Microservices, a small step or a giant leap?

The term 'microservices' is a real buzz word. Expectations of applications built using the microservices architecture are high - they are almost treated like the Holy Grail. Are microservices a small step, or a giant leap forward?

This year, the Microsoft TechDays programme covered a huge number of topics. The sessions I aimed to attend were based on the following topics:
* Microservices (including bus technologies)
* Open-source software (Angular2, JS tools)
* New .Net features (e.g. C# 7, .Net Core and ASP.Net Core)

In order to keep this article concise, it is part of a series of three separate articles. This is the first part, about microservices.

Microservices
Microservices offer a giant number of benefits, for example increased scalability, maintainability and robustness of your application. However, they do come at a price. There are concerns about accurately determining the scale of a microservice (how small it should be), dividing the functionality between the microservices (which function to assign to which microservice) and the increased deployment effort.

Sander Hoogendoorn pointed out that these are the reasons why microservices won’t be the perfect application architecture for all teams, projects or companies.

If you base your application on microservices, it is no longer a single unit, but rather a bundle of smaller units. Each one of these units has a separate (and therefore independent) code base that implements a smaller, more concise piece of functionality. This offers the advantage of easier testing and maintenance. However, each unit has to be configured and deployed separately. An end-user action may involve many separate actions within different units, so you need to figure out a way of tracking them in order to be able to investigate issues occurring in your environment.

You also need to ensure that all of these units are perfectly aligned (both functionally and technically) in order to make the application run smoothly.

If maintenance of your application is proving to be problematic, as it has changed into a monolithic set of ‘spaghetti code’, you may decide to turn it into a microservices-based application. Starting from scratch and rebuilding the complete functionality is often out of the question. A good approach is therefore to gradually migrate your application. Just take a small, clearly bound piece of functionality and build a microservice for it. Disable the functionality in the existing application and connect to your microservice, either using a RESTful service or a messaging bus. After deploying these changes to your live/production environment, repeat these steps for the next piece of functionality.

This approach lowers the impact of the changes involved and enables the team to familiarise itself with the concept of microservices. Gradually, the application is migrated to a microservices architecture. This has proved to be a helpful approach for Vincent Lesierse.

Roy Cornelissen indicated that a microservices architecture results in a distributed application in which the components should be temporally unrelated: one service should not have to wait for another service, which would result in a time dependency.

In order to achieve this, you need some kind of messaging bus. This will introduce a small overhead that could trigger a massive delay in the application’s response. You need to decide whether to use a small number of giant messages or a giant number of small ones. This is highly dependent on the functionality and how it is divided over the microservices.

The two messaging bus systems that are often used within a microservice architecture are:
* Rabbit MQ, together with a .Net API: EasyNetQ or MassTransit. These products are all available with an open-source licence.
* Microsoft MQ or Azure Service Bus, together with the commercially available product NServiceBus.

These bus systems have comparable functionality, so the one you choose depends on your other requirements. If your microservices are going to run on Azure, you should go for Azure Service Bus. If they are to run on a Windows platform, you may feel more comfortable using MSMQ, but Rabbit MQ also runs on Windows just as well.

Rabbit MQ uses the AMQP protocol, which proved to be the solution to Henry Been’s high messaging throughput problem. His application had to handle an enormous number of small log messages, which had to be delivered to a SQL data warehouse as quickly as possible.

Microservices’ independence allows for many possibilities, compared with an application consisting of a single code base. Each microservice can use its own type of storage and its own data access technology. One microservice can use Entity Framework to access data in a SQL Server database, while another one can use a noSQL database.

Microservices don’t even all have to run on the same operating system (although this would add a new bundle of skills to your development team). As Alex Thissen and René van Osnabrugge pointed out, if your .Net-based and other microservices need to be portable so that they can be moved to different operating systems, you could host each of your microservices (together with its own Windows Core OS instance) in a Docker container. The result is a highly flexible application consisting of a huge number of small components.

Sessions
These are the recordings of the sessions about microservices:
* Vincent Lesierse – https://channel9.msdn.com/Events/TechDays/Techdays-2016-The-Netherlands/Migration-to-microservices-in-practice
* Henry Been and John Hoang - https://channel9.msdn.com/Events/TechDays/Techdays-2016-The-Netherlands/Building-a-simple-high-throughput-messaging-infrastructure
* Roy Cornelissen - https://channel9.msdn.com/Events/TechDays/Techdays-2016-The-Netherlands/Building-Microservices-in-NET-with-NServiceBus
* Sander Hoogendoorn - https://channel9.msdn.com/Events/TechDays/Techdays-2016-The-Netherlands/Thirty-months-of-microservices-Stairway-to-heaven-or-highway-to-hell
* Alex Thissen and René van Osnabrugge - https://channel9.msdn.com/Events/TechDays/Techdays-2016-The-Netherlands/How-Docker-and-ASPNet-Core-will-change-the-life-of-a-Microsoft-Developer