App Modernisation for Azure App Service
Can you teach an old dog new tricks? Yes you can!
This is Caesar, our Beagle. He’s 4 years old and he loves food. Any food!
I can teach him any trick if there’s food involved. He’ll make a great 3rd slip if the cricket ball was a cookie.
Your 4 year old application can also learn new tricks. That cute puppy code-base that evolved into today’s resource hungry monolith can be modernised for the cloud.
In Greek, monos (single) + lithos (stone) literally means a single piece of stone.
The typical monolith application
I feel your pain. I’ve worked on many projects where customers explained to us how their “single piece of stone” application became so heavy that it often fell over when surpassing a certain number of users. Part of the solution is always to improve the quality of the code and the other part is application hosting at scale.
The cloud is great for running applications at scale. As an ASP.NET developer my preferred choice is always Azure App Services. It’s developer friendly. I can forget about Docker, Kubernetes, Yaml files and all things infrastructure while rather being customer-focussed so that I can deliver real features on time and on budget.
What a relief! Now I can focus on my application and leave the uptime to those who excel in enterprise-grade, secure, performant and compliant application hosting.
Scaling is important. As your business grows, your application will need to handle more traffic.
With monoliths, the only option is vertical scaling: Adding more RAM, disk space or CPUs. But there’s always a hard limit to scaling up your application.
With a few small changes you can modernise your application for hosting in the cloud. Azure App Services allows for horizontal scaling. It can scale out your application from 1 to any number of instances.
Scaling out your application to 3 instances on an Azure App Service
But there are a few things to keep in mind when preparing to host at scale.
If your application carries any form of state such as session data, in-memory caching and flat-file storage, it’s not quite ready for vertical scaling.
There should be a clear separation between processing and storage. Your application should contain user interfaces, API’s, business logic and data access methods, but storage should reside elsewhere.
Session data and caching ideally belong in a Redis backplane, while application data should be stored in a cloud database.
Select the cloud database engine closest to your current on-premise one.
Azure offers many data storage options such as SQL Server, MySQL, PostgreSQL and CosmosDB. CosmosDB has a Mongo API if you prefer a NoSQL database.
The databases are built for scale and you have a myriad of choices in terms of disk size, RAM and CPU’s. Many replication options are available as well.
When setting up your Azure App Service and database, make sure they’re in the same region. Your application should live as close as possible to the data.
If you’re in South Africa, be sure to make use of the newly added Cape Town or Johannesburg regions. Azure calls them South Africa West and South Africa North respectively.
While scale is convenient, it’s important to keep an eye on the consumption as well. Azure offers a cost calculator to help with estimates up front, but the dashboard in the Azure Portal also shows your real-time consumption.
The benefits of Azure App Services are many. For me the following stand out.
- Almost any application can be hosted in Azure App Services
- Best practices are built in: performance, reliability, security, compliance
- Horizontal scaling allows for growth and peak periods
- Zero-downtime deployments ensure that customers are not interrupted
- The staging environment helps you test before going live
- Builds and deployments from any Git repository allows for reliable, repeatable rollouts
Whether your code is written in Python, Ruby, PHP, Java, .NET Framework or .NET Core, Azure App Services can host it for you.
As a Microsoft Gold Partner, DVT helps businesses like yours to scale for the future. Let’s set up a meeting and discuss your cloud requirements.
Now what happened to my cookie?