In the Digital Pulse ‘Uncovered’ series, we put the spotlight on tech terminology, clarifying the internet trends and buzzwords of the moment.
Here, Adnan Jaswal explains microservices architecture, a digital solution spearheaded by some of the world’s biggest businesses to deliver speed and agility.
Modern day digital businesses need to be swift and responsive to their customers’ demands. This may involve updating business features, or even changing business model entirely. They must also be able to quickly add new elements to their digital offering, or change existing ones, while making sure that their service offering is reliable, scalable and secure.
To meet this demand and to overcome some of the associated challenges, today’s systems must be architected for agility. Microservices architecture – a design approach that’s well suited for multiple digital channels such as web, mobile and the internet of things – could offer the solution.
A microservice is a small and independent service that focuses on doing one thing and doing it well. It supports a specific business feature through a well-defined interface and is independently developed, tested, maintained and deployed.
Microservices architecture is the design approach that uses a suite of these independent microservices to build applications. The general principle behind this style of architecture is that the applications become easier to develop and maintain when broken down into smaller, more manageable components.
The opposite approach is a traditional monolith application, which is created as a single deployable unit. Imagine a monolith as being like a building made from solid concrete: even a small change would require a rebuild and redeployment of the entire application. Microservices is more like a Lego type of architecture: each block is an autonomous piece that you can take away and do something completely different with.
of microservices architecture
Microservices are usually divided along service boundaries. For example, consider an e-commerce application that provides two features to its users: allowing them to search for products, and to add a product to the shopping cart. Both these features would be developed and deployed as a single unit in a monolith application. Within microservices architecture, however, these two business features would be developed as two independent services.
Now let’s take the above example and extend it into a real-life situation on Amazon. On that site, a search for a particular shoe might trigger over 170 different applications, from pricing, to reviews to recommendations of other products. On that scale, the decoupling of functions makes perfect sense.
In fact, Amazon is credited with being one of the pioneers of microservices architecture. Talking about its early reliance on the monolith structure in 2001, Amazon senior manager for product development, Rob Brigham, told a 2015 conference: “A lot of startups, and even projects inside of big companies, start out this way […] because it’s very quick. But over time, as that project matures, as you add more developers on it, as it grows and the codebase gets larger and the architecture gets more complex, that monolith is going to add overhead into your process, and that software development lifecycle is going to begin to slow down.”
Eventually, he said, “We went through the code, and pulled out functional units that served a single purpose, and we wrapped those with a web service interface.” This is the point at which the search function gets separated from the add-to-cart function, and so on.
Whilst the term ‘microservices’ was only apparently coined in 2012, the design principles that underpin it are neither new nor innovative. The roots of this approach go back to distributed systems and service oriented architecture, which have been around since the 1970s (roughly speaking, any systems that consists of multiple nodes that talk to each other – think telephone networks and the phones that communicate with each other).
The key benefit of microservices architecture is speed and agility. You can deliver new features and change existing ones faster than you would be able to if you were to develop a monolith application. Other key benefits that make microservices architecture highly attractive are:
- Scalability: being autonomous, individual microservices can be scaled independently of the whole solution. For example, if a particular microservice becomes a bottleneck, it could be vertically or horizontally scaled without the need to scale the whole system.
- Resilience: in a typical monolith application, a failure in one part of the system usually brings the whole application down. A failure of a microservice is isolated and doesn’t cascade to the rest of the system. This allows us to build more resilient systems that can gracefully degrade functionality on failures.
- Choice of technology stack: since each microservice is an autonomous system, it can be developed in a technology stack that is right for the job. For example, a particular service that requires high performance can be developed independently using a technology stack that may be more expensive but is better equipped to deliver those particular needs (without the same high cost rolling out across all services). The freedom to choose the right technology for the function also mitigates the risks associated with adopting new technologies.
While microservices architecture has many benefits over traditional approaches, there are a few challenges that must be considered before adopting it for your next project.
Microservices architecture comes with all the complexities you would normally associate with distributed systems, such as implicit contracts between collaborating nodes, distributed transactions, security, and network latency.
The overall complexity of the system is also increased because of the need to maintain and deploy individual services. High levels of automation are usually required to roll out updates and deploy new services.
Making the right call
It’s safe to say the benefits outweigh the challenges and the cost when microservices architecture is adopted on the right project. However, microservices architecture has only been around for a few years, which means that the development, running, and maintenance of these systems is still in its early days.
Although the technologies are fast improving, as with any approach, it is critical to make an informed decision on whether to proceed – and only an experienced team, fully aware of the complexities, can make that call.