Cloud migration. It’s a term that comes up in most enterprise conversations at least once. While the term represents the practice of moving from on-premises infrastructure to cloud infrastructure, what is meant by “cloud migration” has evolved. Cloud migration is no longer as simple as moving from on-prem servers to AWS EC2. It include moving to managed databases or API gateways, or maybe you need AWS for some workloads and Azure for others. could Perhaps you’re a financial or public sector organization, and you need a private cloud. Or maybe you need to meet special regulatory requirements. In this article, we’re going to look at three best practices for making cloud migration easier for your enterprise: Refine your culture. Engage in intelligent change. Observe and monitor. By applying these guiding principles to your organization’s cloud migration effort, you’ll avoid turning the cloud migration effort into an aimless and inefficient slog. Instead, you’ll have the organizational awareness and the tools in place to tackle the job with confidence. Before we dive right into our best practices, however, let’s first touch on the different approaches typically used during cloud migration. Cloud Migration Approaches: The 5 R’s Though there are guidelines for cloud migration, there is no one-size-fits-all approach. Today’s cloud environment is complicated by the diversity of options, industry nuances, and business needs. Traditionally, businesses needed to take an approach from one of the following Five R’s: : This is your traditional lift-and-shift approach. For example, you have applications running on-prem in VMs, and you redeploy your application to VMs running in a cloud. Rehost : This is similar to , except that you have a midpoint step to make tweaks (lift, tweak, and shift). Refactor rehost : This is an amalgamation of and . The approach often includes significant application changes to leverage the capabilities of the destination cloud. Revise rehost refactor revise : This takes your effort one step further than the approach by, in some cases, fully rebuilding applications to leverage the destination cloud’s capabilities. Rebuild revise : With this approach, an organization cordons off and removes a piece of functionality that was being maintained in-house, replacing it with a third-party option. Replace Now, let’s take these and put a modern cloud spin on them: : You have applications running on-prem in VMs that you redeploy to VMs running in . Rehost multiple clouds : Your midpoint step makes tweaks . Refactor for each destination cloud : You include significant application changes to leverage the capabilities of . Revise each destination cloud : You fully rebuild applications to leverage destination cloud capabilities. Rebuild multiple : You replace pieces of functionality with third-party options. Replace potentially multiple Talking about multiple clouds, specialized use cases, or industry regulations quickly compounds the complexity of cloud migration. Even amid this complexity, organizations can follow three key best practices to smooth out and simplify the cloud migration effort. #1: Refine Your Culture Perhaps one of the most difficult yet rewarding best practices is cultural refinement. You probably have a loose idea of who’s in charge of what pieces of your technical estate, and that’s a good start. However, before attempting a cloud migration, much more awareness is necessary. Identifying responsibilities One good technique is to use a for a given component or domain. This will clearly show who is responsible, accountable, consulted, and informed for all of the changes that will be happening during the migration. The cloud moves fast, and your team needs to move faster. Knowing who to go to for each piece is key. RACI matrix Tracking Metrics Another piece of the cultural refinement is not just key metrics, but also ! Many are hesitant to take this approach because it often shines a light on operational inefficiencies. Remember: If it’s not measured, it can’t be improved. identifying putting those metrics in writing This practice should be adopted at various levels. From the application-team perspective, metrics around network and storage latency may be important. For the management level and higher, however, composite service level objectives (SLOs) that show a high-level team metric may be more important. Be clear and concise on what comprises an SLO and, if possible, standardize the generation of the SLOs among as many teams as possible. While you might have service level agreements (SLAs) to enforce contractual guarantees, SLOs help your entire organization understand how application performance and reliability impact your customers and the overall business. Remember, SLOs enable SLAs, and SLAs enable your customers. Answer Business Questions Efficiently Carrying forward the idea of codifying metrics, it’s essential to lower the bar for observability and monitoring. If a team member needs to copy and paste a PromQL query in order to answer a business-impacting question, you can consider this an opportunity for improvement. This can be an expansive and complex topic, but ultimately it comes down to answering business questions as quickly and accurately as possible. Most often, this is achieved by coupling your data store(s) with a flexible visualization system that’s open and available for all levels. #2: Engage in Intelligent Change Change management often conjures up the image of a stifling board of attendees whose sole jobs are to poke holes in progress and to say no. Luckily, that’s not what’s meant by “intelligent change.” Intelligent change is an approach to cloud migration that uses technical gating instead of process gating. In other words, protection should be enforced through automated processes like end-to-end testing, continuous integration, and provability through distributed tracing. Pieces that can’t be covered by technical gating (or would require a non-trivial amount of work) should be moved lower on the migration list. The process of creating the technical gating for smaller or easier workloads often paves the way for more complex pieces to follow the same processes. Work through each piece iteratively until a sufficient level of correctness and functionality is achieved, then rinse and repeat. #3: Observe and Monitor Observation and monitoring are critical to validating the success of your cloud migration effort. Before the effort begins, then, it’s important to make systems and applications if they’re not already. Observability is not the same thing as monitoring. Monitoring is, in a sense, observing observability. observable As an example, you can monitor if a database is up or down based on whether or not you can make a connection to it, but a database is observable when you can see utilization metrics, query times, and active connection counts. Second, make systems and applications if they’re not already. This is how you make informed decisions based on observability. Examples of questions to ask yourself include: monitorable Can I send alerts based on monitoring data? Can my infrastructure self-heal based on monitoring? How long does it take me to answer X about a system/application? In essence, monitorability is the nexus of decision-making during a cloud migration. Without it, success is difficult to achieve if at all. Lastly, it’s paramount to have a single pane of glass through which you can trace back each change, deployment, and ideally, the lack of impact on the environment. The ability to zero in on likely culprits of issues during your cloud migration is critical. Wrapping Up In reality, there are many best practices, probably enough to write several in-depth books about how to migrate to the cloud. These three practices give you the “who,” the “what,” and the “why” of how to migrate . Now the difficult part is, what tooling should you use? successfully There’s always the roll-your-own option, but if you’re staring down a cloud migration (especially in a large tech estate), going with a homegrown option will make things more difficult. For a cloud migration, we would almost always recommend choosing an established vendor, of which there are many. One particularly good option is Lightstep. Lightstep is building SRE tools for the cloud-native enterprise including observability, monitoring, and incident response. One of the key use cases for their platform is cloud migrations! Also published here.

Trace

Building a Slack App with Native SFDC Integration

How to Build a Slack App That Changes Salesforce Records Within Slack

I write about technology michael.bogan@gmail.com

Nominated for 2022 - HackerNoon Contributor of the Year - Software Architecture

Nominated for 2022 - HackerNoon Contributor of the Year - Microservices

Nominated for 2022 - HackerNoon Contributor of the Year - Devops

Nominated for 2022 - HackerNoon Contributor of the Year - Api

Nominated for 2022 - Software Developer of the Year

Nominated for 2022 - HackerNoon Contributor of the Year - Software

Too Long; Didn't Read

How Do You Make Cloud Migration Easier?

How Do You Make Cloud Migration Easier?

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

10 Threats to an Open API Ecosystem

10 Ways to Future-Proof Your Business With Cloud

10 Upcoming DevOps Conferences for 2018

101 Stories To Learn About Cloud Infrastructure

The Ten Top Cities for Highest Cloud Engineering Salaries

10 Threats to an Open API Ecosystem

10 Ways to Future-Proof Your Business With Cloud

10 Upcoming DevOps Conferences for 2018

101 Stories To Learn About Cloud Infrastructure

The Ten Top Cities for Highest Cloud Engineering Salaries

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps