Introduction

Developers like to rewrite code. After all, it’s easier to write new code than trying to understand the old code, especially if other developers wrote it.

History is full of software that was completely rewritten from scratch, but only some of it was successful (read this article for some examples).

The problem today is even worse because there are two competing sets of forces:

• IT challenges, such as changing nonfunctional requirements like compliance and security, or trying to spend less budget on maintenance and to implement new functionalities (72% of IT budgets are used to “keep the lights on”).
• Evolving business needs to innovate products rapidly to better connect with customers.

Another trend making things complex is the now-inevitable adoption of cloud technologies, public or hybrid.

What to do with existing applications? What’s the right way to move them to the cloud to better use its power while enabling new features?

In this e-book, we’ll try to understand how to modernize existing apps without completely rewriting them. Most of the concepts in this e-book are also valid for a complete rewrite of an app directly in the cloud, or new apps built directly in the cloud.

This e-book is about cloud-enabled apps, so we won’t talk about desktop and mobile apps, but if a desktop or mobile app is using backend services, these services can be migrated to the cloud, which we’ll discuss.

We’re using Microsoft Azure as the cloud for this e-book, but most of the concepts also apply to other clouds, like Amazon AWS or Google Cloud.

What is Microsoft Azure?

Microsoft Azure is a set of cloud services created by Microsoft and available worldwide from 54 regions. Cloud services could be servers, storage, databases, networking, analytics, media, intelligence, compute services, and more, all accessible over the internet. You typically pay for the services you use for the time you’re using them, helping you to lower operating costs and run infrastructure more efficiently. Cloud services can scale quickly as businesses change and can have high service level agreements (SLA). The SLAs for all the Azure services are available here.

Figure 1: Azure regions worldwide (from Azure website)

Since regions are increasing every year, check the Azure website for the updated map and numbers.

Not all Azure services are available in all the Azure regions, and it depends on many factors. One thing that is different from a typical on-premises solution is that you have to check the status of the various services in the regions that you’re using, because different services can have issues at different moments.

Paired regions

Where possible, each Azure region is paired with another region in the same geographic area for maintenance and availability:

• Patches and maintenance are applied in paired regions one after the other, and not in parallel. If something goes wrong, the other paired region is still available.
• In case of global incidents affecting the availability of services, at least one region in the pair is prioritized for recovery.

If you need high-availability requirements, consider deploying multiple copies of your app in various regions, and think about deploying them to regions that are paired so you can recover quickly.

IaaS, PaaS, and serverless

Infrastructure as a service (IaaS) refers to servers, virtual machines, storage, networks, and so on. You rent IT infrastructure and must configure, monitor, and upgrade it when needed.

Platform as a service (PaaS) refers to more advanced cloud computing services used to create and operate web apps or backends easily, while hiding the complexity of the underlying infrastructure. With PaaS services, you only need to configure and manage the capacity of your services; all the other aspects are handled by the cloud provider.

Serverless computing is a special case of PaaS, where the cloud provider also manages the capacity of the service, and you pay only for the transactions that are executed and the actual resources that are used in real time.

Microsoft Azure implements all these types of services, and some of the products can work in different ways. For example, Azure Functions can work in a pure serverless way, where you pay for the actual transactions, or in a PaaS way, where you pay for the allocated underlying resources.

In the following figure, you can see a partial list of various Azure services.

Figure 2: High-level view of various Azure services

Software as a service is when software is sold “as-is” with minimal customization, using a pre-paid or subscription model, directly from the vendor from its datacenter or cloud subscription (like Office 365 or many offers that can be found from independent software vendors).

The road from on premises to migration, app modernization, and cloud native

If you have an app that is running on-premises on physical or virtual machines, the most natural path to the cloud is migrating the solution to the cloud as-is, in a typical “lift and shift” approach.

With lift and shift, you migrate everything: the same (or similar) hardware configurations, the same OS (or a newer version that is available and tested with the app), the same network topology, and so on.

If your app is already running on premises inside containers, they can usually be moved to the cloud easily. If your web app is running inside a web/application server like IIS or Tomcat, and it’s not using advanced features, it can be migrated to App Services with very few modifications. All these scenarios are included in the migration or lift-and-shift approach.

If you don’t know about containers, App Services, or other PaaS or cloud-native services, they will all be explained in the following chapters.

App modernization refers to making more advanced modifications to the app to better use the power and flexibility of the cloud, to reduce VM or container utilization, and to better use built-in features of PaaS components (such as Azure App Service or Azure SQL Database). An app that is modernized for cloud services is often referred to as cloud-optimized.

