We have looked at various strategies for scaling our application, different types of databases, how to structure our code, and finally how to use the mediator pattern to make the transition from monolith to microservices. However, we haven't discussed where we would be deploying said web application and databases. Let's take a brief look at the deployment landscape.

Till the early 2000s, most servers were deployed on hardware owned by the companies writing the software. There would be dedicated infrastructure and a team to deal with this critical part of software engineering. This was mostly the subject of data centers.

However, in the 2000s, companies began to realize that data centers could be abstracted away because most of the developers weren't interested in handling these problems. This allowed for cheaper and faster development and deployment of software, especially for web applications. Now, instead of buying hardware and space at a data center, the developers would be provided with server instances they could access via SSH. One of the most prominent companies in this field from the start was Amazon.com, Inc. This allowed them to expand their business beyond e-commerce.

These services also gave rise to the question: do developers need to install and maintain generic applications such as databases, load balancers, or other such services? The reality was that not all developers or companies wanted to be involved with maintaining these services. This created demand for ready-to-use application instances that would be maintained by the company selling these applications as a service.

There are many companies which initially started out as software companies that maintained their own data centers—Amazon, Google, and Microsoft to name a few examples—and they now boast a great set of such services for general consumption.