With the introduction of virtual machines also came software-defined networking. This gave us more flexibility in how we can build, configure, and scale networks. With the network also being virtual, we weren't bound by the requirement to have certain types of workloads on specific servers. Our public and private resources could now reside on the same physical server because of the hardware abstraction that was introduced by the hypervisor. 

This means we can build more secure applications by separating the tiers of workloads. Our load balancing or web layer can be separated from the backend application server logic and data stores by a network barrier. We can hide the databases behind a network boundary that further protects from intrusion. Running the tiers on different virtual machines also means the code and configuration can be deployed independently (provided backward-compatibility is maintained).

Teams can now be responsible for their siloed areas of responsibility:

• DBAs can maintain the databases.
• Developers can deploy to the web or presentation tier.
• Engineers can tune the balancing tier.

This sounds ideal in theory, but we still have the challenge of people working in silos. A developer has to request for a network engineer to open ports, or ask for a certain feature in a database to be enabled. The idea of ownership is still very much entrenched in the areas of responsibility, which can give rise to a culture of blame. Have you ever heard someone say works for me, or not my issue? 

In terms of hardware utilization, the biggest impact here is that we can now scale by workload type. If the user demand was running a task that was creating a high load on the processing tier, we can add more compute nodes (virtual machines) to this tier, independently of the web tier. This is called scaling horizontally.

Amazon EC2 and Autoscale Groups is a great way to do this automatically in response to a certain metric threshold—for example, the number of user sessions or the utilization of a CPU. For on-demand EC2 instances, AWS charges for the amount of time that an instance is running.

Of course, once our application grows significantly, we may have multiple developers working on different parts of the application. Each feature may evolve differently and may deal with data in different ways. Microservices can help break an application into domains where each can use their own implementation strategy and database.