This chapter does not focus on specific technologies, going for a more agnostic approach. We will discuss a Python Django application for our monolith example.

The monolith example can be found at: https://github.com/PacktPublishing/Hands-On-Docker-for-Microservices-with-Python/tree/master/Chapter01/Monolith. Installation and running instructions can be found in its README.md file.

The traditional approach to the software when developing a system has been to create a monolith. This is a fancy word to say a single element, containing everything, and it is the way virtually every project starts. In the context of web applications, that means creating deployable code that can be replicated so that requests can be directed to any of the deployed copies:

After all, every project will start off small. Making strict divisions early on is inconvenient and even doesn't make sense. A newly created project is small and probably handled by a single developer. While the design can fit in the head of a few people, making strict boundaries between parts of the system is counterproductive.

The monolith approach works until the point it doesn't. But, what is the alternative? That's where the microservices architecture enters into the scene.

A system following a microservices architecture is a collection of loosely coupled specialized services that work in unison to provide a comprehensive service. Let's divide the definition a bit, in more specific terms:

1. A collection of specialized services, meaning that there are different, well-defined modules.
2. Loosely coupled, meaning that each of the microservices can be independently deployed.
3. That work in unison—each microservice is capable of communicating with others.
4. To provide a comprehensive service, because our microservice system will need to replicate the same functionalities that were available using a monolith approach. There is an intent behind...

The single most important element is the capacity to deploy independently. Rule number one for creating a successful microservices system is to ensure that each microservice can operate as independently as possible from the rest. That includes development, testing, and deployment.

This is the key element that allows developing in parallel between different teams, allowing them to scale the work. This increases the speed of change in a complex system.

The team responsible for a specific microservice needs to be capable of deploying a new version of the microservice without interrupting any other teams or services. The objective is to increase the number of deployments and the speed of each of them.

We've discussed a lot of advantages that the microservice architecture has over a monolith, but migrating is a massive undertaking that should not be underestimated.

Systems get started as monoliths, as it is simpler and allows for quicker iteration in a small code base. In any new company, pivoting and changing the code, searching for a successful business model is critical. This takes preference over clear structures and architecture separations—it is the way it should be.

However, once the system matures, the company grows. As more and more developers get involved, the advantages of a monolith start to become less evident, and the need for long-term strategy and structure becomes more important. More structure doesn't necessarily mean moving toward a microservice architecture. A great deal can be achieved with a well-architected monolith...

The very first step, as we defined before, to migrate from a monolith to a collection of microservices is understanding the current system. This stage should not be underestimated. It is highly likely that no single person has a good understanding of the different components of the monolith, especially if some parts are legacy.

The objective of this phase is to determine whether a change to microservices will actually be beneficial and to get an initial idea of what microservices will be the result of the migration. As we have discussed, making the move is a big investment and should not be taken lightly. Making a detailed estimation of the effort required won't be possible at this stage; uncertainty will be big at this point, but a thousand-mile journey starts with a single step.

The effort involved will vastly depend on how structured the monolith...

Obviously, any real-world system will be more complicated than our example. There's a limit to what a code analysis can discover just by looking at it carefully, and plans often don't survive contact with the real world.

Any division needs to be validated to ensure that it will have the expected result and that the effort will be worth it. So double-check that the system is working the way you think it is working.

The ability to know how a live system is working is called observability. The main tools for it are metrics and logs. The problem you'll find is that they will normally be configured to reflect external requests and give no information about internal modules. We will talk about the observability of systems in depth in Chapter 10, Monitoring Logs and Metrics. You can refer to it for more information and apply the...

As we've discussed previously, moving from the initial state to the desired one will be a slow process. Not only because it involves new ways of doing things, but also because it will happen in parallel with other features and developments that are "business as usual." Being realistic, the company's business activities will not stop. That's why a plan should be in place to allow a smooth transition between one state and the other.

There are a few alternatives as to what technical approach to take to make the move and how to divide each of the elements to migrate to the new system:

• The...

The final step is to execute the carefully devised plan to start moving from the outdated monolith to the new promised land of microservices!

But this stage of the trip can actually be the longest and most difficult—especially if we want to keep the services running and not have outages that interrupt our business.

The single most important idea during this phase is backward compatibility. This means that the system is still behaving as the old system was from an external point of view. If we are able to behave like that, we can transparently change our internal operation while our customers are able to continue their operations uninterrupted.

That's obviously more easy to say than to do and sometimes has been referred to as starting a race with a Ford T and ending it with a Ferrari, changing every single piece of it without stopping. The good news...

In this chapter, we saw what the differences are between the traditional monolith approach and microservices architecture, and how microservices allow us to scale development across several teams and improve the delivery of quality software.

We discussed the main challenges that are faced during a transition from a monolith to microservices and how to perform the change in different stages: analyzing the current system, measuring to validate our assumptions, creating a plan to split the monolith in a controlled way, and tactics to successfully perform the move.

Though this chapter was written in a technology-agnostic way, we've learned why Docker containers are a great way of implementing microservices, something that will be explored in the following chapters. You also now know how using a load balancer helps to maintain backward compatibility and deploy new services...

1. What is a monolith?
2. What are some of the problems of monoliths?
3. Describe the microservice architecture.
4. Which is the most important property of microservices?
5. What are the main challenges to overcome in a migration from a monolith to microservices?
6. What are the basic steps to make such a migration?
7. Describe how to use a load balancer to migrate from an old server to a new one without interrupting the system.

You can learn more about systems architecture and how to divide and structure complex systems in the books Architectural Patterns (https://www.packtpub.com/application-development/architectural-patterns) and Software Architect's Handbook (https://www.packtpub.com/application-development/software-architects-handbook).