There have been lots of changes to web applications’ architecture in the last few years and 2021 is going to be a year where many organisations may consider moving from monolithic architectures to microservices. Equally many businesses will opt for a monolithic-first architecture which is best for many use cases. There is no right or wrong approach, it just depends on the complexity and roadmap of your product development.
A monolithic web architecture is a system where code modules and functionalities are all blended-in and coupled rather than having separate or independent components that exist outside of the core application. Less reliant on API versioning and lower DevOps efforts, monolithic architectures have traditionally been the default way to develop complex web applications, allowing tightly coupled knitted development efforts. But recently a trend emerged: Microservices have been hailed as a new and modern way to develop web applications. Which approach should organisations take?
Should microservices top your wishlist?
The ‘mammoth’ monolith?
Monolithic architectures have been around for decades and are generally the convention. They are composed of a database, client UI running in a browser including HTML pages and a backend application that contains the business logic, sends data to and from the database and powers the client UI. The conventional wisdom would make one think that this type of architecture is unsuited for modern applications.
However, monolithic architectures make sense for small teams and projects. When Steve Newman and Steven Czerwinski two senior ex-engineers from Google who started Scalyr, needed a system architecture, they opted for the monolithic approach because of their “simple deployment, debugging and simple operational ability”. The founders of Scalyr said that “when first writing an application, your team doesn’t fully understand the domain yet. Having everything within a monolith makes it easy to move components around while learning about the domain”
The evolution of monolithic architectures over the past couple of decades is however now presenting some technology leaders with certain challenges, especially when scale and a vast quantity of software developers become involved in the project. It starts out fine: a tightly aligned, cost-effective architecture built on a single database that gives you core services, straightforward testing and fast performance.
But after several upgrades and once a few more features get bolted on, that closely coordinated architecture starts to sprawl. The ultimate result can be a large, lumbering monolithic entity with code so entangled that it risks grinding to a halt. Vertical scaling can only go so far, and horizontal scaling quickly gets inefficient. And it's frustrating to be limited to one programming language, and difficult to integrate third-party services.
An example of a Monolithic Architecture.
Microservices to the rescue?
Microservices have been around for a while, but there’s a lot of talk about them again right now, and for good reasons. Microservices are small, lean, focused services that do one thing – and do it really well. Some organisations, especially large technology-led companies like Amazon and Netflix, break down their architectures and structure their teams in independent service. Others, especially smaller companies with limited development resource, buy-in microservices so they can focus on their core operations.
This happened at Shopify in 2016 where the monolithic application became very fragile. If a developer made a change to the tax rate logic, it could have an unexpected impact on the shipping rate calculation. Things were so tightly coupled that when developers deployed updates, quite often a ripple effect triggered a cascade of test failures. Whilst it wasn’t an easy effort, Shopify embraced microservices. They conducted a survey with its developers to find out what changes they wanted to see in the architecture. Taking this user-centric approached allowed Shopify to develop a new strategy around “componentization” (so each component would be structured as its own mini-app), isolate dependencies, enforce boundaries and re-organise the code using real-world concepts.
Microservices offers some significant benefits. Services are decoupled, so they can be upgraded or swapped out as needed. The impact of an issue or glitch is limited to one service. Because they can scale independently, you can scale faster and more cheaply depending on your need.
But here’s the caveat. In order to manage a portfolio of microservices, you have to manage several servers/databases as well as separate APIs so they can talk to each other. Tools like Docker and Kubernetes can help, but if you go overboard on them, you’ll still use up all your budget on technical architecture, taking precious resource away from product development.
An example of a Microservice Architecture.
Conclusion
Martin Folwer, probably one of the most prominent software developers of all time said that almost all successful microservice projects started initially as monolith, got too big and had to be broken down into components later. He also said that whenever a product was built from the ground up using microservices it ended up failing.
So what is our advice for 2021? Start with a monolithic structure with good naming convention and structure and push it to its limits. Learn the ins and outs of the business logic, ensure tests are implemented and only use microservices when and where it makes absolute sense.
