An Overview of Microservice Architecture – Part I

Companies want to bid farewell to legacy architecture and digitize their business models, products and infrastructure. While some advanced companies are leveraging two-speed IT, DevOps and Cloud, some others are still trying to figure out a way to build disruptive web and mobile products faster.

Moreover, growing consumer demands have increased the need to build large scale and complex applications meeting the requirements of end users. Traditional product development teams used to work on a single monolithic deployment artifact. Monolithic architectural style puts all its functionality into a single process and scales by replicating the monolith on multiple servers.

However, it was challenging to continuously manage one large monolith. Agile software teams weren’t able to leverage Agile principles in a real way. They found the monolith too complex to understand and debug. They were also challenged to implement new features, updates and releases.

Moreover, monolithic architecture also impacted startup time of applications. In one of the surveys, developers reported startup times as long as 12 minutes. Apple suggests to aim for a total app launch time of under 400ms and you must do it in less than 20 seconds or the system will kill your app.

Continuous deployment was another pain point with most monolithic architecture. Development teams need to push changes to production multiple times a day and with so many releases being shipped, it is extremely difficult to redeploy entire monolith again and again just to update a small part of it. Moreover, as the impact of the change is difficult to understand, it would require an extensive testing effort every time there is a need to update or deploy.

Furthermore, monolithic applications are less reliable as modules run within the same process. The breakdown in any of the modules will impact entire process and ultimately hamper the user experience. For development teams, a larger challenge was to identify the bugs from various identical instances and make the application available at all times.

With monolithic applications, it is also very difficult to adopt new framework and language. As it is difficult to change and rewrite code, it is not possible to introduce a new framework to improve specific aspects of the application. Monolithic applications hence present a huge barrier to adopting new technologies.

Clearly, monolithic applications are a tough nut to crack. They are difficult to understand and scale with time.

Microservice Architecture – A shift to resolve the complexity

What are microservices?

“A loosely coupled service oriented architecture with bounded contexts to make sure you break your problem into the right chunks”  – Adrian Cockcroft

“An approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms” – Martin Fowler

With the focus on developing applications faster and cut down on the development costs, microservices are quickly gaining traction among software development teams. Agile teams find this architectural style a key enabler for improving the product delivery process.

Microservice architecture divides the single application into a small set of services, each running on its own but communicating with each other through APIs.

A service implements some of the features or functionality such as customer management, partner management and so on. Each of these services is mini-applications having their own hexagonal architecture. Such an architecture comprises of business logic. Out of these services, there will be some that would expose an API that’s consumed by some other microservices or by app’s clients whereas some others might just implement a web UI. At runtime, each instance is often a cloud VM or a Docker container.

Additionally, microservice architecture doesn’t just put each element of functionality into a separate service but also scales by distributing these set of small services across various servers and replicating them as and when needed.

Organizations such as Netflix and Amazon have started leveraging this new style of developing applications for some time now.

The concept of microservices is considered as a variant of the existing service-oriented architecture (SOA) architectural style that structures an application as a group of loosely coupled services. Software development teams that are interested in leveraging microservice architecture should ensure that the services are fine-grained and the protocols are lightweight.

Some of the design characteristics of microservice architecture include:

• Business Oriented
• Adaptable
• Autonomous
• Loosely Coupled
• Composable

Unlike monolithic architecture, microservices are project-agnostic providing business capabilities instead of functionality specific to a particular project on hand. This makes them reusable thereby reducing costs. Moreover, scaling up of individual services is much easier with microservice architecture than monolithic architecture. This is mainly because each service could be individually developed, replaced and scaled as needed. In monolithic architecture, it is not possible to scale in real time as all the functionalities are bundled together in one single artifact.

Eight Benefits of Microservices

After understanding microservices and differences between microservices and monolithic architecture; let us also look at the top benefits of microservices

1. Separate components – The Primary benefit of the microservice architecture is its loosely coupled components. These components can easily be developed, replaced and scaled individually.

2. Increased availability and resilience – Microservices improve fault isolation. As complex applications are broken into separate service components and deployed on multiple servers, failing of one of the services or modules will not impact the entire application. A single service fault can easily be replaced with another service (simple to build resilience around the small set of services) increasing the application’s availability.   

3. Easy to change technology stack – With microservices, software development teams can try a new stack on specific service to avail larger benefits at the application level. There is no long-term commitment to one particular stack as there are no dependency concerns. For example, recommendation micro-services can use python due to its machine-learning libraries against which event-processing micro-services may use Java due to the multithreading properties of jvm.

4. Easy to understand even in distributed environment – Understanding how an application is developed is important when there is a change of hand in development teams. In a distributed development project when some of the team members are geographically dispersed, microservice architecture make it easier for dev teams to understand the entire functionality of a service as it is not built into one single package.

5. Organized around business capabilities – Microservices are not organized around technical capabilities of a particular product, but rather business capabilities. As the end goal is user experience and customer satisfaction, the teams leveraging microservices are not divided into UI teams, database teams and so on. In fact, there are cross-functional teams that work towards fulfilment of one single functionality. Here’s a diagrammatic representation for quick understanding. 

Here’s a diagrammatic representation for quick understanding:

6. Re-usability of services – As microservices are organized around business capabilities and not a specific project or product requirement, they are project agnostic. This enables technology teams to reuse services and reduce costs.

7. Decentralized data management – Large scale and complex enterprise applications are normally three-tier. Martin Fowler, in his microservices article, describes that microservices let each service manage its own database, either different instances of the same database technology or entirely different database systems.  As he mentioned, this approach is called Polyglot Persistence.  

Here’s a diagrammatic representation for better understanding:

8. Easy to Deploy – While technology teams have to deploy an entire application again because of small change in the code, with microservices this deployment becomes easy. The scope of deployment is smaller and only the service that has a problem needs to be deployed again.

With more and more product companies now resorting to iterative development, it is crucial to have an underlying architecture which is robust, scalable and easily adaptable to real-time business needs. Microservices are surely the game changer. They not only improve the experience of development teams about building and understanding application but also improve the overall user experience of end users. Being able to improve fault isolation, even when one of the services fail, the application is still available to users which ensure a break free experience.

Learn more about building microservice architecture, setting up continuous delivery and other best practices in our second blog.