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.
Features
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).
Key
benefits
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.
Challenges
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
on microservices
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.
