Completely renewed back-end in BlueDolphin:
How does that work?
In 2014, life was first given to “BlueDolphin”. Ever since, as you have probably all noticed, much has been changed and improved. The interface has been transformed step-by-step, numerous functionalities have been added and a completely new module has been added in the form of BPMN. The BlueDolphin hosting is basically the only thing that has remained the same.
In 2014, we chose to host BlueDolphin using Cloud Services on Microsoft Azure because this was the best option at the time to make the software somewhat scaleable. At the time the Azure portal look like this:
Cloud Services… a Cloud Service can consist of one or multiple Virtual Machines. You can scale these when you need less or more capacity. Ideal, it would seem, but that is always a manual and time-consuming job.
That was the way the ValueBlue development team has ensured sufficient capacity over the past years. This was labour-intensive and there was ‘waste’ because we had to estimate the maximum client requirement per period; we could not scale up or down ‘on-demand’ without it taking a lot of working hours.
We split the Cloud Services into logical groups to set up the work around BlueDolphin and development as effectively and scaleable as possible. This was better. It meant that we could scale the individual components up or down. Over the years, this turned into fourteen Cloud Services, all having at least two Virtual Machines. But when we looked more closely at the Virtual Machines, these turned out to have a lot of additional resources (CPU/Memory). Space that we paid for, but that remained unused.
Around 2015, Microsoft announced that they would be providing the Microservices Platform Service Fabric to all their Azure customers in 2016. This Service Fabric platform seemed to better fit our needs to scale more effectively. BlueDolphin consists, as described earlier, of different groups of resources, or multiple ‘(micro)services’. We researched the possibilities and concluded that a transfer from Cloud Services architecture to the Service Fabric architecture would be beneficial.
To make the change to the Service Fabric architecture run smoothly, it was necessary to simultaneously work on two so-called codebases. We chose the ‘lift and shift’ approach for this. We wanted to keep the codebases in Service Fabric Services and the Cloud Services as similar as possible to implement the new functionalities and resolved bugs easily and relatively fast in both environments. In return, this means we had to keep two codebases up to date lately. This has affected the amount of work and, in doing so, the development speed.
What are the benefits of Service Fabric?
As indicated before, we had approximately 28 Virtual Machines that kept the Cloud Services going. Service Fabric uses fewer Virtual Machines; at this moment, our development team uses five Virtual Machines in their production environment. In addition, we can:
- Scale the number of Virtual Machines of the cluster;
- Scale the number of BlueDolphin (micro)services.
These two actions can be carried out automatically. The Microsoft platform ensures that the services are spread evenly over the available machines. Where scaling up and down took a relatively long time in the previous situation, thanks to Service Fabric, it only takes a couple of minutes the moment we change something in terms of capacity and/or use.
In the old situation, communication between the different BlueDolphin services ran via a service box. This service box has, depending on the chosen type, a delay. This could result in delays. Now, in the Service Fabric cluster, the services communicate directly with each other. This means we are less bothered by delays and that BlueDolphin responds more quickly.
We are better able to separate configuration and code. We work with releases for this (with the help of Visual Studio Online) and are better able to test builds/features independently of each other. So we can build, test and release in smaller pieces instead of the large blocks that were necessary before. This means we can offer new functionalities to our customers more quickly in the future and also implement improvements faster.
Service Fabric supports a working method called ‘Rolling Updates’. This means we can upgrade service(s) and releases for the customer without any noticeable effects. In theory, we will implement certain releases at any given moment from now on without downtime and without noticeable impact for the end user.
The transfer from the old Cloud Services to the Service Fabric platform was a large step. We worked hard on this with the development team. Now it is time for optimization, so we can, for instance, scale even more precisely.
In the meantime, ValueBlue has converted all BlueDolphin environments to the new back-end in batches based on Service Fabric. The results are very good. The performance has improved and the conversion of the BlueDolphin environments has been achieved almost without anyone noticing. For the foreseeable future, the focus will be entirely on the development of new functionalities; ones that we are now able to test and implement even faster and better.