Moving to the cloud is a major infrastructure change for any business. Unless you’re starting from scratch, switching to the cloud requires getting your existing data and applications there. For data, transfer may mean sending files over the wire or physically shipping a storage device to the cloud provider. For applications, the major choices are re-architecting, taking advantage of cloud-native capabilities; re-hosting, a simple “lift and shift” of an application in its current form to the new hardware; and re-platforming, which does a partial re-architecture in the midst of lift-and-shift.
Re-architect, Re-host, Re-platform
Amazon Web Service’s Head of Enterprise Strategy, Stephen Orban, described these options in a post on medium.com.
The main goals of re-architecting are to take advantage of cloud-native capabilities. This means breaking an application down and rebuilding it in a service-oriented, scalable design. Doing this lets you get the most benefits from a cloud platform, allowing you to easily add capacity and manage the cost of the service. It positions applications for future agile development and DevOps deployment approaches to speed new functionality to production.
Re-architecting requires understanding the cloud platform and the application in depth, including its functionality, its data, its performance requirements, and its usage patterns all so you can refactor it. Taking advantage of cloud-native features requires applications to follow a scalable, service-oriented framework with built-in redundancy to handle failures. Because companies lack experience with the cloud when they are getting started, developing the necessary understanding can be a challenge and migrating a re-architected application will take longer than the re-hosting approach.
Re-hosting simply takes the existing application in its current architecture and deploys it on new hardware in the cloud. This requires much less analysis and testing than re-architecting the application would, and allows companies to migrate an application to the cloud more rapidly. Companies are still able to obtain some of the promised cost benefits of the cloud with this approach.
Re-platforming is the middle ground between those two approaches. An application isn’t completely rebuilt, but it isn’t migrated as-is, either. Instead, a few quick, easy wins that leverage some cloud-native functions are implemented, while the rest of the application is unchanged.
Re-architect Now or Re-architect Later?
The decision to re-architect or re-host can be made based on several factors that acknowledge both technical and business requirements. Some businesses have a desire to go all-in on the cloud and start using its features from the beginning, supporting the choice to re-architect. Others are motivated to get off their current hardware or out of their current data center as quickly as possible, leading them to the re-hosting decision.
The long-term impact of re-architecting versus re-hosting should also be considered. Re-architected, cloud-native applications can often support future growth more effectively than applications that aren’t modified. In addition, redesigning applications to be cloud native is a learning experience for the information technology (IT) team. This can positively change the IT team’s culture, as they adapt to working with dynamic, flexible, on-demand cloud features.
Some applications aren’t a good choice for re-architecting, such as those with a planned retirement date. If the application is monolithic, and separating data from logic will be complex, re-hosting will be significantly faster than redesigning. Applications that aren’t running well in their current environment should be evaluated for re-architecting, as they will continue not to run well if they’re simply lifted and shifted to the new platform. Applications that are highly resource-intensive should also be evaluated for re-architecting.
For other applications, recognize that the decision to re-architect doesn’t need to be made when the workloads are migrated. Applications can be re-architected after they’ve run in the cloud for a while, once the IT team has gained cloud experience and there’s a better understanding of which cloud features will benefit the application’s performance and potentially lower costs. Waiting to re-architect also separates the application redesign from the data migration, which reduces the project’s complexity.
Using containers can help companies with their application migrations to the cloud, even if an application isn’t completely refactored and re-architected.
While re-architecting applications to take advantage of the cloud is time-consuming, companies experience real benefits from completing these projects. Orban uses the example of Netflix, which spent an extended period of time on their cloud migration rather than rushing through it. Netflix benefited from the effort, which totally reshaped their internal technology and even their operations model. They now find themselves well positioned to support the company’s business growth and future expansion.
Tools to Support Re-architecting
Using good tools helps companies reduce the effort and time involved in re-architecting. Weaveworks’ tools help companies implement multicasting on top of their cloud, and support container troubleshooting and microservice troubleshooting when problems develop. It also provides support for continuous delivery.
Weave Net enables multicast applications to run in clouds that don’t directly support multicast. By using Weave Net, companies are able to reduce the re-architecting time needed to migrate these applications to the cloud.
Once applications are in the cloud, Weave Cloud provides real-time visibility into and monitoring of applications, reporting on both host and container metrics.This insight makes it easier to trace and resolve the source of trouble.
Weave Cloud also offers continuous delivery, allowing you to ship features faster to your newly re-architected microservices app. By choosing the right applications to re-architect — those where cloud-native capabilities will enable future growth and opportunities — and using tools that support the migration effort, you can succeed in your transition to the cloud.