Microservices Architecture

Originally Published July 21, 2018

 

Introduction

All software systems exist to serve a business need. However all software systems are not made in the same way or follow the same structure. Software systems vary in their complexity and size. There’s a an ecosystem that exists across a wide spectrum ranging from traditional software systems commonly called ‘monoliths’ (giant one-piece bundles of code) to ‘microservices’ (tiny single-function systems or apps communicating with each other).

Monoliths or conventional software systems are conceived, built and operated as a single unit.  Because of their size and complexity, even smallest changes in monolithic systems involve building and deploying the whole application. Flexibility is almost zero while the entire system requires huge efforts to just maintain and run day to day operations. Scaling monolithic applications is another challenge why organizations are seeing less and less benefits in operating such software systems.

On the other hand, microservices come in to picture as a combination of various small features where each feature serves only one distinct purpose of the system. Martin Fowler describes microservices as an approach to developing an application as a suite of small services.

 

Image Credit: Internet

 

Microservices Architecture – Explained

With microservices, modules or functionalities within an application can be independently produced, deployed and operated. Microservices architectures offers businesses an unique ability to build and operate only those functionalities which are required. Microservices architecture focuses on creating software as single-function components (microservices) with well-defined interfaces and operations that communicate via APIs.

As the microservices are independently deployable and scalable, each service exists within a firm boundary, even allowing for different services to be written in different programming languages and can also be managed by different teams.

The most important parameter to decide what and how many Microservices are needed is to identify business needs that need to be met. A functionality can be loosely defined as a purpose of the particular element – for example user getting authenticated through an username / password combination is a a functionality and authentication is the business feature. What counts is how various business features (functionalities) are categorized as business capabilities and then split, where required, as fully independent, fine-grained, and self-contained microservices. Hence, the Microservices architecture has certain distinctive features making it more desirable for some business cases than others.

Image Credit: Oracle

 

Benefits and Advantages of Microservices Architecture

The main concept behind microservices architecture is that most types of applications and business units structured around their IT portfolio become easier to build and maintain when they are broken down into smaller, composable pieces which work together. To put it differently, each module or component is developed and operated separately, and the application is then simply the sum of all its constituent components. In microservice architecture, each service runs a distinct and independent process and usually manages its own database. This provides development teams with a more decentralized approach to building software while also allowing each service to be deployed, rebuilt, redeployed and managed independently.

Image: Advantages of microservices architecture

 

1. Enabling Agile Development

• Microservices architecture involves organizing services around business features. Each service is self-contained and generally implements a single business capability. Hence, value delivered to business is immediate rather than waiting for big bang value delivery as in case of monolithic applications.
• Applications / software built on microservices model are broken down in to smaller, outcome driven components or services. Each of these components or services can be produced, deployed and redeployed independently throughout the lifecycle.
• Developers and tech teams get the freedom to work on individual components or services and features delivering short increments of business value.
• Testing cycles are quick and short; and complex, endless regression tests are eliminated as there are limited components to be tested. Defect fixing is vastly improved as well.
• Customer feedback cycle is greatly helped as smaller microservices are easier to focus on and relevant feedback can be provided without confusing between complex features in case of monolithic applications.

 

2. Optimization / Flexibility

• In the microservices architecture, each service is a separate codebase, generally managed by a small development team.
• Services are responsible for persisting their own data or external state. This differs from the monolithic application model, where a separate data layer handles data persistence.
• There are components or microservices which are better written in one language. Microservices architecture enables developers to write code for different services in different languages.

 

3. Operations / Fault tolerance

• Microservices architecture leads to greater fault tolerance within an application or software. Since the application is a suite of multiple small microservices, it leads to better fault isolation as when one microservice fails, the others will largely continue to work.
• Downtime is severely reduced as individual components are easier and quicker to fix, while the fixes themselves can be deployed quickly rather than bringing down whole application and repeating endless regression tests to ensure that fix implemented doesn’t break any other component in case of monolithic applications

 

4. CI / CD

• By default, microservices architecture enables easy integration through quick deployments, many times using open-source continuous integration tools such as Jenkins, etc.
• Services are deployed independently. A dev team can update an existing service without rebuilding and redeploying the entire application.
• The microservice architecture enables continuous delivery. Microservices architecture works very well with containers, such as Docker.

 

5. Security

