Migrating to a serverless solution using Azure Functions

We recently relaunched the AMBER application which was still running on older systems. Although this was no problem, the systems were very difficult to maintain. Therefore, one of the things that needed to be addressed was upgrading the architecture and systems. These had to be future-proof and achieve the quality standards we strive for so much with Endare.

The old Windows Tasks were one of the major problems within the application. During testing, it turned out that they were very unreliable. Furthermore, they took up a lot of resources, which meant that the virtual machine ran at a higher cost even when no tasks were running. Because of this, we decided to upgrade the virtual machine to the next level to make sure the service would not eventually fail. Enter Azure Functions.

First things first, what is a serverless architecture?

What is a serverless solution? Isn't all code normally run on a server somewhere anyway?

Yes, but the difference lies in how it is managed. With a conventional setup, the code is deployed on a server that you manage yourself. This can be a virtual machine hosted in the cloud or a physical server sitting in the corner of the office. With a serverless architecture, you don't have to worry about a server running the code. There is little to no overhead when it comes to server maintenance, architecture and scalability. In an ideal situation, you write the code and can deploy it immediately to the serverless solution. Done.

There are many providers in the market for these serverless architectures. The main competitors are Microsoft Azure with Azure Functions, AWS Lambda from Amazon and Google Cloud Functions. Over the years our developers have become familiar with all three and even some lesser known serverless architectures.

At AMBER, we have chosen to use Azure Functions to replace the outdated Windows Tasks. The reason for choosing this particular provider was quite simple. The entire tech stack and architecture was Microsoft based and hosted on Azure. It was a no-brainer to continue working on this, especially from an integration standpoint.

Why we chose a serverless solution like Azure Functions

Why would we choose Azure Functions over the older Windows Task? The older ones were already up-and-running and working, so it could be argued that the extra effort that would go into migration and testing would not outweigh what we could gain. Nevertheless, we've chosen to invest in this effort for several reasons.

The main reason is reliability and scalability. The old setup meant that the resources of the server were shared among multiple clients. When we wanted to set up a new client, it meant that we also had to make sure that the underlying infrastructure had sufficient resources to keep working properly. As a result, we had to scale the server in its entirety. Because of this, even when there were no tasks in progress, we had to pay full price for all unused resources.

On the other hand, when we wanted to run multiple tasks, it was possible that the infrastructure did not have enough resources to run everything properly. As a result, tasks could prevent themselves from being executed. At Endare, we strive to provide the highest possible uptime for the customer, and these old tasks meant that these uptime standards were not guaranteed. An hour of downtime could mean a lot of additional manual work for us and extra costs for the customer.

The benefits of our migration to Azure Functions

After a few months, we were able to thoroughly evaluate this new approach. From this evaluation we can draw the following conclusions.

Thanks to the migration from the old Windows Tasks, our system works a lot more efficiently because each client has its own container of functions. As a result, the system can scale based upon the needs of each individual client which substantially improved our uptime. So far, the implementation is much more reliable and performant than its predecessor.

We also noticed that this had a major impact on the costs associated with this particular side of the infrastructure. From now on, we only pay for the resources we actually use and not the latent resources that do nothing. From the monetary point of view alone, it was worthwhile to carry out the migration.

And finally, thanks to the serverless solution, we were able to set up extensive logging much easier. This way, we detect downtime immediately when it occurs.

A difficult road, but nothing we can't handle

We would be lying if we said that the road to a serverless solution is easy. There are also some slight drawbacks with this migration. These are very minor, but it is nevertheless necessary to mention them.

A migration from a legacy system to a new version always brings difficulties. A lot of time was spent linking the old code to the new architecture. This was very time-consuming and took a lot of elbow grease. Nine times out of ten, the problems were very specific and there was not much information available.

For this, we had to find custom solutions and dive deep into the underlying architecture of the serverless provider. This could be very frightening for someone who is not familiar with the matter. Fortunately, we could rely on years of experience, making it easier for us to tackle these problems successfully!

To conclude...

The migration to a serverless architecture has its own specific use cases and is not always suitable for every part of your infrastructure. Sometimes you may need or want to keep your own server infrastructure. In our use case, however, we needed to be able to scale on demand and reallocate resources. Above all, our architecture had to be really reliable. This made the serverless infrastructure of Azure Functions the ideal match. The migration has proven to be worthwhile both financially and in terms of customer satisfaction.

Curious to find out more about our back-end services? Or would you like to talk to us about your digital project? Feel free to contact us via our contact form. Our experts are happy to meet with you.