Microservices: A new approach to building applications

What is Microservices buzzword?

In today’s world, the fast changing demands in business are driving to adopt an application architecture model called “microservices”. Microservices architecture describes a particular way of designing software applications as suites of independently deployable single purpose service. This architecture style definition is provided by James Lewis and Martin Fowler.

Most of us are already aware of software design concepts like

• Decomposition
  • Promotes separation of concerns
  • Promotes reuse
•  Shared libraries
•  Components
  • Process isolation – ability to host a component in its own process space.
• SOA
  • Services instead of components

Microservices approach is “fine-grained SOA”, an approach of small service instead of monolithic with a single focus. It’s based on a subset of SOA principle – “Single responsibility”.

In contrast to SOA, microservices gives an answer to the question – how big a service should be and how they should communicate with each other? In a microservices architecture services should be small and the protocols should be lightweight. It is an approach to build an application as a set of small single purpose services, each service running in its own process and communicating with each other via lightweight protocols such as HTTP.

Examples of microservices can be protocol gateways, user profiles, shopping carts, inventory processing, purchase order subsystem, payment processing, and queues and caches.

In a recent article from a movie marketing company called MOVIO, they talk about some of the benefits of this microservices architectural style:

• easier continuous delivery
• finer grained scalability
• the team maintains an ongoing relationship with the product
• each service can use a technology set that is best suited to its purpose
• makes it easier to incrementally evolve the product

Source: Microservices: How we walk the walk with Movio Media

Movio found microservices architectural significantly simpler for their analytics-heavy system – Movio Media. Movio Media is a web application, and the system consists of about 20 microservices, each running with multiple instances in production. All of these microservices communicate via JSON over HTTP and run behind load-balanced routers which dispatch requests to the appropriate docker containers on the host.

Traditional 3-tier monolithic application model

The classic three-tier model, with web, business logic and data tiers is shown in the figure below. Due to tight coupling of application services within tiers this model have very little advantage of decomposing application in three tiers.

A change to any application service, even small ones, required its entire tier to be retested and redeployed. Different modules and services are tightly coupled and any failure could affect the whole system.

When load caused an application to outgrow its hardware, the typical answer would be typically to “scale up,” or upgrade the application’s hardware to add capacity which most of the time requires duplication of whole tier. Also a simple update could have unforeseen effects on the rest of the tier, making changes risky and lengthening development cycles to allow for more rigorous testing.

These all limitation can impact the efficiency and agility in any monolithic application model.

Microservices approach to application development

Microservices are a different approach to application development and deployment that caters agility, scalability and reliability requirement to modern application.

A microservice application is decomposed into independent components called “microservices,” that work in concert to deliver the application’s overall functionality. Each microservice typically encapsulates simpler business functionality, and they can be scaled up or down, tested, deployed, and managed independently.

Key benefits:

• Agility
• Autonomous
• Single Responsibility – strong cohesion and loosely coupled.
• Technology, programming language or platform agnostic
• Developed, deployed and updated independently
  • Enables continuous integration and continuous development practices, and accelerates delivery of new functions into the application.
  • Enable superior maintainability in large, complex and highly scalable systems by designing applications based on many independently deployable services that allow for granular release planning.
• Independently changeable – As long as you don’t break the contracts or interfaces, you can change any microservices implementation under the hood and add new functionality without breaking the other microservices that depend on it.
• Scaled independently
  • Instead of having giant monolithic application blocks that you must scale out at once, you can instead scale out specific microservices.
  • Failure of one microservice does not cascade to other parts.

One important benefit of a microservices approach is that development teams tend to be more driven by business scenarios which means that smaller teams develop a microservice based on a customer scenario, by using any technologies they choose. Further, individual teams that own services can do what makes sense for them based on team expertise or what’s most appropriate for the problem that service is trying to solve.

Microservices approach vs Traditional approach

In microservices approach it’s all about efficiency for agile changes and rapid iteration, which enables you to change specific, small portions of large, complex and scalable applications.

Source: https://msdn.microsoft.com/en-us/magazine/mt595752

Also microservices must own its domain data and logic under an autonomous lifecycle, with independent deployment per microservice

The traditional approach used in many applications is to have a single and centralized database like a normalized SQL database for the whole application and all its internal subsystems, as shown in above figure.This approach looks initially simpler and seems to enable re-use of entities in different subsystems to make everything consistent. But the reality is you end up with huge tables that serve many different subsystems and include attributes and columns that simply aren’t needed in most cases.

Stateless microservices

• State is external or non existing
  • In the case of stateless microservices, the databases will be external, employing relational options like SQL Server or NoSQL options like MongoDB or Azure Document DB.
  • The services themselves can be stateful, which means the data resides within the same microservice. This data can exist not just within the same server, but within the same microservice’s process, in-memory and persisted on hard drive and replicated to other nodes.
• Multi-instance and parallel execution
• Load balancing

Stateless is a perfectly valid approach and easier to implement than stateful microservices, as it is similar to traditional and well-known patterns. But stateless microservices impose latency between the process and data sources, while also presenting more moving pieces when improving performance via additional cache and queues. The result can be a complex architectures with too many tiers.

Stateful microservices

Stateful microservices, can excel in advanced scenarios, as there is no latency between the domain logic and data. Heavy data processing, gaming back ends, databases as a service, and other low-latency scenarios all benefit from stateful services, which enable local state for faster access.

• State is stored within the service
• Reliability is achieved by creating replicas on multiple nodes

One drawback in case of stateful services can be the level of complexity in order to scale out. Functionality that would usually be implemented within the external database boundaries must be addressed for things such as data replication across stateful micro­services replicas, data partitioning and so on.

Conclusion

If you want to build applications with more control and flexibility that enable you to focus on delivering business value in an agile way then you can consider building your application using a microservice approach.

The microservice architecture breaks down an application into small, independently executing microservices resulting in the following benefits:

• Agility
• Autonomous
• Single Responsibility principle – strong cohesion and loosely coupled.
• Developed, Deployed and updated independently
• Scaled independently

But microservice architectures have a higher degree of complexity which requires a PaaS layer to effectively deploy and manage them at scale. This can be handled by using Azure Service Fabric as a microservice platform. Service Fabric provides the plumbing needed to create, deploy, run, and manage microservices in an effective and efficient way.

Resources:

https://azure.microsoft.com/en-us/documentation/articles/service-fabric-overview-microservices/

https://msdn.microsoft.com/en-us/magazine/mt595752.aspx

http://movio.co/blog/microservices-walk-walk-movio-media/?utm_content=buffere7738&utm_medium=social&utm_source=linkedin.com&utm_campaign=buffer