The road to Microservices architecture

ABF is growing fast. And healthy growth requires preparation to be ready for every new situation. On one hand, this requires extra manpower. On the other hand, you’ll need the right systems that can keep up with this growth. This is where our Developers come in. They must meet the constant demand for new functionalities. To get the most out of the available tools, we have decided to set up a Microservices architecture.

A bit of history

Let’s start with a bit of history, to get a better understanding of our baseline. The applications we have been using for a while now, are based on C# (.NET Framework 4.6.1) – a combination of MVC, API and console aapplications. A part of the DTAP-street was already used to roll out these applications – automatic roll outs to acceptance, and semi-automatic (by a press of a button) to production. A suitable basis for successfully carrying out daily activities.

“More Developers alone is not enough”

However, at the start of this year we decided that the development team has to deliver faster (and more) to keep up with the growing demand for new functionalities. With our current software design, team expansion alone is not enough to achieve the intended development speed. Fundamental changes are therefore necessary, like setting up a new architecture. Which is easier said than done. As Marc Matthijssen already mentioned in an earlier blog, Microservices also introduce complexity. But with a Microservices architecture like that it seems that we can meet the required development speed. All the more reason to take utmost care mapping out a follow-up process. How do we avoid the complexity of a Microservices architecture? Do we stop developing our current applications? Do we turn all our efforts towards new architectures? Impossible. After all, business still must go on.

Old and new, side by side

For that reason, we are looking for the solution in a different direction. We are aiming for an “and-and”-situation; a hybrid environment where old and new can coexist. We first create an environment where we can successfully run Microservices. This allows us to automate most of the complexity of Microservices architectures. This means the development team is relieved of the more tedious processes. Setting up a DTAP-street would be one of those processes. We also have to adapt the methods we’ve been using until now, to be able to embrace the concept of ‘continuous integration’. The main advantage: the moment a developer pushes his code it will automatically go to production. Quality gates ensure that the code meets our high standards. And from that moment on we can start transferring our processes from “old” to new.

“With Microservices architecture a commit from a developer can be pushed to production immediately”

We currently have the basis of our Microservices architecture in place. And already two major processes have been transferred: quotes and orders.

The blueprint of our methods is as follows:

• The Microservices are developed with .NET Core 3.1 (REST API, C#) – to ensure we are not dependant of a Windows hosting environment.
• Communications with and between Microservices go through a message bus – to avoid the services to be “hard” linked.
• We use Microsoft DevOps to set up the DTAP-street
• All of this runs in Kubernotes – in an Azure-cluster

We’re not there yet, but we’ve made great progress. And we will further develop our Microservices architecture and introduce new functionalities.

Help us built our new microservicce architecture?

We are looking for developers! You’re more than welcome to join us. See our vacancies for more information.