The application was originally installed on a hosted server, managed by a South African Internet Service Provider. The environment was maintained by the client. A QA environment was hosted on a separate server and maintained by Code Collective.
This setup was sufficient for initial development, but posed several challenges over time.
- Maintenance of the server environment was tedious. Regular OS and security updates were required. Database backup jobs had to be implemented and maintained.
- Disaster recovery was cumbersome.
- Risk of security breaches and reliability of the hosted server.
- Limited flexibility to handle scale, or high escalating costs.
- Data sovereignty rules, requiring data to be stored in the same country, or continent.
Azure Platform as a Service (PaaS) presented a managed, highly reliable service with the flexibility to scale as needed.
- No server environment maintenance was required.
- Multi-region data redundancy was provided with little effort.
- Microsoft secured servers and >99% monthly uptime SLA.
- Ease to scale resources as required, and limit cost by reducing resources during off-peak periods.
- Microsoft’s international data centres meant data could be stored as geographically required.
In 2016, we moved from the hosted server to Azure PaaS. The project, which took around a month, transitioned us from IIS to App Services; and from SQL Server to Azure SQL. Where we would previously access the server file storage we now used the cloud based Storage Accounts. The Windows Service was replaced with a WebJob, which was an appropriate mechanism for our background, and periodic processing. Our distributed caching layer, previously implemented with MemCached, was transitioned to Redis – a fully managed service, with high performance and reliability. In addition, we started to incorporate Azure Automation features, such as Function Apps to manage periodic scaling of our database, syncing of indexes, and other automated processes. Application Insights was included for performance and monitoring.
Soon we had transitioned all our environments, including QA, UAT, and a UK based production environment. They were able to leverage off each other through shared App Services, a Redis cache, and an Elastic Database pool. App Service scaling rules were introduced to allow for increasing and decreasing of instances and configured based on load such as CPU, memory and queue length. This would allow seamless scaling capabilities in keeping up with the growth of the business.