Blog

Checklist part 2: Choose your architecture before you migrate to Azure

As a second in a series of articles, we’ll take a look at architectures and why it is important to take a look at the overall picture. In our previous article we discussed how to choose your strategy before migrating to Azure.

Do you want to define a roadmap and see where you are in 3 years? Probably not. But you do want to understand the implications your architecture has on added value, available features and pricing.

The initial benefits from moving to the cloud can usually be categorized in one or more of the scenario’s as mentioned in the previous article (“On and Off”, “Growing fast”, “Predictable and unpredictable Bursting”). Depending on where you are in your journey of modernizing your application on Azure, one or more scenario’s will be beneficial for you. The higher in the stack you go (IaaS -> PaaS -> Serverless and SaaS) the more benefits, added value and efficiency you will get. The higher you get in this stack, the more your focus will (and should) shift to software architecture instead of IT infrastructure.

Does that mean your architecture has to represent your ultimate architectural dream? Definitely not. With the ever changing and ever evolving public clouds, committing yourself to a long term IT roadmap is not the wisest thing to do. Committing yourself to a multi-year plan is the equivalent of investing in on-premise hardware with a 3-5-year depreciation. Your environment will be “old” by the time you will write-up your new roadmap. One of the most important properties of public cloud is that new features are being added daily and they evolve at a speed at which we have never experienced before in IT. To overcome this, you want to start with the right architecture, make sure you deploy what you need and focus on life cycle management and continuous improvement (DevOps!).

I can hear you say “well that’s all great! But where do we start?”. And to tell you the truth: this is probably the hardest thing to do. How do you decide where to start, what to use and how to use it? All roads lead to Rome (eventually) but hopefully this article and this series will help you.


Knowledge
Your first step is to obtain the knowledge you need to map your plans to an actual cloud architecture. This can also be quite the challenge. Are you looking to do things by yourself or are looking for help? When it comes to Microsoft Azure (and public clouds in general) it’s easy to get started by yourself; get a subscription, deploy resources and learn by doing. But when you want to start building your proposition, you want to be sure to have the right knowledge at hand. If you have Azure professionals on the payroll, they will be the place the start. But it is likely you don’t have the required knowledge available to you. This is not your fault, this is because public clouds go that fast and it’s hard to keep up. In any case we always advice people to seek guidance from a Microsoft Partner, seek out those architects and go through the process with them. Microsoft Partners who built their business on Microsoft Azure spend a lot of effort tot stay up to date on whatever new features are released, how you can use them and test them through private preview programs prior to be released to the public. And to be fair: do you want to focus on education and testing new features in a cloud platform or focus on improving your software and become informed of all the new features that might be applicable to you? In our experience the combination works best, you have professionals that know the ins and outs of your solution and that knowledge is valuable. Having them team up with a Microsoft Partner and built the best platform for your solution is the most efficient way to go.

Regardless of who’s doing what and when, think of this before you start. Nobody wants to look back and think “why didn’t we do it like this?” 😊

Where are you coming from
It’s important to understand where you are coming from. Especially from an infrastructure perspective. Where is your solution currently hosted and what does your application architecture look like? First of all, it’s important to determine how dependent you are on your infrastructure.

  • Are you currently running on Virtual Machines?
  • Is your solution installed on the operating system (i.e. are you using installers) and are you adding extra dependencies (additional services to support your solution) or are you simply running a website on IIS or apache?
  • Is your app tightly coupled and monolithic?
  • Are you dependent on networking and / or virtual private networks?
  • Is your solution multi-tenant or do you provision a new environment for each new customer?

These are just a few of the questions you need to answer to begin translating your environment to a Public Cloud architecture. This article will provide you with some more insights on where you might want to go and help you understand where you are right now and where you might go:

What is your incentive to move to Azure?
Additionally, you need an incentive to move your solution to a different platform. I can give you many reasons why you want to do this but to list a few common ones:

  • Efficiency;
  • Simple and automated deployments (DevOps);
  • Staying ahead of the competition (features, global availability, scaling);
  • Competitive pricing (when using the right architecture);
  • Focus on building your solution, not on managing a platform;
  • Eco system.

When we go back to the previous article (choose your strategy before you migrate to Azure) and look at the migration options / strategies then your incentive, combined with your current picture will tell you where your cloud journey will start.

To recap, we had the following strategies mentioned:

  • Rehost (lift and shift);
  • Refactor (repackage);
  • Rearchitect (optimize your code);
  • Rebuild (build cloud native).

If you know what your incentive is, you will get a nudge in the right direction when it comes to architectures. Is focusing on building, development and adding new features to your solution something that drives you to move to Microsoft Azure? Then Virtual Machines are probably not the best way to go and you might want to look into Platform as Service solutions such as App Services or even Serverless.

Then again if you are struggling with availability and management on your current platform then moving to Virtual Machines will give you a whole lot of benefits that you don’t have right now such as automated management, unmatched availability (deploy globally!) and competitive pricing when using the “On and off scenario” or reserved instances.

But if you’re not sure you want to go to serverless and still have some dependencies running on virtual machines to support your solution you might want to start with refactoring (minor adjustments) and look into using containers. Basically, you can start your journey anywhere depending on how much effort you are willing to put into it. But what to look for?

