How we view a data center has changed with the introduction of new technologies and software development methods. We will begin with a recap of the characteristics of a fully self-managed data center and go on to explain how our views have changed over time:

It's worth noting that, in all the examples in this book, there is still an underlying data center that has to be managed, but now we're talking about shifting that responsibility of management. In the preceding diagram, each stream of evolution is not tightly linked. For example, monoliths can still be run on private or public clouds. In this section, we will cover the evolution of hardware over time and focus in on the following topics:

• The physical data center
• Colocating our gear
• Cloud born

In the previous section, we were reminded of the progression of building data centers to consuming cloud resources. We can also relate this shift to how we provision, deploy, and scale our compute resources. Let's have a look at how our thinking has moved from deploying physical servers to scaling our applications and to scaling at an application function level:

• Physical servers: Scale at the physical server layer
• Virtual machines: Density efficiencies achieved by virtualizing the hardware
• Containers: Better density with faster start times
• Functions: Best density by abstracting the runtime

When designing for scale in...

The evolution of compute has also opened new possibilities regarding how we structure and architect our applications. Mark Richards talks about "Ingredients that go into an evolutionary cauldron – agility, velocity, and modularity" (source: keynote talk, Fundamentals of software architecture at O'Reilly Software Architecture Conference in London 2016). By this, he means that, when we are talking about the topic of software architecture, we need the ability to change and evolve the way we do things in order to keep up with the ever-increasing expectations we have of new technologies. Instead of investing in complex analysis and planning, organizations should invest in making sure their software solutions include the essential evolutionary ingredients so they can change and evolve at an acceptable pace when...

So, what is the next evolution after nanoservices? We've already seen applications being broken into smaller and smaller parts with the edition of repositories so that developers can share useful functions with others in the community. 

I think we're going to see more sharing of things we can build into our applications, especially things we may not be specialists in building. I postulate that an Algorithms as a Service concept will emerge and become increasingly popular very soon. Developers who have knowledge in a particular problem domain or technology vertical will be able to share their models or the use of those models with others to achieve the same inferences.

A simple example could be a recommendation engine that predicts the likelihood of a customer purchasing a product, given their previous buying or browsing behaviors. Models...

This chapter has been a reminder of the reasons behind hardware, compute, and software architectures evolving to where they are today. As we discovered, the progression of how we want to be less and less responsible for the hardware and compute we consume has been a large driver to abstracting management and responsibility away. 

In the next chapter, we're going to explore some of the factors contributing to how designing and building applications has changed with the adoption of serverless architectures.

1. Which compute option gives you the best workload density?

A) Virtual machines
B) Containers
C) Functions
D) Bare metal

2. Which of the following is a benefit of an n-tier architecture?

A) Defined and separated areas of responsibility
B) Each tier can be scaled individually
C) Controlled network isolation between tiers
D) All of the above

3. What is the typical lifetime of a container?

A) Minutes or hours
B) Milliseconds or seconds
C) Days or weeks
D) Months or years

4. When creating virtual machines on a physical server, what must you take into account?

A) Air temperature and humidity
B) The type of workloads running on the physical host
C) The amount of available CPU and memory

• Introduction to serverless architectures: https://martinfowler.com/articles/serverless.html
• Serverless Computing 101: https://hub.packtpub.com/serverless-computing-101/
• Learn more about serverless in the following video, Design Serverless Architecture with AWS and AWS Lambda: https://www.packtpub.com/virtualization-and-cloud/design-serverless-architecture-aws-and-aws-lambda-video