Chapter 5. Deployment

Both monolith and microservice architectural styles come with different deployment challenges. In the case of .NET monolithic applications, more often, deployments are a flavor of xcopy deployments. Microservice deployments present a different set of challenges. Continuous integration and continuous deployment are the key practices to deliver microservice applications. Also, container technologies and their toolchain to build and deploy, which promises greater isolation boundaries, are essential for microservice deployment and scaling. 

In this chapter, we will discuss the fundamentals of microservice deployment and the influence of emerging practices, such as CI/CD tools and containers, on microservice deployment. We will also walk through the deployment of a simple .NET Core service into a Docker container.

By the end of the chapter, you will have an understanding of the following topics:

• Deployment terminology
• What are the factors for successful microservice deployments...

Monolithic application deployment challenges

Monolithic applications are applications where all of the database and business logic is tied together and packaged as a single system. Since, in general, monolithic applications are deployed as a single package, deployments are somewhat simple but painful due to the following reasons:

• Deployment and release as a single concept: There is no differentiation between deploying build artifacts and actually making features available to the end user. More often, releases have coupling to the environments. This increases the risk of deploying new features.

• All or nothing deployment: All or nothing deployment increases the risk of application downtime and failures. In the case of rollbacks, teams fail to deliver the expected new features. Besides, hotfixes, or service packs become the norm to deliver the right kind of functionality.

• Central databases as a single point of failure: In monolithic applications, a big, centralized database is a single point of...

Understanding the deployment terminology

It is important that we understand the terminologies around microservices. This will help us navigate through much jargon and buzzwords. This sets our microservice journey on the right track:

• Build: In the build stage, the service source gets compiled without any errors along with the passing of all corresponding unit tests. This stage produces build artifacts.
• Continuous Integration (CI): CI forces the entire application to build again every time a developer commits any change--the application code gets compiled and a comprehensive set of automated tests run against it. This practice emerged out of the problems of frequent integration of code in large teams. The basic idea is to keep the delta or change of the software small. This provides the required confidence of having software in a workable state. Even if a check-in made by a developer breaks the system, it is easy to fix it this way.
• Deployment: Hardware provisioning and installing the base OS...

Prerequisites for successful microservice deployments

Any architectural style comes with a set of associated patterns and practices to follow. The microservice architectural style is no different. Microservice implementation has more chances of being successful with the adoption of the following practices:

• Self-sufficient teams: Amazon, who is a pioneer of SOA and microservice architectures, follows the Two Pizza Teams paradigm. This means usually a microservice team will have no more than 7-10 team members. These team members will have all the necessary skills and roles, for example, development, operations, and business analyst. Such a service team handles the development, operations, and management of a microservice. 
• CI and CD: CI and CD are prerequisites for implementing microservices. Smaller self-sufficient teams, who can integrate their work frequently, are precursors to the success of microservices. This architecture is not as simple as monolith. However, automation and the ability...

Isolation requirements for microservice deployment

In 2012, Adam Wiggins, cofounder of the Heroku platform, presented 12 basic principles. These principles talk about defining new modern web applications from idea to deployment. This set of principles is now known as 12 factor App. These principles paved the way for new architectural styles, which evolved into microservice architectures. One of the principles of 12 factor app was as follows:

"Execute the app as one or more stateless processes" - Adam Wiggins (https://12factor.net/)

This means microservices are shared nothing architectures. So, services will be essentially stateless (except the database, which acts as the state store). The shared nothing principle is also applied across the entire spectrum of patterns and practices. This is nothing but isolation of components to achieve scale and agility.

In the microservice world, this principle of isolation is applied in the following ways:

• Service teams: There will be self-sufficient teams...

Need for a new deployment paradigm

The highest level of isolation for an application can be achieved by raising a new physical machine or bare metal server. So there is a server with its own operating system running on top of it and managing all system resources. This was regular stuff in legacy applications. But it is not practical for modern applications. Modern applications are massive systems. Some examples of these systems are Amazon, Netflix, and Nike, or even traditional financial banks, such as ING. These systems are hosted on tens of thousands of servers. These kinds of modern applications demand ultra-scalability to serve to their millions of users. For a microservice architecture, it does not make any sense to set up a new server just to run a small service on top of it.

With the new CPU architectural breakthroughs, one of the options that emerged is virtual machines. Virtual machines abstract out all the hardware interactions of an operating system through the hypervisor technology...

Containers

Container technology is not new to the Linux world. Containers are based on Linux's LXC technology. In this section, let's see how containers are important in the case of microservices.

What are containers?

A container is a piece of software in a complete filesystem. It contains everything that is needed to run: code, runtime, system tools, and system libraries--anything that can be installed on a server. This guarantees that the software will always run in the same way, regardless of its environment. Containers share their host operating system and kernel with other containers on the same host. The technology around containers is not new. It has been a part of the Linux ecosystem for a long time. Due to the recent microservice-based discussions around it, container technology came into the limelight again. Also, it is the technology on which Google, Amazon, and Netflix runs.

Suitability of containers over virtual machines

Let's understand the difference between containers and virtual...

Docker quick introduction

Docker (www.docker.com) is a company who has been a major force behind popularizing containerization of applications. Docker is to containers what Google is for search. Sometimes, people even use containers and Docker as synonyms. Microsoft has partnered with docker and is actively contributing to the docker platform and tools in open source. This makes docker important for us as .NET developers.

Docker is a very important topic and will be significant enough to learn for any serious .NET developer. However, due to time and scope constraints, we will just scratch the surface of the ecosystem of docker here. We strongly recommend that you read through the Docker books made available by Packt Publishing.

Note

If you want to safely try and learn docker without even installing it on your machine, you can do so with https://KataCoda.com.

Now let's focus on some of the terminologies and tools of the Docker platform. This will be essential for our next section.

• Docker image...