Hands-On Docker for Microservices with Python
上QQ阅读APP看书,第一时间看更新

Parallel deployment and development speed

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.

The microservice architecture is strongly related to Continuous Integration and Continuous Deployment principles. Small services are easy to keep up to date and to continuously build, as well as to deploy without interruption. In that regard, a CI/CD system tends to be microservices due to the increase in parallelization and the speed of delivery.

As deploying a microservice should be transparent for dependent services, special attention should be paid to backward compatibility. Some changes will need to be escalated and coordinated with other teams to remove old, incorrect functionality without interrupting the system.

While, theoretically, it's possible to have totally disconnected services, that's not realistic in practice. Some services will have dependencies between them. A microservice system will force you to define strong boundaries between the services, and any feature that requires cross-service communication will carry some overhead, maybe even having to coordinate the work across different teams.

When moving to a microservices architecture, the move is not purely technical but also implies a big change in the way the company works. The development of microservices will require autonomy and structured communication, which requires extra effort up front in planning the general architecture of the system. In monolith systems, this may be ad hoc and could have evolved into a not-so-separated internal structure, increasing the risk of tangled code and technical debt.  

The need to clearly communicate and define owners cannot be stressed enough. Aim to allow each team to make their own decisions about their code and formalize and maintain the external APIs where other services depend on them.

This extra planning, though, increases long-term delivery bandwidth, as teams are empowered to make more autonomous decisions, including big ones such as which operating system to use, or which programming language, but also a myriad of smaller ones, such as using third-party packages, frameworks, or module structures. This increases the development pace in day-to-day operations.

Microservices may also affect how the teams are structured in your organization. As a general rule, existing teams should be respected. There will be expertise in them that will be very useful, and causing a total revolution will disrupt that. But some tweaks may be necessary. Some concepts, such as understanding web services and RESTful interfaces will need to be present in every microservice, as well as knowledge on how to deploy its own service.

A traditional way of dividing teams is to create an operations team that is in charge of infrastructure and any new deployments because they are the only ones allowed to have access to the production servers. The microservices approach interferes with this as it needs teams to be able to have control over their own deployments. In Chapter 5, Using Kubernetes to Coordinate Microservices, we'll see how using Kubernetes helps in this situation, detaching the maintenance of the infrastructure from the deployment of services.

It also allows creating a big sense of ownership, as teams are encouraged to work in their own preferred way in their own kingdom, while they play the game with the rest of the teams within clearly defined and structured borders. Microservices architecture can allow experimentation and innovation in small parts of the system that, once proven, can be disseminated across the whole system.