Digital transformation of a monolithic application

Digital Transformation

‘Digital Transformation’ is one of those buzzwords we hear often when discussing the new world of cloud based computing, but it is in fact a far older concept describing the way in which computers have changed business and wider society since their first adoption; From the paperless office to contact-less payments. As such applying the term ‘digital transformation’ to the cloud is just describing another step in a longer journey – the step of moving services from on-premises datacentres to public clouds.

The first tentative steps for organisations is often to ‘lift-and-shift’ workloads from on-premises physical or virtual servers into equivalent Infrastructure-as-a-Service (IaaS) virtual machines. The next step, usually referred to as a ‘refactoring’, is to substitute one or more components of a service with a Platform-as-a-Service (PaaS) offering. Common examples include replacing IaaS hosted SQL or IIS with Azure SQL or Azure App Services respectively. These are generally seen as intermediate moves towards the true cloud ‘ideal’, of re-architected services that are serverless, transactional solutions based on microservices.

In this article I’m going to discuss my first experience of re-architecting a traditional monolithic business application while taking a consciously cloud-native approach. I’ll be porting a small, bespoke, in-house developed application. The resulting solution uses a mixture of cloud-native technologies, and while not quite completely meeting the ideal I just described we get significantly closer to it, and bring about a solution with a number of benefits over the original.

What Came Before

Scribe is a bespoke application written in-house to transcribe emails into notes on Incident records in Silversands’ instance of Microsoft System Center Service Manager employed by our service desk. While Service Manager includes its own email ingestion service, this has several limitations and did not meet all the requirements of Silversands’ service desk. The original on-premises version of Scribe was written as a monolithic Windows service running inside a virtual machine, making API calls to the Service Manager server and to Exchange Online.

Inspiration

Having been lucky enough to have attending 2018’s Azure Tech Summit in Birmingham, UK, one of the things that struck me the most was the potential for serverless computing. The benefits are clear;

• Massive, seamless scalability
• The potential cost saving from paying on a per-transaction model, as opposed to continuously paying for idle infrastructure
• No need to manage of the underlying infrastructure
• Integration with other Azure services, such as API management, and App Insights.

The challenge comes from re-architecting solutions to fit the cloud native services, such as by adopting functional programming where possible. However, like most coders, a new programming challenge just sounds like fun 

Breaking it Down

Part of the appeal of Azure is the offering of multiple Compute services, to meet differing requirements around hybrid connectivity, security boundaries, access to data stores and so on, and allowing any combination of these to be used to play to the strength of each.

The mix of cloud-native services that I went with is a combination of:

• Microsoft Flow – For the high-level orchestration, taking advantage of ‘low-code’ development
• Azure Functions – For stateless operations, taking advantage of transactional cost savings
• Azure API Apps – Providing the hybrid connectivity to the on-premises Service Manager, taking advantage of the reduced management overheads of a PaaS offering

The Solution

Microsoft Flow provides a web-based ‘low-code’ interface, that was used to develop the orchestration of the overall solution. Flow provides many useful building blocks out of the box, called Actions, which can simply be dropped-in to the sequence with minimal configuration.

This avoids the need to write boilerplate code for tasks such as in this case, monitoring a mailbox and triggering on the arrival of a new email. It also includes pre-built Actions for common data manipulation tasks, such as parsing JSON or HTML files which are very useful for when interacting with RESTful services as we are here.

For things we can’t do natively in Flow, we make HTTPS POST requests to the Functions App, secured using Azure AD authentication, as and when required.

Both the Azure API App and Functions App were developed in Visual Studio in C#, taking advantage of the continuous integration and source control integration provided. Both services support other languages – including in the case of Functions, JavaScript – however C# happens to be what I am most comfortable with.

The App Service hosting the API App is configured with hybrid connectivity, with a gateway service installed on the on-premises Service Manager Management Server. This provides a secure way of enabling App Services to communicate with any arbitrary on-premises TCP service. In this case, it allows our API App to communicate with the Service Manager SDK.

Both the API App and Functions App are associated with Application Insights and the code for both include telemetry calls for monitoring and instrumentation.

Conclusion

The result is a service, previously implemented as a monolithic Windows service, running on a virtual machine that required patching, backup and monitoring, being completely re-implemented in the Microsoft cloud with no infrastructure to manage. If it needed to, the re-implemented solution could scale with far greater ease.

Azure Application Insights also provided a wealth of analytics on the performance and health of the application that can identify areas where the efficiency of the service could be improved, and failures identified and resolved. By posting custom events to Application Insights we could also produce dashboards indicating the most widely used features.

As a side benefit, by re-architecting the service with an API in the middle, we were able to add a new way of interacting with our helpdesk Incidents by integrating the API with the Azure bot service. This means we have been able to allow our staff to query and add notes to Incidents through the Teams chat interface.

Observability using Application Insights

How can Silversands help your digital transformation?

Silversands is a Microsoft Gold Partner and specialist in Microsoft 365 and Azure / Hybrid cloud. To talk to one of our consultants please complete and submit the form below:

Silversand’s expert-led seminars. If you work for an organisation with more than 250 seats that uses Microsoft 365 / Azure, join us for a 1/2 day session that will fill your head with ideas and knowledge.