I heard from a developer not long ago that his team limits the size of each microservice to less than 300 lines of code. That can be one way to define the size of a microservice. But, really?
There are number of problems with using lines of code to define microservices:
- Depending on the programming language, some will require more lines of code than others to express the same service.
- Microservices are explicitly not supposed to predetermine the technology stack.
- Most importantly, microservices represent an architecture approach.
So, how *do* you define the size of Microservices?
Recently, I picked up the book Microservices – Flexible Software Architectures by Eberhart Wolff, and I really like Eberhard’s approach on how to the determine size of a microservice.
He explains that we need to consider several factors influencing the size of a microservice (from upper limits to lower limits):
- TEAM SIZE. Never be so large that several teams are required to work on a microservice. “You build it – you run it.”
- MODULARIZATION. The microservice should preferably be of a size that allows developers to understand and further develop it.
- REPLACEABILITY. The smaller a microservice is, the easier it is to replace it. Above a certain size, it may be difficult to replace as it then poses the same challenges as a monolith.
- TRANSACTIONS AND CONSISTENCY. Data exchange within a transaction and data are only possible when all concerned are part of the same microservice. When transactions are requiring several microservices, and when data consistency is required across several microservices, the microservices have been designed too small. However, when communicating via messaging systems, transaction consistency is possible but not easy to design.
- INFRASTRUCTURE. When a small microservice is chosen, the system is distributed into many microservices which require more infrastructure.
- DISTRIBUTED COMMUNICATION. Microservices run within self-contained processes. Communication between a microservice is distributed communication via the network. According to the “First Rule of Distributed Object Design” approach, a system should not be distributed if it can be avoided because calling on another system via the network is orders of magnitude slower than a direct call within the same process. In addition to the pure latency time, serialization and deserialization of parameters and results are time-consuming. These processes also cost CPU capacity. For this reason, the microservice should not be set too small.
Remember, microservices are not easy. A system comprised of microservices has many components which have to be deployed, controlled, run, and monitored. It is complex. It also requires solid operations, DevOps and a solid number of runtime infrastructure, ideally Cloud/Container. Developers face increased complexity because they are a truly distributed system.
There are many advantages to adapting microservice architecture approaches, including:
- Strong Modularization
- Easy Replaceability
- Sustainable Development
- Quick Time-to-Market
- Independent Scaling
- Free Choice of Technologies
- Continuous Delivery
The right microservices architecture approach will lay a great foundation for enterprise transformation. Remember, microservices are not technology stack but rather an architecture approach. There are so many technology vendors who claim that they have solutions for microservices, but it is important to research and have a solid understanding of microservices before diving into creating technology solutions.