Why the migration to PaaS with Azure Cloud is such a big step
In software development, it’s normally a good idea to develop more layers of abstraction over time to hide complexity and create a platform that is closer to the end-product. This benefits the user because it results in a stable application.
It also benefits developers, because it means reduced administration, fewer issues with complexity while developing the product, and the ability to focus on product development rather than infrastructure. Code development, rather than server administration, is our specialization, and I believe we should keep it that way.
Leveraging from this “high-level” infrastructure, using abstraction to hide hardware and system administration processes, allows us to focus on product development.
That’s been the philosophy behind our infrastructure from the start, and was one of the reasons behind our migration to Azure Cloud Services.
The old days — choosing virtualization
In 2008, I began development for the Nmbrs product. We had a small team of developers and no system administrator (back then, our DevOps were called sysadmins).
At the time, it was standard to buy/rent servers in a hosting firm, set up networks and racks, and then install the OS, web servers, and database engines so you could run your application. Installing physical hardware naturally creates extra maintenance and risks of hardware failure. After all, who wants to have a burnt disk in the middle of the night? For a small software firm, installing server hardware was a huge side step from our primary purpose, product development.
Luckily, virtualization was already maturing as a technology. Against the recommendations of many experts, we embraced it. I decided to use virtual machines (VMs) rather than physical hardware.
The modern era — from Iaas to PaaS
Our product ran on VMs for many years. This was logical, as VMs was the most high-level technology available at the time. But, like any innovative company, we continuously assessed our tech stacks and watched new trends. It was during this stage I first noticed Platform-as-a-Service infrastructure.
PaaS allows development teams to deploy their application to a platform, without the need to manage a VM. (On-premise) IaaS infrastructure requires managing the OS, web server, and configurations to even run the application, PaaS doesn’t.
PaaS also means that you pay for computing time, rather than simply having a VM running. The nature of our application means users very much log on during business hours and during payroll peaks (last week of the month), so it’s important that our infrastructure adapt to these changing needs. With IaaS, it’s difficult to scale resources up and down, but Azure Cloud is designed for it. This meant we could scale resources whenever needed to provide the best-possible user experience. It very much fit our “high-level” vision for our infrastructure — we needed to take this step!
Microsoft, AWS, and Google Cloud were a few of the available options at the time. We work with Microsoft.NET, so Azure was a logical choice. We began running pilots for our large enterprise application from about 2014, and in 2016, we decided Microsoft Azure was mature enough for us.
Going all the way (to PaaS)
Migrating to a new infrastructure is a very risky step. Infrastructure is the foundation of our product. A badly configured infrastructure can cause many issues with performance and instability. I wanted to take it slowly and make the best possible decisions for our users and our future.
Here, many tech teams prefer a conservative approach known as “lift and shift”, where you directly move your VMs to the Azure Cloud. This wasn’t my first choice for Nmbrs, because it means you’re still using IaaS technology. I wanted to evolve our infrastructure to PaaS.
This greatly complicated our migration. Rather than simply migrating to a new data server, we had to migrate VMs with Windows Server and SQL Server to Azure App Services and SQL server. Our tech team was naturally very excited with changing over to a completely new technology.
We also ran into problems, especially with the (in)famous 230 second timeout limit and the SQL connection limit. We had to refactor our application to overcome limits that didn’t exist on VMs.
After using a PoC to prove that our application could fully run on Azure cloud services, we started the process of designing and implementing a new infrastructure from the ground up. This process naturally involved tests to assess load, performance, and stability, and when the tests were very positive, we were ready to migrate our customer’s data.
Migrating to Azure was a project requiring several months. Nmbrs is a complex program with a lot of data and components, and we had to migrate in a way that did not disrupt service. Those “in-between” moments, where we were running two infrastructures was difficult to manage. Both infrastructures needed to communicate, because components were on both sides. This naturally resulted in temporary instability and performance problems for the application.
Eventually, our teams successfully migrated around 50 VMs to run on Azure cloud services, fully moving Nmbrs from IaaS to PaaS.
The benefits of Azure Cloud
Moving to Azure Cloud was a big step, not just in terms of the physical move, but also in terms of technical capability and possibility. For example, Azure means we are able to adjust capacity to quickly meet user needs, which means better performance, especially during peak moments.
However, the prime benefits lie in how developers actually perform work. Azure, and PaaS, creates a completely new layer of abstraction, intrinsically changing how teams operate. In the past, we needed system administrators to maintain virtual machines. Today, our developers can simply handle everything automatically, enabling a seamless move to full DevOps.
Administration and maintenance requirements are almost fully managed by Azure. Our DevOps engineers focus on task automation rather than manually changing settings. This results in a better quality of infrastructure, as our components are configured by scripts, with no room for manual error.
Leveraging a platform as a service application also means that we implement best practices out of the box. This means that factors such as security are better-designed than we would manage ourselves, with security-by-design (almost) out of the box. PaaS offers a huge advantage in this respect, because the platform delivers more than just tooling, you also get good design principles.
While we already greatly benefit from Microsoft Azure, I believe this is just the starting point.
What’s next?
Nmbrs is consistently striving to create a more stable, higher-level infrastructure. That’s why I intend to connect the application to the infrastructure in the future. Azure allows us to script infrastructure components using API, which would enable us to control infrastructure resources from inside the application. Why would we want to do that? Imagine a user action will require a great deal of resources. In Nmbrs’ case, that could be generating a big report or processing payroll for a large company. If the application is connected to the infrastructure, the application could trigger the infrastructure to scale up to meet these needs before the user is fully ready to demand them, offering an optimal user experience. We also want to improve the deployment process and make it possible to deploy without downtime.
By taking the concept of infrastructure-as-code to a new level, Nmbrs will deliver a better end-user application, but also improve the quality of internal development.
Moving forward, I will continue to look for higher-level solutions as new technologies appear, so we can continue delivering an innovative product. New technologies like serverless already making waves and could disrupt our infrastructure in the future.
