· Tim Pruitt · Articles · 4 min read
Migrating from On-prem to the Cloud
Its rare that one migration strategy will fit even two like organizations the same way.
“Let’s put all of our applications in the cloud, we want to be a cloud company.”
Great ideas can become poor ideas in a flash when poor strategies are implemented. Its rare that one migration strategy will fit even two like organizations the same way. There are many considerations that, if overlooked, can produce a disastrous outcome in the middle of your migration project. The design of your new cloud architecture will have a major impact on the ability to control costs, administration, growth, and change.
The benefits of moving to cloud infrastructures include cost savings, automation of deployment, application performance, and leveraging built-in technologies to produce real time analytics or feature enhancement. You are probably aware of these benefits hence the desire to move in this direction. It is important to consider the many approaches to migration and design to maximize these benefits. Simply existing in the cloud may not get you there.
What technologies are in place and in which areas of expertise do your developers thrive? Is it time to change application platforms? What can AWS, GCP or Azure provide that would allow us to retire certain applications? What level of effort is required and how long will it take? Your team or chosen partner should consider these questions and more when conceiving the environment which will be so critical to operational success. There are many strategies to migrating applications to the cloud. Most projects will require considering multiple strategies for maximum effectiveness.
Lift and Shift:
Most projects begin with this strategy in mind. Re-hosting…it is simple to conceive and quick to implement. If your project has time as its most weighted factor, this strategy in conjunction with import/export tools can get your environment out of your data centers quickly and seamlessly so you can start pulling cables and shutdown facilities.
The re-hosting strategy does have its pitfalls. While quickly establishing your application in a cloud environment may seem to be a benefit it may be an extra step to achieve your actual goals. For example, migrating load balancers into AWS as cloud appliances would be a significant cost in comparison to moving load balancing to AWS provided elastic load balancing. In general, overlaying traditional networking concepts onto a cloud platform is more expensive and requires more administration. If the goal is speed, lift and shift is quick but could require additional projects to evolve those applications to realize cloud benefits.
Re-Platforming:
This strategy will ultimately produce the best results in terms of running smoothly within the cloud environment. By migrating as many applications as possible to cloud provider components, deployment, security, administration, and cost management become simpler and more effective. AWS cost explorer, for example, becomes a very handy built-in tool to identify cost saving opportunities. This tool works best with AWS components i.e. EC2, NAT Gateway, and S3 to pinpoint where costs are generated. You may realize your NAT gateway is not optimized for cross-zone traffic and is costing much more than it should.
Re-platforming also allows for built-in monitoring and logging to perform optimally. You may be able to eliminate that expensive Splunk licensing or alerting service. Overall administration of the cloud platform regarding deployment and scaling are generally simplified.
Re-Engineering:
In cases where an organization wants to customize and develop applications in the cloud, applications may need some re-engineering to use the cloud provider tools. Developing tools provided by the cloud provider have some major advantages to enhance productivity. Templates, deployment tools, data models, and platform management can all contribute to efficiency in development and deployment.
Discussing best strategies is circumstantial. You will need to find members of the team or a partner with the experience and wisdom to identify what exists, what is desired, and how to get it to the desired state. Operational knowledge and design knowledge should not be confused but should work hand in hand. Companies should consider the right personnel for the job. A software developer may not be the best person to deploy instances and configure routing or VPN, while a data center engineer may not understand the software aspects well enough to design auto-scaling groups. This is where DevOps comes in to play.