Azure and PaaS Versus IaaS
Sage 300 ERP has had a cloud version for over ten years now with Sage 300 Online. I blogged a bit about how this offering works here. Basically we offer our on-premise product in the cloud relying on Citrix and Terminal Services technologies to host and allow access. You are basically running your on-premise Windows desktop ERP application in the cloud. The only thing required on the local computer to access the software is the Citrix client component which is available for Window, Mac, iPad, etc. We are currently hosting this in Sage’s Atlanta data center.
We are now looking to produce the next generation of this cloud offering and we are looking to host it in Microsoft Azure rather than our own data center. There are quite a lot of reasons for this, like being able to deploy globally to various Azure datacenters or to take advantage of the Microsoft network which provides quite low latency access to these data centers. But the Azure feature we are going to explore in this blog posting is what does Azure PaaS give us over an IaaS offering? What are the differences and what are the considerations?
IaaS stands for Infrastructure as a Service. In this model the provider, typically someone like AWS or Rackspace, provides all the hardware, storage and networking equipment. Then they give you the ability to create virtual machines in this environment (often providing some starting templates of typical servers). It is then up to you to install everything you need to run on these virtual machines and to maintain them fully going forwards, ensuring all patches are installed, upgrading to new versions of the operating system, etc. If you need a database server then it’s up to you to buy and install that database server on one of your virtual machines and it is up to you to maintain this server, back it up, provide geographic redundancy and anything else that is required to keep the data safe.
PaaS stands for Platform as a Service. The goal of PaaS is to build on IaaS to have the vendor also take care of maintaining the operating system and the database server. So you don’t need to worry about patches, backing things up and various other chores. Microsoft Azure is an example of a PaaS offering (although they are getting into offering IaaS as well). Below is a diagram showing how the layers are often separated. This also gives the vendor the opportunity to provide more advanced monitoring and management tools for the platforms they are supporting.
Complexities of PaaS
That all sounds good but how do you separate out the maintenance of the operating system from the maintenance of the application? Generally the way this is done is that whenever you start a VM you start with a fresh copy of the operating system which is then guaranteed to be at the most recent patch level. In the IaaS model you start with the operating system template once, then everything that happens to that image is stored to disk and if the image is stopped and started you continue from where you left off. In the PaaS model if your image is stopped and started, then it is restarted with a fresh image of the operating system and you need to install all your software before it can start processing.
This is why most PaaS systems tend to be very specialized in the type of applications they can run. Azure is built around running ASP.Net applications. Microsoft provides support in Azure and .Net to easily deploy your ASP.Net application to a new operating system image as it starts up. Similarly Ruby on Rails PaaS vendors provide support for installing the Rails application on their new image as it starts.
But doesn’t that mean you have to transfer huge amounts of files to the environment every time a VM starts? Well actually no. Azure provides a number of non-VM storage mechanisms for storing files in the environment. So for instance you can use blob storage or one of the other storage mechanisms to hold all your files and data. Then the scripts that start the VM would just attach these to the VM when it starts, or your program knows how to use the Azure SDK to connect to these when it runs.
PaaS databases are bit easier, since you just create and access your SQL Server databases in Azure SQL just like you would in a regular SQL Server, you just need to know the right information for the connection string to the Azure SQL server. But there are still issues to be aware of. For instance when you create your own set of VMs to make a production system, you can specify them in a VM group and ensure they all run in the same area of the Azure data center. This then ensures any latency of communication between these VMs is very low. But when you switch to the PaaS database server, all the servers that comprise, say Azure SQL all run together in another area of the data center and the latency from your server group to this server group is a bit higher than communications within your own group. Further you are then sharing these servers with other unrelated applications using these servers, so you are relying on the vendor to provide sufficient processing power to keep everything performant. But the best thing about PaaS databases is that you don’t need to worry about tuning the server or backing up all the data.
Moving Sage 300 ERP to PaaS
But Sage 300 ERP is not an ASP.Net application. So how can we even run in this environment? Fortunately, Microsoft provides both IaaS and PaaS services in the Azure environment. This means we can move our current Sage 300 ERP cloud implementation from our Atlanta datacenter to Azure by using the Azure IaaS infrastructure. We can then start to take advantage of various PaaS services one by one.
The whole Azure infrastructure provides a very rich API which allows you to use PowerShell scripts to control what is going on. Hence the ASP.Net support is really a set of scripts developed to handle typical deployments that is built into the Azure/Visual Studio SDK. From Sage 300 ERP we are developing similar scripts to create and control a Sage 300 ERP deployment. This way we can incorporate PaaS building block into our system. So we can have scripts to start and configure the whole system, scripts to add applications servers and so forth. We can even integrate these into standard DevOps tools such as RightScale or Chef.
Leveraging Azure SQL is perhaps a bit easier since you can use the same access technology we currently use. We have to add a bit of code to our database driver to handle some cases that can happen in the Azure environment but generally using Azure SQL is very similar to using regular SQL.
The system that makes up Sage 300 ERP cloud consists of quite a few VMs all performing various tasks. Switching some of these to PaaS based servers is very straight forward, so we can do this right away. For our application servers that have full Sage 300 ERP installed, we will continue to maintain these as IaaS for the foreseeable future since right now the overhead in installing full Sage 300 ERP is a bit high. But there are features coming in the Azure roadmap which will over time let us migrate these to PaaS as well. To some degree PaaS is still in its early stages and new services are regularly being rolled out and we can take advantage of these new services as they appear.
In our Atlanta data center we operate Sage 300 Cloud on a fixed set of servers that we purchased and as the usage grows we buy another server now and again. With a managed service like Azure we are paying for our infrastructure on a usage basis. However the system is elastic, meaning that we only need to run as many application servers as we need to handle the current load. So if usage is low during the weekend then we can shut down some application servers and save some money. Similarly if we get a big spike in usage we can easily add as many application servers as we need instantly to handle the load (perhaps at year end). Again basically we control all of this with a number of PowerShell Scripts.
Microsoft Azure is a very rich cloud environment. It provides us with a lot of benefits to help us beef up our Sage 300 ERP Cloud offering. But with the richness, there is quite a bit of work creating scripts to take advantage of it, tuning our application for this environment, as well as a learning curve learning the best ways to leverage all these new PaaS features.