Improving Delivery & Efficiency by Leveraging PaaS
Introduction
Development teams moving towards a more DevOps way of working need a way to manage infrastructure and configuration without having in-depth knowledge. The easiest way to achieve this is by offloading it to a provider while maintaining overall ownership.
Within Kingfisher, we have a team of approximately 15 engineers responsible for the development and maintenance of tactical applications. These applications fill short term retail operational gaps identified within strategic enterprise solutions, but can often remain in use far beyond their original proposed lifetime (sometimes indefinitely).
Within this article, we provide an overview of how leveraging Platform as a Service (PaaS) within Azure helped the team.
Old vs New
Applications were typically hosted on-premises using Windows Server within a conventional approach (3-tier, IIS, etc…). This severely limited any control over scaling and meant the configuration and software maintenance (excluding OS) was the responsibility of the engineers.
A considerable amount of time and effort was taken up in ensuring that the right server resourcing and configuration was chosen and created.
Moving applications from being hosted on-premises to being hosted within Azure using PaaS offered clear benefits:
- Simplification of application configuration
- Offloading of machine creation / maintenance
- Reduced deployment cost and effort
- Easily configurable horizontal scaling
Technical Approach
As the team design and build applications using Microsoft technologies, the easiest path to establish a new way of working was with Azure Web Apps. These felt familiar to the team — both in terminology and approach. They also provided straightforward integration with existing corporate datacentre and allowed for full .NET framework support out of the box.
The company already had an existing ExpressRoute connection, so connecting to on-premises resources was easily achieved. This meant traffic could be sent over a private connection — avoiding sending requests over the Internet.
Given the range of applications owned by the team, an Application Gateway was added to provide a single point of communication and to allow traffic to be routed to the relevant Web App. This simplified the configuration of SSL certifications and domains (among other benefits). Originally, traffic had to be blocked by each Web App to eliminate any public access. This created a number of frustrations but the introduction of Private Endpoints removed the need for this and allowed traffic to flow securely without the need for additional rules.
After the first few applications were created using Web Apps, effort spent creating and maintaining via the Azure portal became excessive and mistakes were becoming more prevalent (e.g. forgotten configuration values). It became clear that an Infrastructure as Code (IaC) approach was needed and the team adopted Terraform — as this was easy to learn and fitted with other teams within Kingfisher.
Once the first Terraform modules were built to agreed standards and conventions were met, (such as enforcement of private endpoints), the team were pleased with how much easier this made the creation and maintenance of the required Azure infrastructure.
To get the most out of using PaaS, the team utilised as many of the built-in features as possible. This removed much of the cross-cutting effort usually required and included:
- Authentication
- Logging
- Monitoring
Team Approach
Although there was some commonality between building and supporting .NET applications on-premises and Azure Web Apps, there was still an adjustment needed in understanding how to get the best out of the technology. Azure Web Apps provided an abstraction from traditional IIS-hosting and so delegating control to a “black-box” took some getting used to. The key point was that by not needing to have such control, we were releasing the team from the overhead of configuration and maintenance of a server / site.
The team were keen to adopt hosting using PaaS and eventually understood the benefits (and costs) of doing so. One of the key lessons to be learned was how poorly implemented features would cost real money (i.e. needing extra resources to run) in addition to the less than optimal performance which also affected applications when hosting on-premises.
Operational Approach
With the company still on a journey towards DevOps, supporting applications now hosted in Azure with existing support teams proved to be a “square peg, round hole” situation. To resolve this, we worked with support teams to provide them knowledge on how to resolve issues that may occur (for example showing how to restart the application when previously this had normally involved a server restart).
This wasn’t easy. Support teams only had knowledge of how to work with on-premises servers and only as far as they needed to in order to support existing applications. Over time, the knowledge was shared and more of the day-to-day operational tasks were handed over.
With the simplification of day-to-day running provided by PaaS, many of the tasks which would normally require manual intervention were removed. This reduced the load on support teams — freeing them up to look into improving application usage for end users.
Resulting Benefits
Moving from hosting applications on-premises to using Azure PaaS increased the speed of delivery. With the team no longer having to configure and maintain servers, (either directly or indirectly), they are free to concentrate on building applications.
With the amount of cross-cutting features Azure PaaS offers out-of-the-box, the team is able to offload and use a largely codeless approach in these areas. This has removed effort needed to implement repeated capabilities and reduced cost of development.
The adoption of IaC means environments can be declaratively defined and versioned controlled. This has also meant environments can be created quickly and in a repeatable way — opening the door for ephemeral environments which (for example) can be used for automated test runs.
Being a team using Microsoft technologies obviously means Azure is a best-fit Cloud provider. The large amount of cloud-native .NET support means the team do not have to radically change the design or implementation approach in order to leverage Azure — further adding to the benefits of adopting Azure PaaS.
Future Direction
With a number of greenfield applications now running in Production, migrating on-premises applications into Azure using the same approach is possible. This will align with the organisation’s desire to move to cloud providers and away from data centres.
One of the main integration points for all Azure applications is connecting to on-premises databases. This will eventually be resolved by hosting databases within Azure — reducing latency and allowing us to take advantage of DBaaS.
The use of Web Apps is by no means a final destination. The work undertaken to date puts the team in a great position to take advantage of serverless hosting options (Functions, Container Apps, etc…) to reduce cost and to further accelerate the rate of change.
If you are interested in joining us on our journey, please do check out our careers page.
Thanks for reading
