There have been lots of changes to web applications’ architecture and 2021 is going to be a year where many organisations may consider moving from monolith architectures to microservices. Equally many businesses will opt for a monolith first architecture which is absolutely fine. There is no right or wrong approach, it just depends on where you are with your product development.

A monolith web architecture is a website system where code and functionality are blended-in and coupled rather than having separate or independent components that exist outside of the core application. Not relying on API versioning and separate 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?

Monolith 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, monolith 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 monolith 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 reason. 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 by 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,conducting a survey with its developers to find out what changes they want to see in the architecture. Taking this user-centric approached allowed Shopify to develop a new strategy around “compentization” (so each complment 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 each one’s servers and databases (and often manage separate APIs too). 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 and push it to its limits. Learn the ins and outs of the business logic and only use microservices when and where it makes absolute sense.

 

Share this article
Danny Headshot 2020 v2

Founder & CEO

Danny founded Cyber-Duck in 2005 with one goal in mind: to create exceptional user experiences for global brands.

Related