However, did you simply move the code and runtime from a Virtual Machine to an App Service, or did you spend time redeveloping and refactoring parts of your code to make it a better fit for Microsoft Azure?
Possibilities for integrating with Azure
What we mean by “Really using Azure” is: Are you integrating with other technologies and really leveraging the power of the cloud?
Let us picture the following scenario:
Cloud Adventures is a software company that provides a web shop to its customers. Their solution is an MVC application built in .Net and leverages a SQL database for storing orders. Additionally, they have some customer-specific customization stored locally on the web server itself. Their solution contains code that provides different layers and services to allow for access to the database and local storage, and on top of that, they added an API endpoint for their customers to retrieve a list of orders and the order status. Customers can use this API to integrate with their CRM system.
A couple of things pop out here. We can quickly conclude that Cloud Adventures has built a lot of functionality into a single solution. You often hear the term “monolith” to describe such a configuration. This is usually the result of two things:
- The company started with one or two developers coming up with a great idea, and they just built it (there is no better way to get started!). Once the product became more successful, and the market was ready for it, features were added. And those features were being added until Cloud Adventures learned that it requires quite some oversight to maintain this one solution that can do everything. Not to mention that updating a piece of code means rebuilding and testing the entire application.
- Then we have the constraints of Virtual Machines. There is no native technology to abstract the storage away from the Virtual Machine; you are bound to use the local disk or attached storage.
So, other than the fact that it’s a natural process and at some point, almost everyone ended up with a monolith, we were also not giving our developers the option to do it differently! One could argue that you can host different websites/services on a local webserver. And that is true. But is a developer generally aware that you can do this? Do we even want to burden a developer with that infrastructure knowledge? Unlikely.
What is the alternative to a monolith approach?
For one, you can still build a monolith on Microsoft Azure. You can easily stuff everything into a single App Service and scale it until you hit the limits of that technology. This is when innovation in infrastructure can no longer be used to improve the solution and its performance. When you get to that point, it is definitely time to look at the code itself.
We need to understand that just technology is not going to solve this. The mindset of developers requires a change; if you are used to building monolithic solutions, this might just be a result of Conway’s law:
“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.”
— Melvin E. Conway
That doesn’t mean it is easy to fix, but I recommend reading about this and understanding why and what is happening.
Leverage the power of Azure
All right, back to technology. Let us say Cloud Adventures moved their solution to run on App Services in Microsoft Azure. All the logic is put into that single App Service. Same solution as in a virtual machine, just a different technology to host it on. That means we still have the same monolithic scenario. They are experiencing the same challenge as before: it is hard to maintain, difficult to keep oversight, and touching one piece of code may impact the rest. They are not really using Microsoft Azure.
How do we solve that? Well… Microsoft Azure provides a lot of different technologies, each with its use case. We can use storage accounts for storing files and leverage the power of a Content Delivery Network (CDN), we can use an Azure Redis Cache to perform the user session caching, and we can use Azure Functions and API Management to run and expose the API Cloud Adventures has built to provide order statuses. That’s a lot of technologies in one sentence, and you don’t have to remember them all, as you might need different ones for your use case. However, it does show that there are Azure technologies that you can use to abstract that logic away from your primary solution (the Cloud Adventures web shop in this case).
You, as an observant reader, might think, “This sounds familiar,” and you are right. We have recently published an article on App Modernization: App Modernization, buzzword, or true story? | Intercept that describes this process and the mindset.
Let’s talk about getting this done. Do you have to go from 0 to 60 within a couple of seconds? Definitely not. These are projects that take time and require a phased approach. It’s all about those bite-sized pieces.
For Cloud Adventures, that would mean we will look at using Storage Accounts for storing the customization per customer that is now hosted on the App Service locally. We are going to abstract the storage away from the App Service.
Interacting with Azure Services
So. We are going to interact with different technologies in Azure.
Storage Accounts
In the current example that would be Storage Accounts. There are multiple ways to go about this. Your main two options are:
- Interacting with storage accounts using the Azure REST APIs
- Using the Blob storage SDKs as provided and maintained by Microsoft
Everything in Microsoft Azure can be addressed using the Azure Resource Managers REST APIs. However, this requires you to do multiple API calls to the endpoints for storage accounts, resulting in quite some code and dealing with HTTP Clients, JSON responses, and complex authentication in code. Not something you want to do spend doing every day.
SDK in Azure
Then we have the SDKs. There are a lot of them for different languages and different Azure technologies. SDKs can be found here: Download Azure SDKs and Tools | Microsoft Azure. Most are maintained as open-source projects; if you’re missing something, propose an improvement! What makes the SDKs so powerful? Because almost everything you need is in there. If we look at using Blob storage, using the SDK, it takes a whopping 7 lines of .Net code to write a file to blob storage. If we were to do that using the REST APIs directly, it would take way more than seven lines of code.
Does that mean REST APIs are out of the question? Definitely not. Sometimes you need to do something not supported through the SDK; the REST APIs are your alternative.
What did this bring Cloud Adventures?
By incorporating the Azure Storage SDK, Cloud Adventures has abstracted away from the storage of customer-specific configuration to blob storage. This resulted in multiple benefits:
- Storage doesn’t take up space and resources on the App Service
- The SDKs require less code to get the job done, it’s more efficient
- Cloud Adventures can now leverage additional Storage Account features such as enabling a Content Delivery Network to perform the caching of data
- Customer customization can now be separated and secured into different blob containers
And we didn’t even talk about the financial impact. If you embrace this mindset and follow through by modernizing more parts of your solution and incorporating different technologies for different tasks, you can be efficient in the way your environment is priced. We no longer need that beefed-up App Service.
Wrap-up Azure is all about the bite-sized pieces
We’ve seen that it is definitely interesting to use Microsoft Azure, but it doesn’t happen overnight. It is all about the bite-sized pieces, but it will come easier than expected once you get to it. In the second part of this article, we will work on the Cloud Adventures use case and provide visuals and code examples on how a solution would go from 0 to 60!
Application Insights: deep dive
Want to gain more insights into Azure? Sign up now for our workshop: Application Insights and find out if you are fully in control of your application.
This is the first article in a series, the second article will follow soon!