Cloud-native apps are built from the ground up to the cloud. They are optimized for cloud scale and performance. Cloud-native apps are based on scalable architectures (like microservices), use PaaS or managed services when available, deploy containers using orchestrators (even better if managed by the platform), and are deployed using continuous delivery to achieve faster time to market and reliability. You can take a look at this article for more on building cloud-native apps in Azure. Cloud-native apps are so important that a foundation was created to sustain and integrate all the related open-source technologies: the Cloud Native Computing Foundation.

There is no one-size-fits-all strategy­—you should get to know all of them and think about the expected value for end users, how the various approaches allow for app evolution, how requirements change over time, and so on.

Apps can be moved to the cloud in part with a lift-and-shift approach, in part by using app modernization, by rewriting the most critical elements as cloud-native microservices, or by using serverless features to achieve the best result.

Note: Here’s a simple example: an app is migrated using a VM (or a set of VMs) while the database is moved to Azure Database to stop it from needing to be maintained manually.
This scenario is typical when the database is not using advanced features that require running it inside a VM. Azure Database can use SQL Server, MySQL, MariaDB, or PostgreSQL database engines, and is fully managed to lower TCO and improve availability.

When the app is running in the cloud, new features can be written using microservices running in containers, or using serverless capabilities. Advanced features can be added on top of those using cognitive services, machine learning, and other AI capabilities; big data can be stored inside data lake technologies and analyzed when needed; and so on.

How to choose the right compute service in Azure

It’s not easy to decide which services are the right ones to use when migrating, modernizing, or writing an app from scratch. A starting point can be the following flowchart, described in the Azure documentation. It’s useful because it’s easy to follow, and it exposes some of the questions that drive the selection of the right compute service.

What’s missing in the flowchart are essential points that need to be analyzed deeply before deciding, like:

• Service cost, region availability, and SLA.
• Feature set and service limits.
• Supported technologies.
• Developer skills.
• Operational skills.

We’ll see most of the services and their implications in the next chapters.

Figure 3: How to choose the right Azure compute service (Source)

Edge computing and hybrid cloud

Edge computing was discussed for the first time in 2008 by the Microsoft Research team. It’s an extension of cloud computing, where computing resources are placed closer to sources of data to reduce network latency, bandwidth usage, and cloud computing costs, since initial processing and filtering of data are executed on local hardware.

The experience for users is better because, in most cases, the system can also run with limited network outages and data is synchronized later if needed.

There are many systems that can run at the edge, from credit-card-sized computers to hybrid cloud devices:

• Azure Sphere: Linux-based, internet-connected microcontroller devices with enhanced security.
• Azure Stack Edge (previously known as Data Box Edge): A (portable) appliance that can analyze, preprocess, and transform on-premises data before sending it to Azure. Includes advanced processing capabilities like the ability to run Azure Functions, execute AI and ML tasks (with dedicated FPGA hardware), and more.
• Azure IoT Edge: A fully managed service that deploys cloud workloads (AI, Azure Functions, other Azure and third-party services) on standard Internet of Things (IoT) edge devices using containers.
• Azure Stack Hub and Azure Stack HCI: Extensions of Azure that run on premises to host hybrid applications anywhere, with great compatibility of SDKs, APIs, and admin tools.
• Windows IoT: Run security-enhanced IoT solutions on many different IoT systems, using Windows as the foundation.

Edge computing and hybrid cloud are outside the scope of this e-book, but most of the technologies discussed in the e-book can also be used (in one form or another) on the edge. You can find more information here.

Figure 4: Azure hybrid landscape

Azure Arc: manage any infrastructure

Azure Arc is a new capability that allows for managing Linux and Windows servers and Kubernetes clusters on any infrastructure, on premises, multi-cloud, and edge.

With Azure Arc, it’s possible to use ARM templates, Azure Cloud Shell, Azure portal, Azure API, and Azure policy (see the next chapter) to manage environments not running on Azure with a significant simplification of tools and procedures.

Azure Data Services

Built on top of Azure Arc, Azure Data Services anywhere allows you to run Azure SQL Database and Azure Database for PostgreSQL Hyperscale (see Chapter 7) on any Kubernetes cluster, on premises, or on other clouds.

DevOps: How to deliver faster and more reliably while moving from one stage to another

One definition of DevOps (taken from this article by Donovan Brown, Principal DevOps Manager at Microsoft) is:

“DevOps is the union of people, process, and products to enable continuous delivery of value to your end users.”

Having a DevOps approach enables us to test, implement, and deploy migration, modernization, and cloud-native strategies with better control of the outcome, and the ability to test different solutions in parallel. If you don’t know anything about DevOps, you can read this detailed article by Sam Guckenheimer, chief customer advocate for DevOps at Microsoft. The essential DevOps practices include agile planning, continuous integration, continuous deployment, monitoring, automatic rollback when needed, and continuous feedback.

Figure 5: DevOps cycle (Source)

Azure DevOps works with all platforms, languages, and cloud providers, and it’s free for open-source projects. It can be used for free for five users for other kinds of projects, and Visual Studio subscribers already have the license.

