Microservices should not be (default) architecture choice

Four years ago I wrote a post about misconception about microservices. That was the year when microservices adoption had already begun riding on the containerization wave powered by Kubernetes. Since then Microservices architecture has become most talked about architectural style filling up the void created by downfall of SOA.

This post is summary of challenges emerged from industry and my own experience in implementing this hyped architecture. Microservices fans will be shocked to read that Istio, (a service mesh used to help solve difficult application-networking challenges introduced by a microservices/cloud architecture), itself has moved away from a microservices architecture.

Microservices are independently deploy-able services modeled around a business domain.

The Challenges

Q: When to adopt microservices architecture?

This is the most important question. First thing I would ask “Would this system benefit from the ability to deploy subsystems separately?” Probably you are better to start with and even continue with monolith architecture style. This may seem to be contrary to popular belief but this is what Sam Newman warns and reverse journey from microservices tell about. Both are worth reading.

Q: How to get started on microservices journey?

For new application development, most likely you don’t because the system’s scope may not be large enough to justify the complexity of a distributed architecture or to justify the cost of building the deployment automation. Sometimes, there is lack of domain to properly identify and separate the system’s various independent business capabilities?

For existing monolith application, advisable approach is to convert incrementally than do it big bang. Doing in small pieces carries lesser risk. Identify very few but key business functionalities to split. Invest in building a solid deployment automation pipeline initially. Demonstrate the benefit to the stakeholders. Take patterns-based approach in every phase. See useful patterns later in this post.

Design Considerations

Q: How to decide granularity of microservices?

Q: How to solve any cross-cutting concerns in microservices?

Q: How to ensure code reuse across different microservices?

Q: Should I spilt the database first, or the code?

Q: How to design distributed data management?

• How to define the boundaries of each microservice
• How to create queries that retrieve data from several microservices
• How to achieve consistency across multiple microservices
• How to enable communication across microservice boundaries

The Pitfalls

Ok, so you have carefully evaluated and decided to go with microservices architecture. What are the things that must be known before diving into microservices world? Let’s see below.

Q: What are downsides of a microservice-based solution?

The benefits (easier to change, independently scale etc) are well known but it comes with its own set of problems and challenges in live integrated environments.

• Distributed application – More you distribute the application; more complex it becomes in terms of inter-service communication during building and testing. It also adds latency to the system. Those who have worked on distributed application in pre-microservices era, can easily imagine the chaos in highly distributed application(s).
• Deployment complexity – An application that has dozens of microservices types and needs high scalability means a high degree of deployment complexity for IT operations. Yes, now the tooling is maturing fast to ease out but then you need highly skilled DevOps or SRE professionals in your team.
• Distributed transactions – Atomic transactions between multiple microservices usually are not possible. The business requirements have to embrace eventual consistency between multiple microservices. New patterns have emerged to deal with this problem. See patterns question.

Q: Why observability is so important?

The concept of observability aims to provide data on the behaviour of systems. It is one level up from traditional monitoring. It has become increasingly important for cloud-based distributed systems such as those commonly found with microservices. This is to monitor traffic, errors, latency, collect logs and traces and maintain service inter-dependencies map. All these measures give visibility into service to service communication.

The Patterns

There are many but look at Domain Decomposition and Strangler to begin with. Then there are essential patterns like Chasis and Saga. Although these are platform agnostic, however a platform might provide a framework implementing a pattern. For example – A good microservice architecture needs to have a Microservice chassis pattern like Spring Boot (Java) or Gizmo (Golang) or PyMS, Eve (Python).

New Trends, Best Practices

Microservices are typically backend services leaving a monolithic frontend layer. New patterns have emerged to break the frontend layer code into micro-frontends. A best practices deep dive, look at this. There are useful reference architectures from microsoft and nginx.

Conclusion

Interest towards Microservices have already began to show flat curve across developers and IT organizations. Having said that, it also true statement that the Monolithic Architecture and Microservice Architecture both are architectural patterns. Which one you should choose depends on your context, the problem you are trying to solve and architectural constraints you work under.

If you have other experience or opinion, feel free to share in comments. Share if you enjoyed reading it. Stay safe! Stay Healthy!