Migrations to another environment can be trivial for some applications, but it’s a complex array of different parts that all work together for most of them. Migrating such applications is a complex task of analysis and decision-making oriented around many different factors. Most application migrations to Azure begin with prework that performs business analysis on the organization. This analysis determines the set of governance and security practices an organization uses and implements in the cloud.

On Azure, this initial set of services and feature configurations is an Azure Landing Zone. Once the Landing Zone finishes, applications can begin migrating into Azure. As with most things in the cloud, there is generally more than one way to accomplish a task. Application migrations are no exception and typically take one of three different paths into the cloud: IaaS, PaaS, or containers.

IaaS, or Infrastructure as a Service, leverages virtual machines on Azure for application hosting. Applications in this context run more or less as they did when they were in an on-premise environment. Users, therefore, are responsible for the configuration and maintenance of virtual machines on Azure.

PaaS, or Platform as a Service, is a hosting platform that enables users to run applications in a managed environment without the responsibilities of maintaining the underlying operating systems and compute.

Containers offer a middle ground between IaaS and PaaS. They provide a mechanism to encapsulate an application and all of its dependencies into a deployable package. The package can run across many hosting options, some of the more managed than others. The amount of infrastructure exposure depends on the container hosting options. With something like Azure Container Instances, there is no infrastructure exposed, while with Azure Kubernetes Services, the infrastructure is exposed but partially managed by Microsoft. Containers themselves also require that the user configure the dependencies, usually things like runtimes and supporting components like web servers.

Comparing IaaS, PaaS, and Containers

These three paths are not three mutually exclusive paths and can be mixed and matched depending on the context. Often, all three options will work for applications.

The technical feasibility of a path into the cloud, though, is not the only determinant. Several non-technical and non-functional priorities factor into these kinds of decisions.

  • Agility – How fast does the organization want to move to the cloud? Hard deadlines, such as end-of-lease agreements or depreciation schedules for older hardware, demand that an organization move fast. For these sorts of deadlines, moving as much to the cloud as quickly as possible is imperative. Other organizations are not as bound by time constraints and can therefore more slowly. Agility then would not be a high priority.
  • Flexibility – How much leeway does the organization need in the environment? Some hosting environments come with assumptions that may prevent some applications from running on these environments. Such environments are said to be opinionated. Some organizations are fine with these constraints and are willing to adapt to the constraints. Other organizations want the flexibility to run whatever application they want by whatever means they want. For such organizations, having all options available is, therefore, a priority.
  • Management – How much management responsibility does the organization want to take on for applications? Some organizations want to get out of managing infrastructure and other environments because these sorts of environments require large commitments to human resources to manage them. Other organizations, however, are okay with managing environments because they are mature in their practices and like to keep things more homogenous across all deployments.
  • Tooling – What tools exist to help assist and expedite an app migration? Tooling assists in both the assessment of environments for its readiness to move to another and assist in the actual migration process. One such tool, Azure App Services Migration Assistant provides a detailed report for .NET and PHP applications hosted on IIS and their readiness to move to App Services. Better tooling improves planning, and thus more manageable outcomes for a migration.
  • Familiarity – How familiar/comfortable is the organization with the technologies and tooling? Adopting a cloud hosting environment for applications requires learning new skills no matter what option one chooses for a migration. Some organizations, though, have lower thresholds than others for learning new paradigms and technologies and are more comfortable and better equipped to stick with what is most familiar to the organization.
  • Cost – How much does the organization want to spend on hosting and maintaining apps in the cloud? Cost in the cloud can be viewed in several ways and goes beyond the monthly bill for that month’s consumption. For costs, looking at the total cost of ownership (TCO) gives a better picture of costs in the cloud versus other environments.
    • Capital Expenditures vs. Operational Expenditure – Accounting distinguishes capital expenditure and operational expenditures for tax purposes. Consumption-based computing typically lowers CapEx while raising OpEx at the same time.
    • Soft Costs vs. Hard Costs – Hard costs are typically directly associated with expenses directly related to running systems, such as hardware and software licensing. Soft costs include indirect costs, such as employees’ salaries, electricity, physical security, and the like. Cloud computing tends to roll the expenses related to soft costs and hard costs into a monthly bill, while on-premise systems only periodically expose hard costs.

IaaS, Containers, and PaaS options work better with different priorities. For instance, if an organization wants to move fast to the cloud, migrating virtual machines is oftentimes one of the fastest ways to do that because it requires no refactoring efforts or re-platforming efforts on the part of the applications hosted on those virtual machines. Likewise, sometimes priorities compete with one another. For instance, flexibility often comes with the added expense of more management. The following is a chart summarizing priorities against the kinds of offerings.

Priorities Compared

The nexus of technical requirements and non-technical priorities, though, does not always translate into clean decisions for many different reasons.

  • Technology choices may require an option that goes against priorities. In some cases, historical technology makes some options less desirable than others. For instance, Ruby applications have no native PaaS solution for running Ruby applications on Azure. If an organization has priorities that lean towards PaaS, then the technology choice would go against those priorities. The organization must change its priorities considering this.
  • Different teams have different priorities. In some organizations, different teams will have different priorities, which can impact the overall organization. Some teams may prefer infrastructure because they are familiar with it, while other teams may prefer PaaS because it enables them to iterate quickly without dealing with infrastructure.
  • Priorities can compete with one another. As mentioned, flexibility and management tend to stand in contrast to one another, and it isn’t easy to have both flexibility and minimal management at the same time. However, other conflicts may not be so obvious.
  • Letting technology, not business value, drive decision-making. Technologists love to work with the technical aspects of applications and systems. Technology for technology’s sake, however, is often a poor factor for making decisions. Technology influences these decisions, but ultimately, the business value should drive business decisions, not technology.
  • Analysis paralysis results in inaction. Factors like fear of the unknown or the struggle to find a perfect solution drive overanalysis. Fear of the unknown will make risk-averse organizations and individuals never commit. Similarly, others will want a perfect solution that will make an organization stall. There’s almost always some idiosyncrasy or caveat that makes a platform less than ideal with any new platform. Organizations should do due diligence for assessing applications, but at some point, decisions must happen.
  • Migrations start too soon! Start a migration with governance and security FIRST! The tendency for many organizations is to start migrations before establishing governance and security. Migrations come after the governance and security aspects of cloud providers have been established.

When considering migrations into Azure, there is no “wrong” way. Instead, the path chosen should be thought of as the “best” way for an organization. Other organizations may opt for a different path. Regardless of the path chosen, setting priorities helps guide the decision-making, and therefore delivers more value for the organization.

Do you have legacy applications that need modernization or to be migrated to the cloud?
Request a free 4-hour advisory session with our team