Achieving success with cloud adoption remains an elusive challenge for many organizations. But why is that the case? After all, there are countless tools designed to facilitate the process of taking on-premises operations to the cloud. It is common to use these purpose-built tools for moving virtual images, automatically provisioning services, migrating data, right sizing deployments and optimizing cloud operations. But when it comes to application migration, this variety of infrastructure tools actually contributes to the problem.
These disparate systems certainly work well enough for their specific use and purpose. However, successful execution of application rehosting requires that users look above these infrastructure tools to see the full picture and select the tools appropriate to the specific migration method, or "R approach" — rehost, replatform, repurchase, refactor, retire, retain — for the application.
Perhaps the most interesting thing about these point solutions is that they all focus on infrastructure migration tasks, while selecting the R approach and the specific sequence of steps required are entirely dependent on the application and business goals. How is it possible to decide which R method is optimal or appropriate if you never look into the application requirements? Before committing to a specific path for each application, it is essential to consider the business needs for its availability, access, performance and the total cost to achieve the migration.
Of course there will be times where a straight rehost (often called a "lift and shift") will be appropriate and optimal. This is especially true for mobile workloads that are self contained on a specific server with few external dependencies, no external storage and no requirement for real time app-to-app communications. In other cases, a rehost may be possible, but not desired. For example, rehosting may violate corporate information security policies such as HIPAA or GDPR. Or perhaps some refactoring or reconfiguration is required to achieve target availability goals. Organizations should assume no more than 10-20% of their total server inventory will be highly mobile and ready for an automated rehosting process.
In our experience, organizations that proceed with an "infrastructure first" approach quickly recognize that it does not take into account the impact on critical business applications early enough in the process. Unfortunately, this approach often results in wasted time as plans must shift once the business factors are acknowledged and considered. Taking an application-centric approach is the only way to orchestrate a successful cloud migration.
Know Your Environment Before You Commit to a Migration Approach
Cloud-native platforms typically provide much more agility and flexibility than lifted premise ones. Refactoring apps can be costly and time consuming, so some organizations prefer the lift-and-shift approach. But before you make the decision to take a lift-and-shift migration approach for an application, carefully consider your current environment, your business and IT goals, and expected cost and staff impact first. Simply shifting a legacy, premise-based app to the cloud with all its limitations instead of refactoring it may limit you from taking full advantage of all the benefits associated with the cloud.
Bottom line, tools to support general planning and to assess server mobility can provide useful data points, but are not sufficient for comprehensive planning. Developing appropriate migration plans requires a comprehensive understanding of the entire environment including appropriate information from siloed tools and application SMEs (subject matter experts). Applications should be identified and assessed for readiness: some will be able to be migrated immediately, while others will have to be rewritten or modernized to be workable in the cloud. The indispensable first step for any migration is having an actionable picture of the entire data center, which includes:
■ Accurate information about where apps reside, who owns them, and what SLAs, RTOs, RPOs apply.
■ Complete knowledge regarding the application dependency landscape. Don't just rely on autodiscovery. Your subject matter experts know the ins and outs of your business and will be able to tell you things that machines can't detect.
■ A normalized view of the landscape.
■ Visual dependency mapping of the entire landscape, including what applications are dependent upon, and what is dependent upon them.
■ An understanding of what applications should generally be "grouped together" for a cloud move.
■ The ability to distinguish superfluous data from information that matters. For example, the operating system, manufacturer/model, and IP address are commonly used data points in migration analysis and planning activities, while other information such as CPU speed, MAC address, BIOS, and OS Install Date are simply not necessary or beneficial to the migration activities. Tracking unnecessary data will distract the team and slow down discovery. Don't boil the ocean; just capture the data you need.
Application migrations are among the most complex projects an organization can undertake and require a cautious approach. If you take the simplest path, assuming that rehost is the preferred approach, then rapid early progress can be achieved by first focusing on the easiest mobile workloads. But once you complete the migration of the easiest workloads, the progress will come to a screeching halt. The majority of your app-to-cloud migrations will require deeper analysis, more careful planning and choreographed execution to assure success.
Orchestration of such an ambitious and sometimes treacherous initiative may seem to be an elusive goal. To avoid mishaps or stalled projects, here are several tips for orchestrating successful outcomes of your cloud migration initiatives:
1. Move up the stack, take an application-centric approach
2. Establish visibility across all silos and users
3. Don't boil the ocean – leverage a sprint-based, iterative approach
4. Leverage existing info and tools where available
With a disciplined approach, you can drive successful outcomes for your cloud adoption initiatives. You'll achieve greater agility and scalability in hosting solutions while avoiding any unplanned outages of your business applications and services.
Part 3 of our three-part blog series on the shortcomings of traditional APM solutions for monitoring microservices based applications explains how the alerting and troubleshooting capabilities of traditional APM do not address the evolving requirements of monitoring microservices based applications ...
In a digital world where customer experience defines your business, is your APM solution doing its job? This may seem like a strange question to open a technical blog on Application Performance Management (APM), but it's not. With customer experience today largely driven by software, we think there's no more important question to ask ...
According to the NetEnrich 2019 Cloud Adoption survey, 68% of enterprise IT departments are using public cloud infrastructure today, and 27% of respondents said that doing so is part of their near-term plan ...
Organizations and their IT teams are not in sync when pursuing their digital transformation strategies, according to a new report released today by The Economist Intelligence Unit ...
Having the right tools and good visibility are critical to understanding what's going on in your network and applications. However, as networks become more complex and hybrid in nature, organizations can no longer afford to be reactive and rely only on portable diagnostic tools. They need real-time, comprehensive visibility ...
When building out new services, SaaS providers need to keep in mind a set of best practices and "habits of success," which cover their organization's culture, relationships with third-party providers and customers, and overall strategic decisions and operational know-how. If you're a SaaS application provider, here are five considerations you need to keep in mind ...
In the coming weeks, EMA will be gathering data on what we believe is a unique research topic — approaching DevOps initiatives from the perspectives of all key constituents. We're doing this to try to break through some of the "false walls" created by more niche, market-defined insights, or some of our industry hyperbole. Here are some of the directions we're pursuing ...
An application on your network is running slow. Before you even understand what the problem is, the network is blamed for the issue. This puts network teams in a dangerous position — guilty until proven innocent. Even when network teams are sure an issue doesn't stem from a network problem, they are still forced to prove it, spending sometimes significant amounts of time going through troubleshooting processes, looking for a problem that doesn't exist ...
Tap and SPAN. It's the same thing, right? That answer would be wrong. Some network engineers may not know the difference, but there are definitely clear and distinct differences between these two types of devices. Understanding these differences will help you elevate your game when it comes to network performance monitoring and application performance monitoring ...