admin
November 10, 2020
Microservices vs Monolith – a Pragmatic View
Microservices are all the rage right now, but while they offer numerous benefits, they are far from being a silver bullet and in certain contexts can even prove to be a major impediment to an application’s agility and efficiency.
A natural evolution from services oriented architecture (SOA), which led the way for REStful lightweight services with JSON documents, microservices can be defined as loosely coupled, highly specialised services which can be developed, deployed, and maintained independently.
Microservices wouldn’t have gained such popularity if they didn’t offer a slew of benefits. Each microservice can be developed and deployed independently, is easy to understand and manage, and allows large development teams to coordinate work effectively. They also offer improved fault isolation, because an error in one service doesn’t stop the entire application from functioning, which improves its overall resiliency. Microservices further allow developers to choose a technology stack that is best suited to the particular service instead of a more monolithic approach.
That said, microservices also have a number of drawbacks, which are primarily organisational in nature. When an organisation depends on a small team to maintain a range of different microservices, they can easily be overwhelmed by the breadth of skills and knowledge required. High granularity can result in complexity managing large sets of microservices, and scalability with dependencies on other microservices can lead to bottlenecks.
The simplest way to illustrate this situation is to imagine the difference between building a simple three-bedroom house and a large commercial warehouse. Building a warehouse requires multiple specialist teams that can meet the different requirements of the project – constructing the loading bays, the warehouse floor and workflow, the administrative office and the security infrastructure, to name just a few. Instead of a one-size-fits all approach, a well-built, efficient and cost-effective warehouse requires a range of different construction methods, materials and technologies.
In contrast, a house requires fewer specialisations, materials and technologies, so it makes much more sense to take a monolithic approach, where a single construction crew takes on the entire project.
Thunes’ core offering comprises one main, modular service, namely our cross-border money transfer service, which we believe to be best served by a monolithic approach to development. That doesn’t mean that we’re opposed to a microservices approach in principle. In fact, some of our additional services are more suited to independent, isolated deployment.
Where microservices really shine is where a service is complex and multifaceted. Online accommodation marketplace Airbnb, for example, relies on a broad range of disparate functions, each largely independent from the others. There’s the booking engine, ratings system, payment gateway, and other discrete services, which together make up the broader Airbnb ecosystem. In this case, it makes perfect sense to make use of microservices, because specialist teams can be dedicated to each service, and if one service goes down, the broader service can continue to operate.
In summary, it is our view that microservices are best suited to large, complex systems with many different specialisations, and organisations with large development teams. For specialised services and smaller teams, a monolithic, modular (or should that be modulithic?) architecture makes far better sense.
Looking into the future of Thunes, as we expand our product offerings and grow our engineering team (we’re hiring!), microservices may well form more and more of our architectural approach. As our teams grow, they will also most likely need to become more specialised. Until that day comes, our functionality remains focused enough to warrant a monolithic architecture.
If you’re interested in continuing this discussion and seeing how Thunes can help your business, get in touch with our team today.
