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.

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.  

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.

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.