Modernising .NET apps on Microsoft Azure comes with a number of benefits, from the scalability inherent in cloud computing to the ability to shift risk from your on-prem servers to Microsoft’s Azure platform.
But what does modernisation really mean? Everyone has their own definition, but for us, there are two key parts to it: ownership and architecture.
App Ownership
With app modernisation, a primary goal is to build applications in a way that lowers the total cost of ownership. And total cost of ownership doesn’t just mean what it costs to host the application and to run it Azure, but also what it costs to support it.
When Fred Brooks wrote Mythical Man Month, he famously made the statement that “80% of the cost of a software system starts after development ends.” And that’s still pretty true today. The gold standard is really getting rid of your application and replacing it with the SaaS model where you pay someone X dollars per month, per user. But that’s not always the world that we live in, especially in the enterprise space or where companies have bespoke requirements.
App Architecture and Implementation
Ownership is a big part of modernisation, but the other part – the one where we get down into the weeds – is architecture and implementation. How do we build applications? How are they constructed? How are they delivered? And what does that mean in today’s environment?
When we think about what an ideal application looks like, in most cases, that’s going to be web-based. There are some scenarios like industrial control where you may need to do things on-prem, but those use cases are shrinking all the time. Implementation underpins that by enabling architecture to take a very lightweight approach to integration.
We went down a very dark path as an industry 20+ years ago, when people started building N-tier applications, and COM+ and EJB were a thing. These were very complicated, unwieldy technologies that were hard to manage and prone to breaking. We tried to reboot as an industry into what the web version of that looked like and, unfortunately, produced WS* standards like SOAP – which, again, were just far too hard for what they achieved.
Today, we seem to have settled into REST and JSON being our primary integration technologies. And while they’re less formal than what we used in the past, they’ve made implementation super simple – you can just hit an endpoint with a browser, and you know it’s working. It’s so straightforward.
Given these ownership, architecture, and implementation considerations, it becomes clear that there are three primary paths for app modernisation in Microsoft Azure.
The 3 Paths to Microsoft Azure
Think of app modernisation with these three traffic light rectangles.
Desktop Applications
On the left hand side, you’ve got the worst case scenario – you’ve got a desktop application that’s probably written in VB (or even Microsoft Access). Especially if you’re working in government, chances are you’ve got heaps of these little MS Access applications kicking around to be various registers, for various things.
They’re pretty far away from where you want to be today. And, unfortunately, there isn’t a great migration path for these, apart from either a complete rewrite or deploying it to a desktop solution like Azure Virtual Desktop. AVD is excellent – we’ve got customers using it with desktop applications in a way that works really well. But in this case, you’re always going to have this application that’s going to be difficult to deploy, and that’s going to be subject to compatibility issues with operating system upgrades.
Legacy Web Applications
In the middle, we’ve got what we call legacy web applications. These are apps that are delivered over the web, but that probably take a significant dependency on legacy technologies.
If you’ve got an N-tier type architecture, or if you’re making use of COM+, ActiveX, or any sort of high trust requirements, you’re going to need to do a bit of work for it to become a modern application, depending on how much of a dependency you take on those applications.
Web Applications
Finally, in the best case scenario, you’ve got something that’s close to a sanely built modern web application – something that’s written on a runtime like .NET, PHP, Node, Ruby, Python or Java (all of which are supported by PaaS offerings at Microsoft).
In our experience, 90+ per cent of the time, you can just pick these applications up and drop them into PaaS. If they do need changes, the sort of engineering effort that you’re looking at is something you’d typically measure in days (or at least a very low number of weeks).
How Cloud Anti-Patterns Affect App Modernisation: A Case Study
The app modernisation path you’re on is also affected by what we call ‘cloud anti-patterns’. Essentially, these are things that people do – and have done in applications in the past – that aren’t necessarily bad engineering, but that don’t fit the modern PaaS worldview.
To give you a sense of how these different paths play out in real life, we recently worked with a customer who had built a large genomics application to track and manage their company’s various genetic and DNA matters. We were their cloud solution provider (CSP) at the time, but they also engaged an external developer to work on the project – one who was fairly antagonistic to the cloud.
The application required dozens of servers to run the web-delivered application; the footprint was really large for what it was. So we rolled up our sleeves and started with a source code level review of the application, looking for the cloud anti-patterns that were going to prevent us from going to a PaaS environment successfully.
Once we identified the anti-patterns, we made a resolution plan for each of them, and then implemented them and put them on a more modern footing with DevOps. Ultimately, all it took was a few weeks of work in the context of a project that went for the better part of two years – a couple of weeks to get the application cloud-ready that were essentially insignificant in terms of the overall project cost.
Identifying Your Application’s Cloud Anti-Patterns
One of the reasons we were able to help our genomics customer get their application cloud-ready so quickly is that we utilise a very detailed set of assessment criteria to form a baseline for every customer we work with. From customers’ responses, we’re able to determine where their applications fall on that red-yellow-green spectrum, as well as communicate to them what sort of work might be ahead in terms of modernising their applications.
If you want to conduct the same type of analysis on your own, we’ve put together a quick PDF including some of the criteria we include in these assessments. Download your copy now and use the criteria to get a feel for where you sit on that red-yellow-green spectrum and what sort of work might be ahead of you in terms of modernising your .NET application.