December 3, 2017 Syed Shah

Microservices architecture in plain english

Over the past few years, the term Microservices has become very popular. In this post I will try to explain Microservices as simply and concisely as possible. As with my previous posts, the purpose is to give readers a head start and then the hope is that we all could take our learnings from this effort and build on it.

Relation with SOA

In my opinion, Microservices are an evolution of SOA. Alot of the techniques we use here have actually grown from our experiences from SOA. Thus while going through this article if you find yourself wondering that this is the same as in SOA then don’t get confused; since Microservices are an evolution of SOA there will be alot of similarities.

When I read up on Microservices, I realized that I was already designing systems using Microservices concepts, without even formally learning about them. I don’t think this will be a unique case and expecting that alot of my other industry colleagues would realize the same.

Characteristics of Microservices Architecture

Note that there is no formal definition of Microservices architecture, hence interpretations vary. However there are some common characteristics which we can document. These are:

Components are services

Traditionally while an application was broken down into components, they still resided within the same process. We would create shared libraries/packages and would link them into the main programs.

In Microservices, components are treated as services, hence they reside out of process and are independently deployed and managed.

Based on the Enterprise’s core business functions

Microservices teams are built and organized such that each team supports their organization’s one or more business capabilities.

This implies that the teams owning the Microservices for a specific business capability are cross functional; thus they will own the UX, backend, persistence, reporting etc all aspects required to build and support the particular business capability.

Products based culture

Microservices proponents think in terms of products rather than projects. Project based culture constitutes breaking a feature into multiple projects and than assigning each project to teams with relevant expertise. The outcome from each team is a deliverable, but not a product.

In contrast, Microservices based teams build and own products. i.e they are responsible for all aspects; delivery, deployment and support.

Dumb Communication Channels

In contrast to SOA, in Microservices, the communication fabrics are dumb, hence unlike ESBs they do not provide any complex routing, dispatching, transformation etc. It is for this reason that most Microservices communication channels are built using the simple REST protocols rather than the more sophisticated and complex WS-Choreography.

Hetrogenous Systems

Since components become independently deployable out of process services, implementations enjoy the flexibility of selecting the right set of tools and languages best suited for the specific function they perform. For example an application could have a Node.js based service to allow customers to view and download their reports while a python based service to ingest and prepare data to feed into a Hadoop cluster for aggregation.

Independent Data Management

Each service independently manages its own snapshot of persistent data. Therefore just as we can select the right programming language best suited for the specific task, similarly the service developers have complete autonomy to select the right data management system best suited for the service’s needs

Handling of Failures

Deploying components as independent services does have consequences; one of them being that systems need to be designed considering the fact that at any given time any service could fail. This does indeed adds design complexity and implementation of additional monitors, alarms and remediation processes to guard against catastrophic events.

Flexible Design

Microservices are inherently flexible to accommodate future changes. This is because it is easier to make changes to an independent service compared to a huge monolithic application. Changes in one component (service) doesn’t enforce full application deployment, rather only deployment for that particular service is required.


Share this...
Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedIn
Tagged: , , ,

Leave a Reply

Your email address will not be published.

Contact Us

Get in touch to schedule your FREE consultation!