The best way to minimize risk when moving complex and critical applications from the on-premises environment to the cloud is to follow a three-step process:
- In the first step, IT needs to move the applications to a cloud environment as is, without changing any code.
- In the second step, IT teams can make copies of the application in the cloud to improve software development and testing while refactoring the original to use native cloud services piece by piece. Incremental automation of environment builds can also be introduced without using cloud native services.
- Finally, in step three, much of the application will exist in a cloud native format with an on-premise return connection. This process enables a faster and more secure path to innovation in the cloud, while reducing reliance on current on-premises resources.
This process allows businesses to reap the cost and flexibility benefits of the cloud while minimizing the risk of breaking critical applications or causing delays.
Lift and move
First, IT needs to recreate on-premises applications in the cloud without modifying any code. It should be a full clone of the original system with no reengineering of components to cloud native equivalents. Make sure to create same LPAR / VM count, same disk / CPU / memory allocations, same file system formats, same IP addresses, same hostnames, same network subnets , etc.
Remember that applications running on IBM i or AIX cannot be transferred and transferred directly to AWS, Azure, or GCP without specialized solutions. The benefits of adding the flexibility of the cloud to traditional applications usually outweigh the investment in such a solution.
Once an application is in the cloud, ephemeral longevity, fast cloning, software-defined networking, and API automation can be applied to it. Additionally, once a logical partition / VM group representing an “environment” is created in the cloud, that environment can be saved as a template and then used to clone other work environments. Clones are exact replicas of the template, down to disk allocations, hostname, IP address, and subnet. Multiple environment clones can work together without running the risk of colliding, although the effort involved in setup varies from cloud provider to cloud provider.
The most important part of this approach is designing out-of-the-box environments from a template. It allows IT to create multiple clones for various development / engineering / test groups, which can all run simultaneously. Most cloud providers offer built-in access controls so that users can only access what has been assigned to them (that is, an ENG user cannot see an only assigned environment. quality assurance). Users can also have role assignments allowing them to manage LPARs / VMs defined in an environment assigned to a specific project.
Use an EVR to duplicate address spaces
In order to create multiple working environments replicating the same network structure as the final target system, some form of separation must be used in order to mitigate potential obstacles in your cloned environments. For our purposes, “replicate” means reuse host names, IP addresses, and subnets living in each environment. At this point, each unique environment should be in its own software-defined network space, invisible to other environments running at the same time, making each environment a virtual private data center. By allowing duplicate host names and IP addresses, individual hosts do not have to go through a frustrating and time-consuming “re-IP” process.
There are a number of ways that users can achieve this. Here is an example using an “environmental virtual router” (EVR). Duplicate environments communicate with on-premises resources through EVR, which hides lower virtual machines containing the same host names and IP addresses and exposes a single IP address to the larger on-premises network. EVR working in conjunction with a “jump-host” can be configured to forward SSH requests (via ssh proxy, OpenSSH 7.x and later), which allows SSH to access all hosts in an environment. On-premises, users connect via SSH to any host in the environment (for example, ssh user @ environment-1-host-2), which exposes a unique on-premises IP address, then delivers it to the machine virtual environment. This results in a simplified and sophisticated way for multiple cloned environments to exist in tandem without disrupting the basic structures of the network.
Refactor or restructure piece by piece
As various teams work with their cloned apps, IT can start gradually refactoring the original to use cloud native services. There are several design models established for this (“Side Car” or “Strangler”, for example). This incremental strategy allows for a gradual approach to transformation rather than starting from scratch. Refactoring R&D is done in a rational manner so that the entire application can continue to function, preventing the creation of new application-wide development attempts. Starting from the top through several applications going through the migration process is risky and goes against the Agile principle to “limit the work in progress”.
This piece-by-piece strategy also speeds up the overall refactoring project and reduces risk. By recreating the original on-premises application, final working versions of the original application can be shared with Agile teams performing short sprints. Dividing the entire application into smaller pieces also reduces the risk of the entire project failing and meets the Agile values of “working software” and “reaction to change”.
Developers can gradually build automation into the application even if they are not using cloud native technologies. Alternatively, applications can easily be rehosted (see Microsoft’s article “The 5Rs of Streamlining” for more details) without significantly altering their original on-premises structures.
Move another application via the “cloud factory” line
Once most applications exist in cloud native formats while maintaining a dedicated connection to on-premises computing, the process is complete. Think of it as a factory where various applications go through the assembly line at different speeds. When an application leaves the factory, the other applications in the target list are just getting started. The more you work with cloud native offerings and products, the faster the ‘factory floor’ can accelerate, as solutions to problems found earlier in the transformation process can be quickly implemented without the need for R&D. excessive, rework and try and Error.
Succeed through agility and security
This plan enables businesses to reap the benefits of the cloud and aligns with many Agile software development best practices. The approach speeds up development / testing, engineering and quality assurance by allowing disparate teams to work simultaneously, while reducing risk by not re-archiving or restructuring the platform during migration by dividing work in small, manageable chunks. Not only is this the safest approach to migration for critical on-premises applications, it’s also the most likely to be successful.
Matthew Romero, Technical Product Evangelist, Skytap