Divide and conquer – The Microservice approach

If there’s a phrase that has being always present and reinventing itself in the programming world, that phrase is “Divide and conquer”. In the first years of programming languages, it was about dividing the spaghetti code into small reusable chunks encapsulated in procedures or functions.

With the object oriented programming model, the meaning of the phrase took another step in the modeling of systems. It was about separation of concerns, encapsulation, decoupling and modularization.

Many years passed since this phrase was first used. In those years, technologies, patterns and methodologies have evolved and many new concepts appeared. But don’t worry we are not reinventing the wheel or doing something different from what we have learnt years ago.

Globalization has changed the way we model our systems.

Old fashion way	What’s new
Cascade programming model.	Agile methodologies (Scrum, Kanban, Business driven development).
Development team on same location.	Distributed teams. Reduced team size (6 or 7 developers).
Testing was made by developers (and functional users)	Unit testing frameworks. Continuous integration. Test driven development.
Three tier applications (Data, logic, front end).	Multi-tier applications. Integrated systems. Multi interface applications. Fine-grained SOA.
System deployed onsite.	System deployed on the cloud. Highly available. Auto scaling. Geo-replication.
One single technology for the whole system.	Decoupled APIs, with technology agnostics interfaces.

 

What is a Microservice?

The shortest description of a Microservice is that it does one thing and it does it very well.

We can go a little deeper in the definition and state this:

• It’s autonomous, which means that a microservice is a self-contained unit of functionality. A unique location (URL) identifies it.
• It’s isolated, so we can modify it, test it and deploy it without impacting other areas of the solution.
• It’s elastic. A microservice can be stateful or stateless and can be scaled independently of other services.
• It’s resilient. A microservice is fault tolerant and highly available.
• It’s responsive, meaning that it responds to requests in a reasonable amount of time.
• It’s message oriented. Microservices rely on asynchronous message-passing to establish a boundary between components.
• It’s programmable. This is easy thanks to the provided API’s for access by developers and administrators and Applications are composed from multiple microservices.
• It’s automated, meaning that the lifecycle of a microservice is managed through automation that includes dev, build, test, staging, production and distribution.

 

Microsoft states that we should look at each Microsoft microservice not just as a REST API but as a product, so it has a well-defined set of capabilities, it has a programmable interface, it has a data contract, it has documentation and they are also configurable. We have available a public API but there is the option of having an Administrator API which you can use for providing metrics or configuration settings and typically there’s also a user interface associated with that configuration, all this wrapped up, so it isn’t just a REST API.

Comparison between application development approaches

Azure Service Fabric – Microsoft’s Microservices offer

To support their own internal evolution from on-premises to cloud and from monolithic to microservice-based applications, Microsoft developed Service Fabric over ten years ago. Service Fabric powers many of their hyper-scale cloud services, including SQL DB, DocDB, Intune, Cortana and Skype for Business, as well as many internal Azure infrastructure services.

They’ve taken the exact same technology and released Service Fabric as-a-service on Azure, and the standalone SDK will enable the deployment of Service Fabric applications in on-premises clusters and on other clouds. Service Fabric has built-in support for lifecycle management, hybrid deployments, and 24×7 availability with integrated development experiences using Visual Studio.

The platform offers extensible health models for both the infrastructure and microservices to enable automated health-based upgrade and automatic rollback, simplifying DevOps. Furthermore, Service Fabric supports both stateless and stateful microservices with leadership election to support data consistency and a state replication framework that supports transactions for stateful data guarantees.

As Microsoft says

The aim of Service Fabric is to solve the hard problems of building and running a service, such as failures and upgrades, and utilizing infrastructure resources efficiently, so that teams can solve business problems using a microservices approach.

 

By using Service Fabric, you can:

• Develop massively scalable applications that are self-healing.
• Develop applications composed of microservices, using the Service Fabric programming model, or simply host guest executables, and other application frameworks of your choice, such as ASP.NET Core 1, Node.js, etc.
• Develop stateless and stateful microservices and make these highly reliable.
• Simplify the design of your application by using stateful microservices in place of caches and queues.
• Deploy to Azure or to on-premises clouds running Windows Server or Linux with zero code changes. Write once and then deploy anywhere to any Service Fabric cluster.
• Develop with a “datacenter on your machine” approach. The local development environment is the same code that runs in the Azure datacenters.
• Deploy applications in seconds.
• Deploy applications at higher density than virtual machines, deploying hundreds or thousands of applications per machine.
• Deploy different versions of the same application side by side, each independently upgradable.
• Manage the lifecycle of your stateful applications without any downtime, including breaking and nonbreaking upgrades.
• Manage applications using .NET APIs, PowerShell, or REST interfaces.
• Upgrade and patch microservices within applications independently.
• Monitor and diagnose the health of your applications and set policies for performing automatic repairs.
• Scale up or scale down your Service Fabric cluster easily, knowing that the applications scale according to available resources.
• Watch the self-healing resource balancer orchestrate the redistribution of applications across the Service Fabric cluster to recover from failures and optimize the distribution of load based on available resources.

 

Two ways to go with Azure Services Fabric

The first one is using a set of services as a platform to take care of deployments, upgrades, detecting and restarting failed services, discovery of where services currently are running, state management, health monitoring, etc. These services are in fact microservices.

The second approach is through programming APIs and frameworks that allow the developer build applications as microservices. You can get more information about this model here (https://azure.microsoft.com/en-us/documentation/articles/service-fabric-choose-framework/)

 

Are Microservices the silver bullet for all your problems?

Well, the answer is no. As any other approach, this has pros and cons to take in consideration when defining the architecture to use.

Pros	Cons
Scalable	Network latency increased by the messages interchange.
Reduce deployment costs	Deployment and testing complexity increase exponentially based on the number of interaction between services.
Can be developed by a small team.	Too fine grained microservices may create an overhead that outweighs its utility.
Team only has to be aware of the business logic that represents the service and its interactions.	Message formats, restrictions, and interactions knowledge is needed.
Continuous deployment.	Must pay lot of attention in versioning because of the interaction with older version of other services.
Use the technology you prefer to create it.	Transactional operations that goes through the boundaries of many microservices increase the logic complexity.

 

When should I use Microsoft Microservices?

• You are planning to create an application in the cloud, and you need scalability, high availability, geo-replication.
• You want to create an application that will change in the near future based on the business needs, for example using Lean Startup technics for your site.
• You want to reduce your system maintenance costs by moving it to the cloud.
• You have distributed teams working on the development of your system.

 

At Art2Link we have being working on Mircoservices solutions using Microsoft Azure and Service Fabric technologies.

If you want to know more about this approach, stay tuned for our next post about Microservices in Azure or contact us and one of our experts will help you to get started.