You can check the Azure website for official pricing information. Please consider that licensing and pricing information contained in this e-book could be outdated by the time you read it; be sure to check the pricing website or the Azure pricing calculator.

Azure DevOps is also available as a stand-alone product that can be installed on premises: Azure DevOps Server.

Every other tool or set of tools can be used to obtain the same result if applied correctly.

Azure DevOps is currently composed of five main components, which can be used together or independently:

• Azure Boards: Agile tools for planning, tracking, and discussing work across your teams.
• Azure Repos: Unlimited, cloud-hosted private or public Git repositories with pull-request integration and advanced file management.
• Azure Pipelines: Powerful CI/CD engine that works with any language, platform, and cloud. It can also be connected to GitHub or any other Git provider.
• Azure Artifacts: Host and share packages with your team and add artifacts to your CI/CD pipelines with a single click.
• Azure Test Plans: Manual and exploratory testing tools. Please remember that the Coded UI test and cloud-based load testing are deprecated, and will not be available after Visual Studio 2019. Cloud-based load testing will stop working during 2020.

A typical cycle using Azure DevOps (and other Azure features like Automation and Monitor) can be represented in the following figure.

Figure 6: A possible cycle using Azure DevOps

Small, medium, and large companies can use a DevOps approach. Of course, many adjustments are needed for large companies. In the following figure, you can see some numbers from Azure DevOps adoption within Microsoft.

Figure 7: Azure DevOps adoption inside Microsoft, updated February 2019

GitHub is a valid alternative to Azure DevOps, and the two tools can be integrated at various levels. GitHub users can have public or private repos, and GitHub Enterprise can be used on premises or privately on the cloud subscription of a company.

Figure 8: Azure Pipelines integration in GitHub

Every technology is welcome

It doesn’t matter if your app is built with .NET Framework, .NET Core, Java, NodeJS, Python, or Go—every app can be ported to the cloud, modernized, or written in a cloud-native way. What differs are the options that you can use. For example, with the .NET Framework you cannot use normal Docker containers; you should use Windows containers. If you want to create Serverless Azure Functions, only a few languages and platforms are natively supported, but you can “wrap” the others using a Docker container.

We’ll explore some of the differences in the related chapters, and we’ll also talk about how we can mitigate those differences when possible.

Azure Portal, subscriptions, and resource groups

Azure Portal is the entry point to all your Azure resources. You can do everything from the portal, or you can use Azure CLI, PowerShell, or Azure SDK for many languages, or the Azure REST APIs to manage your resources, create, delete, modify, and so on.

An Azure subscription is tied to billing and management. One user can have many subscriptions, and in every subscription, can have different roles.

Azure subscriptions are also a boundary for networking: you can, of course, connect services spanning multiple subscriptions, but you might incur extra costs.

There are many ways to create an Azure subscription: using a trial, student account, Visual Studio subscription, pay-as-you-go subscription, or a contract with a cloud service provider (CSP).

For the scope of this e-book, you’ll need an Azure subscription in which you can create your resources. You can get more information about billing and cost management here.

An Azure resource group (RG) is a logical collection of related Azure resources. You need to have at least one RG in the subscription, but it’s usually better to create one or more RGs for every project. Resources in the RG can be in multiple Azure Regions when an RG is created; the selected region is used to store the metadata of the RG for compliance reasons.

You can find more information about RGs here.

The scope of this e-book

As you will see, there are so many services that you can use to migrate, modernize, and make your application a cloud-native app. The scope of this e-book is not to give you a 100 percent solution, because there are so many requirements and constraints. The scope of this e-book is to explain different technologies and use cases and let you decide what’s the best way to accomplish your task, considering, for example, your expertise, the expertise of your team, your customer’s operations policies, and so on.

Last but not least: company culture

This chapter cannot be complete without talking about company culture. Moving applications to the cloud, modernizing applications, or creating new cloud-native applications require a different approach than traditional ones. Applying efficient DevOps processes is just a part of the change that is needed. Customers expect cloud-enabled applications to always be available, scalable, and updated frequently with little-to-no downtime—and those features require a completely different approach. These are some of the things that you should consider:

• Every process related to the app should be well documented, repeatable, automated, and doable by all the people involved. Scenerios like “it only works on my machine” or “we have to wait for John to update the app” should be avoided at all costs.
• Security should be at the center of every activity from the beginning, not an afterthought.
• Operations people should be involved in the beginning—apps can’t just be handed to them at the end of development. This goes much deeper than just adopting DevOps; it means planning for operations, management, and monitoring from the beginning.
• Quality should be the responsibility of everybody, not just testers.
• Change management processes should be efficient. Decisions should be fast, and ideally, it should be possible to roll back a failed deployment or a version that is not right in terms of features, quality, stability, performance, or whatever.