Over the last couple of years I have done architecture review of multiple product teams that are on their digital transformation journey. Most of the teams were building products following Microservices architecture. They had all the right intentions to use Microservices based architecture — faster development, better scalability, smaller independent teams, independent deployment, using the right technology for the job, etc. But, most often I found teams struggling with Microservices. They failed to leverage the benefits of Microservices to their advantage. In this post, I will share reasons why I think teams were struggling with Microservices.
For people new to Microservices I recommend reading Martin Fowler’s article on Microservices. I like the Microservices architecture definition mentioned in the article.
The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.
The list of reasons is below:
- Management underestimate complexity of developing Microservices
- No process to update libraries and tools to the latest versions
- Use of shared services for local development
- Lack of visibility in their version control hosting platform
- No clear definition of a service
- No clear strategy on code reuse
- Polyglot programming
- People dependency
- Lack of documentation
- Feature over platform maturity
- Lack of automated testing
You can read the complete post on Medium.
Shekhar Gulati 