Cloud Vendors – Azure Part II
This week we are happy to bring to you our second, long-form guide where we dive deeper into key areas that, if executed well, will act as the foundation for future scaling. First, take a minute to look back at our previous article on Microsoft Azure. Our last article introduced cloud hosting vendor Azure. This article, using the last one as a base, will explore an important cloud architecture decision to consider on day 1 whether to deploy your application using serverless or statically provisioned resources.
Going Serverless
One important solution design decision to make is whether you will opt to deploy your application using serverless resources. Serverless is a great choice because it removes the need for you to manage infrastructure – both for upgrades and patches and for scaling. A second advantage of serverless is that you pay for what you use versus paying for statically provisioned resources. Another major advantage of serverless is that it makes it easier for you to maintain a high security level for your application. Most digital health applications manage protected health information (PHI) and almost every app manages personally identifiable information (PII). This data must be well secured and using serverless resources makes that easier because patching and upgrading are done automatically by the cloud vendor.
Furthermore, if your product is sold to enterprise customers, as part of the buying process, they will do IT security reviews of your application. Standalone virtual machines are always flagged as risks during these reviews – due to their manual patching and upgrading process.
Serverless does not come without downsides. The most obvious is that you will not have access to actual machines and operating systems that your application is running on. This can cause difficulties in monitoring systems and debugging issues. It also introduces a disparity between the typical developer environment and the deployed environment.
Managing Serverless Cloud Costs
Note that managing cloud costs is easier with serverless because of auto scaling and provisioning of resources but, at least for Azure App Services, once provisioned, even if not used, you pay. Furthermore, if your app service is up, it will typically prevent your Azure SQL Database, which you would have provisioned as serverless rather than DTU based, from pausing. This is not a problem if the usage pattern for your application is 24×7 but, if your app is used during the work week, being able to pause resources will save you a lot on your cloud bill.
In a work week scenario, you can save money by having your resources paused on weekends, holidays and night hours. To do this when your app includes Azure App Services, you need to delete the app services so that your database can pause. One approach is to create an “Offline” scheduled DevOps pipeline, to backup the app services to your storage account, then delete them. Then to create an “Online” scheduled DevOps scheduled pipeline, which restores the app services from storage. This will require you to build and maintain these devops pipelines but it can very quickly lead to significant cloud cost savings.
Conclusion
We threw a good bit of information at you above. The question you might have is – what decision should I make, go serverless or use provisioned resources? There isn’t a right or wrong answer to this question but one important criteria is: who is the customer for your application?
If your customer will be another company, the security benefits of a serverless architecture typically outweigh all other factors. If your customers will be consumers, though they are less likely to demand high levels of security, you certainly want to take a
thoughtful approach to managing the data which they are entrusting to you. Furthermore, for B2C applications, the auto scaling capabilities of serverless resources are often essential.