Centric connect.engage.succeed

Microservices, a small step or a giant leap?

Geschreven door Renzo Veldkamp - 12 december 2016

Renzo Veldkamp
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.

MicroservicesTech Days 2016 logo

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.

RabbitMQ logoRoy 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.

Logo NServicebus MSMQ en WindowsMicroservices’ 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:

Part 2 of this blog

Microsoft and open-source software: welcome!

Craft Expert Renzo Veldkamp is part of the .NET team within Craft, the development programme for IT professionals (powered by Centric). If you would like to follow his blog, sign up for Craft updates.


Next to subjects like .Net, Azure and DevOps, the TechDays program covered topics that are not specifically for Microsoft, like front-end technology, IoT, SCRUM, Open Source Software and robotics.

In order to keep this article concise, it is part of a sequence of 3 articles. This is the first part: it’s about microservices.

<h2>Microservices

The term microservices is a real buzz word. Microservices are small units of software, so you could end up with a giant amount of them.

Expectations of applications built using the microservices architecture are high, as if they are a holy grail. Microservices offer a giant number of benefits like the increased scalability, maintainability and robustness of your application.
However, they come at a cost. There are concerns like the determination of the scale of a microservice (how small should it be?), the division of functionality over the microservices (what function to put into which microservice) and the increase in deployment effort.

rabbitmqmasstransit-logoSander Hoogendoornpointed out that these are the reasons that microservices won’t be the perfect application architecture for every team, project or company.
A microservices based application is not a single unit anymore, but a bundle of smaller units. Each one of these units has a separate (therefore, independent) code base implementing a smaller, more concise piece of functionality. This offers the advantage of easier testing and easier maintenance, but each unit has to be configured and deployed separately. An end user action may involve many separate actions in different units, so you need to figure out a way of tracking these actions in order to be able to investigate issues in your environment.
You also need to ensure that all these units are perfectly aligned (both functionally and technically) in order to make the application run smoothly.

When maintenance of your application has become problematic because 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 gradually migrating 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 for the next piece of functionality.

This approach lowers the impact of the changes involved and enables the team to get familiar with the concept of microservices. Gradually, the application is migrated to a microservices architecture. It proved to be a helpful approach forVincent Lesierse.

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

In order to achieve this, you need some sort of messaging bus. This introduces a small overhead that could introduce a giant 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. It strongly depends on the functionality and how it is divided over the microservices.

The two messaging bus systems that are often used in a microservice architecture are:

·        Rabbit MQ, together with a .Net-API: EasyNetQ or MassTransit. These products are all available with an Open Source license.

·        Microsoft MQ or Azure Service Bus, together with the commercially available product NServiceBus

These bus systems have comparable functionality, so which one to choose depends on other requirement. When your microservices will run on Azure, you’ll most likely choose Azure Service bus. When running on premise on a Windows platform you may feel more comfortable using MSMQ, but Rabbit MQ runs on Windows just as well.

Rabbit MQ uses the AMQP protocol, which proved to be the solution toHenry Been’s high messaging throughput problem. His application had to handle a giant load of (small) log messages which had to be delivered to a SQL datawarehouse as quickly as possible.

The independence of a microservice from another allows for a giant number of possibilities, compared to an application consisting of a single codebase. 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, the other one can use a noSQL database.
Microservices don’t even have to run all on the same operating system (although this adds a new bundle of skills to your development team). When your (.Net based) microservices need to be portable to different operating systems, you could host each one of you microservices (together with its own Windows Core OS instance) in a Docker container, like
Alex Thissen and René van Osnabruggepointed out. The result is a highly flexible application (consisting of a giant number of small components).

<h2>The sessions

I attended the following sessions on microservices:

·        Vincent Lesiersehttps://channel9.msdn.com/Events/TechDays/Techdays-2016-The-Netherlands/Migration-to-microservices-in-practice

·        Henry Beenand 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

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.

<h2>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 Hoogendoornpointed 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 forVincent Lesierse.

Roy Cornelissenindicated 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 toHenry 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 Osnabruggepointed 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.

<h2>Sessions

These are the recordings of the sessions about microservices:

·        Vincent Lesiersehttps://channel9.msdn.com/Events/TechDays/Techdays-2016-The-Netherlands/Migration-to-microservices-in-practice

·        Henry Beenand 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

 

This article is continued in part 2: <link naar artikel part 2>.[TJ1] 

About Renzo   Craft Expert Renzo Veldkamp is part of the .NET team within Craft, the development programme for IT professionals (powered by Centric). If you would like to follow his blog, sign up for Craft updates.


 [TJ1]Toevoegen als deel twee erop staat

Tags:.NET

     
Reacties
    Schrijf een reactie
    • Captcha image
    • Verzenden