• Microservices vastly simplifies security monitoring because various parts of an application or software are isolated, hence can be easily observed and managed.
• Security threats once identified can be quickly isolated and thus prevented from spreading to other parts of the application or software.
• Components or services can be spread across multiple data centers and / or environments and run on different systems to reduce risk and downtime while providing enhanced disaster recovery planning.

 

6. Scalability / Reusability 

• Smaller pieces of functionality are better re-used; integration with third party services is quicker and less complex.
• Microservices architecture gels very well with cloud infrastructure, thereby becoming highly scalable

 

7. Ease of operation

• Components thus built are easy to understand since they each represent a small piece of functionality, and are easy to modify for developers, thus helping create resilience within the structure.
• A new team member can become productive quickly by understanding and working on individual models instead of wasting time understanding the complete application and various interfaces.

 

Image Credit: Internet

Microservices Architecture – early adapters

As in case of any new technical offering, there are organizations which were quick to adapt to microservices, just as there are organizations who held out. Organizations like Netflix, eBay, Amazon, the UK Government Digital Service, Twitter, PayPal, The Guardian, and many other large-scale websites and applications have all gradually evolved from monolithic to microservices architecture.

In case of retail giant Walmart, IT department of Walmart Canada was plagued with problems arising out of working with an architecture for the internet of 2005, primarily designed around desktops, laptops and monoliths of a classic monolithic application. The problem was the IT infrastructure worked fine for 90% of the time and seemed to miserably fail during remaining 10% of times. The impact of this 10% failure rate was spectacular – at peak times, like during holiday season, major holidays and other events, the website couldn’t handle 6 million pageviews per minute and made any kind of positive customer experience impossible to achieve. Business impact – poor customer experience, lost revenue / sales to the tune of millions of dollars, losing market share, etc. Walmart Canada wanted to prepare for the world by 2020, with 4 billion people connected and 25+ million apps available. With this intent, Walmart changed its platform to microservices architecture. The impact of this change was immediate and as clear as day. Conversions were up by 20% literally overnight, mobile orders went up by 98% instantly, no downtime on major events like Black Friday or Boxing Day, operational savings were significant since they moved off expensive hardware onto commodity hardware and saved 40% of the computing power and experienced 20-50% cost savings overall.

 

Image: an example of Microsoft Azure

Image Credit: Microsoft blog

 

Image: an example of microservices architecture on AWS

Image Credit: Amazon AWS Blog

 

In 2000, Amazon faced a similar challenge with its primary business, the retail business website Amazon.com being managed as a single monolithic application. The complex scale and size of the application meant that Amazon had to maintain teams of engineers just to support very mundane tasks of pushing new fixes and releases through its production environment. The process of adding a new feature, or changing an existing one, or a simple bugfix was extremely complex and inefficient. Each change needed to be coordinated across a wide spectrum of stakeholders and technical teams to ensure the new changes do not break anything in the existing code. If the development team wanted to roll out a feature, the schedule needed to be coordinated very closely with other stakeholders.

Amazon soon chose to implement a services oriented architecture and proceeded to break down their one, central, hierarchical product development team into small, “two-pizza teams.” They wanted teams so small that they could feed them with just two pizzas. These smaller teams were given clear mandate and operating boundaries and were put in charge of one or few microservices so they were defining their own feature roadmap, designing their features, implementing their features, then testing, deploying and operating them. The results were simply too good. Amazon dramatically improved its front-end development lifecycle, with the product teams enabled to quickly make decisions and crank out new features for their microservices. Now the company makes 50 million deployments a year, thanks to the microservice architecture and their continuous delivery processes.

Breaking your applications into microservices isn’t always easy or enough — once done, someone has to manage, orchestrate them and deal with the new stack. The biggest mistake organizations make when moving to microservices architecture model is underestimating how it’s going to change the way they to think about applications and especially the way they think about teams developing those applications. Here are few points to be careful of while deciding path to microservices adaption.

• Implementing Microservices without making changes to the development culture
• Implementing Microservices without the prerequisites
• Moving too fast and moving too much
• Unrealistic expectations from microservices architecture, something on the lines of magic pills!
• Selecting wrong applications to promote to microservices model

 

Microservices Architecture – Final word

The philosophy of the microservices architecture is: “Do one thing and do it well.” Services might run within the same process, but they should be independently deployable and easy to replace. They can be implemented using different programming languages, databases, and software environment. The services are small and fine-grained to perform a single function. They embrace automation of testing and deployment, continuous delivery software development process, failure and faults, similar to anti-fragile systems. Each service is elastic, resilient, composable, minimal, and complete.

Image Credit: RisingStack