With so many companies getting caught up in the microservices hype, a post by Sean Kelly on the Basho Blog attempts to dispel five of the microservices myths that many developers and businesses have been sold on. The post is adapted from a talk Kelly gave at the Boston Golang meetup in December 2015, and it references his own experiences working at a company that bought into the microservices movement and broke up its legacy monolithic application.
Microservices are not a requirement for writing cleaner code, but the fewer pieces involved do somewhat reduce your ability to write lazy or poorly thought out code. Instead, architect the internals of your code around logical ‘services’ in a way that mirrors microservices by owning a specific piece of the domain. This approach offers better management of dependencies and business logic while reducing excess network usage. It will also make any later transition to microservices much easier.
Defining the specifics of a domain, especially in younger companies that are still fine-tuning their offering, is never easy. And since a piece of a domain must often get data about other parts to do its job correctly, and sometimes delegate the responsibility of writing data outside of its domain, you begin to face up to the complexity of Distributed Transactions.
Must your system call remote services in a given request in parallel, or can they be called serially? And how is the request affected by any of the many potential errors that might occur? Each distributed transaction requires its own approach for handling possible failures, which can create a lot of work.
This claim may be somewhat anecdotal, but there are sure to be real instances of individual code paths isolated inside a service executing faster after adopting a microservices architecture. However, this doesn’t consider the inclusion of the network between many of the calls. Many of these stories actually relate to the benefits of a new language or entirely new technology stack, not microservices themselves.
This notion was discussed in a recent post on TechTarget where Constant Contact’s Dave Berard highlighted the fact that the need for multiple systems calls in a microservices approach can take far longer than a monolithic app, leading them to avoid microservices altogether.
It’s Simple for Engineers
Small teams running small pieces of the puzzle seems like a simple approach, but it can create far larger issues, particularly in the need to run more services to make even small changes. Docker can help with building and maintaining a simple way for engineers to run everything locally, but someone still needs to maintain Docker as things change. Add in the severe complexity of writing integration tests and resolving bugs that span multiple services, and you’re a long way off from the benefits of having engineers sharing knowledge by working together on the same code base.
It’s Better for Scalability
While packaging your services as distinct units for scaling with something like Docker is a great approach for horizontal scaling, this approach is not limited to microservices. You can achieve this in a monolith by creating logical clusters of your application that handle a particular subset of the traffic. This allows you to tune each cluster to its given workload, and scale them individually to handle surge traffic.
Microservices do offer many benefits, but it is vital to understand the domain you’re working in before making any key decisions on adopting the architectural approach. If you have a solid understanding of what the boundaries are and what the dependencies are, microservices could be the right move. However, if you’re still trying to make sense of it, adopting microservices could do more harm than good.