In my role with Isobar, I’ve successfully migrated a number of enterprise applications to the Azure and AWS clouds. In the process, I’ve noticed a number of commonalities and taken some lessons learned. I keep these thoughts in mind at all times and have found they greatly contribute to success.
Focus on “Why”
It is always critical to keep the reason why a project is being done in mind at all times, and cloud migrations are no exception to this rule. There are many reasons why a cloud migration may be considered: cost savings, flexibility, disaster recovery, easier maintenance, security, etc. However, the specific reasons and the order of their importance will vary from project to project and organization to organization. For example, if a particular project is primarily motivated to perform a cloud migration for disaster recovery reasons, then when designing the cloud architecture, make sure that disaster recovery is prioritized above, for example, cost savings or cost elasticity.
The goal must always be to satisfy the business. In the world of cloud computing, it’s easy to get distracted by shiny new technologies and buzzwords which can lead to high migration costs, greater risks, and all for limited business value.
Lift and Shift? Cloud Native? Somewhere in between?
The two ends of the cloud migration approach spectrum are “lift and shift” and fully cloud native. Based on the motivation for the migration, the timeline, and the budget, select the most appropriate strategy.
“Lift and shift” means replicating as closely as possible the legacy hosting infrastructure on the new cloud hosting provider. This approach requires heavy use of Infrastructure as a Service (IaaS), meaning that just like in typical data centers, there are servers allocated and software is installed and run on them. For example, in IaaS, a server (an “EC2” in Amazon Web Services terminology) would be activated, then an operator would install the application on it. If there are multiple instances of the application (such as if it was in a cluster), a server would be allocated for each instance and an operator would install the software on each one. If there was a database, a server would be allocated for it and an operator would install the database software and data on it.
“Cloud native” is an approach that takes maximum advantage of the cloud’s specific offerings. As opposed to lifting and shifting the exact software used today using IaaS, the cloud native approach is to migrate to PaaS (Platform as a Service) and SaaS (Software as a Service) offering. For example, the database would be migrated to a PaaS offering like AWS RDS (Relational Database Service) so Amazon would manage the operating system, database software installation, maintenance, failover, redundancy, and scaling, so the customer doesn’t have to.
Lift and shift can be faster to migrate, but is more labor and capital intensive in the long run than cloud native. One common strategy is to lift and shift initially, then over time, replace lift and shifted IaaS components with cloud native ones. This strategy has the benefit of quickly switching to the cloud hosting provider while also eventually resulting in a lower cost, more elastic, easier to manage cloud native solution.
Evangelize the Cloud to the Entire Team
Enterprise applications tend to be very long lived with large teams developing and maintaining them. These teams have been doing the same things for years; they know how to develop features, maintain the application, deal with the infrastructure, and perform the manual processes. From their perspective, “the cloud” is a scary unknown forced upon them by management. Oftentimes, they will be hesitant at best, or they may even outright resist the change.
If the cloud migration effort can get the entire team, including developers, operators, database administrators, quality assurance testers, and project managers, on its side, the chances of success rise greatly. The team needs to be convinced that the cloud is not the enemy, nor will it eliminate their jobs; the cloud migration’s purpose is to improve efficiency so the team can focus on more useful, interesting, and valuable work.
The message to the team needs to be: “the cloud is not here to take your job – it is there to make it easier for you to be better at your job, by putting information that you’d otherwise have to hunt for right there at your fingertips. The cloud will allow you to eliminate manual, error prone processes more easily through automation – reducing errors and making you look like a hero.” This message should be conveyed repeatedly in multiple forms, including education, training, presentations, and in person relationship building.
Have a Long Term Plan
Large, complex applications will be difficult to migrate to the cloud. It’s never possible to reach that ideal cloud state featuring perfect elastic scalability, exceptional fault tolerance, great automation, bulletproof security, and low operational cost immediately. It’s important to have realistic expectations for day 1 and then have a roadmap for how to reach days 2, 3, 4, etc each taking greater advantage of the cloud’s benefits. For example, one approach is to first migrate part of the application to the cloud then use a connection between the cloud and the legacy data center (such as by using AWS Direct Connect or a VPN). Then, after having realized some wins, another component of the application can be migrated.
Another interesting feature of the cloud is that it evolves over time, adding more and more offerings. For maximum benefit, keep up with the selected cloud provider’s news about new features, and plan to take advantage of them as they make sense to the business.
Not All About Direct Cost Savings
Cloud migrations are not all about direct cost savings (although that is often a component of the reason). Many times, the operational cost of the migrated cloud application will actually be higher than its previous hosting solution. So why migrate to the cloud if it will cost more?
The reason is that there are other costs beyond the direct cost of the monthly bill. These costs can be found by considering risks, determining the annualized loss expectancy (ALE) of each, and then factoring those in when comparing the legacy solution and the cloud one. For example, improved fault tolerance means less downtime, and downtime can cost thousands of dollars per hour or more, especially when considering damage to the brand’s reputation. Another is better security; an organization may have difficulty putting a dollar figure on losses incurred from a security breach, but suffice to say it can be quite significant so taking advantage of the cloud’s security risk mitigations can result in a big win. Other such risks and corresponding mitigations include: ease of disaster recovery reducing downtime and data loss in the event of a disaster; zero downtime deployments allowing for more frequent updates; elasticity to seamlessly handle unanticipated high demand; and ease of management to reduce the risk of human error causing downtime or data loss.
As cloud offerings continue to improve over time, those advantages continue to grow – and the direct cost continues to go down. So even if the cloud migrated system’s monthly bill is a bit more now, it’s actually lower when all the indirect costs are factored in. And that monthly bill will likely decrease over time. Plus, the cloud will become increasingly powerful in the future compared to the legacy data center which will stagnate in comparison.
Cloud Migrations Are Big Efforts
Migrating to the cloud is a big change — it’s not just a change in datacenter, it’s a paradigm shift. The migration will impact all parts of the business, including development, operations, testing, management, and even finance. The scope of this effort is important to keep in mind. It’s a lot of work, but there’s a lot of reward too. By keeping these considerations in mind, that reward can be maximized while reducing the number of bumps along the way.
Moving to the Cloud: Get Started With the Basics by Craig Andrews is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