Which platforms
Let’s take a step back and look at the platforms that Microsoft Azure provides. Simply put we have:

  • Infrastructure as a Service;
  • Platform as a Service;
  • Serverless;
  • Software as a Service (Replace).

Infrastructure as a Service
Sometimes we refer to Infrastructure as a Service on Microsoft Azure as Azure Compute as Virtuals Machines make up a big part of this proposition. Basically, what you are getting is  Virtual Machines, networking and a whole lot of additions to that such as back-up, disaster recovery, automated management, security monitoring, etc. But… you are still running Virtual Machines.

The big pro here is that there is virtually no reason you should not be able to rehost your solution to Microsoft Azure based on IaaS. You can run Windows or Linux and you still have full control over your operating system. And you can deploy it globally! But this also means you need to manage it yourself, including the SLA requirements (for instance, run availability sets).

IaaS is suited for most applications that are based on a monolithic and tightly coupled software architecture. If your incentive to move to the Public Cloud is based on global scalability, excellent availability and the on and off scenario then IaaS is for you. A word of caution: IaaS is a great way to start but if you truly want to benefit from everything that Azure (or any Public Cloud) has to offer then you need to plan on moving forward. If you’re willing to put in a little more time and have that financial momentum, then services higher up in the stack might be better suited for you. 

Platform as a Service
The word pretty much describes it, you will get a platform. What’s happening is that when you move into PaaS, you’re taking a lot of management (including that of the operating system) out of the equation.

With Platform as a Service on Microsoft Azure, a lot is managed for you. Such as:

  • Operating system updates, patches, etc.;
  • In most cases you will get a high availability (SLA) by default;
  • Security (note that this is a shared responsibility);
  • Networking;
  • Logging;
  • Authentication (comes out of the box).

Some of the most notable PaaS solutions on Azure include App Services (Web Apps), Azure SQL, Storage and Azure Kubernetes Services (AKS).

With PaaS you will focus on deployment and minor configurations on the platform, but don’t bother with traditional IT operations. In general, this does not require a complete overhaul of your application but it does require you to develop and deploy according to the standards provided. If you want your application to run successfully on PaaS you then have to understand the platform and implement the preferred practices. For instance: if you’re running an IIS website right now and you save files to a local disk, w you might want to consider storing data on a blob storage or implement caching solutions such as Azure Redis Cache, or you will risk limiting yourself in terms of flexibility (look into the concept of stateless).

As with Microsoft Compute, with PaaS you will still pay for what you provisioned. If you run an App Service plan you will pay the price per hour. But: the on and off scenario doesn’t go here. You cannot deprovision PaaS resources, you delete them if you don’t need them. As opposed to IaaS where you can implement this scenario. However, PaaS solutions cost less compared to IaaS solutions so the on and off scenario might not be that relevant.

Serverless
To top it off we have the serverless proposition. Serverless will give you the biggest bang for your buck. It’s platform that is the highest in the stack and completely development driven. Serverless computing is the abstraction of servers, infrastructure, and operating systems.

There are many solutions available (https://azure.microsoft.com/is-is/overview/serverless-computing/) with some of the most notable being: Azure Functions, CosmosDB and EventGrid. Serverless is generally being defined as consumption based. Where you pay a price per hour for IaaS and PaaS, with serverless you pay for what you actually use. Let’s take Azure Functions for example. You will pay €0,169 per million executions, where you get the first million executions for free.

Additionally, the scaling is virtually unlimited and automated. If you execute a function once or hundreds of times simultaneously – the performance will be the same and Microsoft will managed the scaling for you.

Another big benefit of using serverless is that it will allow you to truly deploy your solutions on a world wide scale without much effort. Because you’re focusing on development and not so much on IT infrastructure (as this is being managed for you) all you have to worry about is where you deploy your solution.

Then if you look at data, you might want to look into Azure CosmosDB, the prime example for serverless storage / database. With CosmosDB you get turnkey global distrubtion unmatched availability and no platform management at all and what you worry about it is, once again, where you want to store your data.

To be honest, going to serverless is not the first thing you might think of when coming from a rehosting project but from a cost and efficiency perspective it is definitely the way you want to go. Serverless is best suited for event-driven architecture, Micro service architecture and helps you with decoupling your application (look at Azure Service Bus or Event Grid - https://www.intercept.nl/en/news/is-your-software-architecture-ready-for-innovation/).

Wrap-up
We’ve seen the several platforms you can choose from, but when do you pick what? Let’s do a little recap. First of: Different Architectures comes with different benefits. What you want to do is find the right benefits you are looking for based on your motivation to move to the public cloud and it all depends on where you are in the process right now (Rehost, refactor, rearchitect or rebuild).

To recap, the different platforms have different benefits:

Please note that this list is not set in stone but intended to help you find your way and choose the right architecture.

And this is just a summary of pro’s and con’s that different architectures and platforms bring you. And to be honest, the speed at which public clouds evolve, some challenges may already have been resolved by the time you start deploying your solution. What’s important to understand is that you can start your journey anywhere but you need to have a plan on where you want to go and pick the right platform for your starting point.

Read checklist part 3: the basics of scaling in Azure. 

ISV Roadmap Migrate