Producing architectural guidelines to help teams make their migration plans
Written by: Kevin O’Shea and Gina Edwards
Quality testing is done, the platform is released for general availability to our application teams, and everything is looking great.
The CIO Hybrid Cloud team released a new hybrid cloud infrastructure that uses state of the art features; we’re running Red Hat OpenShift, we are leveraging public cloud services, and we have streamlined connections between environments and platforms allowing for teams to apply these hybrid cloud benefits to their applications — or so we thought.
Migration
Now that we have the platform available for use, it is time to start getting teams thinking about migrating from legacy environments to CIO Hybrid Cloud. There is documentation available about the platform, features, and how applications can be run in the new environment. Application teams show interest and teams begin looking at what they need to do to migrate to the new environment. Many begin to containerize their applications — some are taking advantage of Source-to-Image (S2I), some are using Dockerfile, and others are uploading their image via their own CI/CD pipeline directly to the platform. This is what we were hoping for — we are getting modernization along with migration and setting ourselves up for a great future — but, we start to notice something that needs to be addressed. Teams are modernizing their applications, they are moving to the new platform, but they are not taking full advantage of the platforms’ capabilities. Their applications have been modernized, running in stateless containers, but they are only running one copy of their application — in one zone, in one region.
We noticed that for some applications that don’t need a high level of up time or can tolerate an outage, teams were using the architecture they had in their legacy environment, which was one instance of their application in one location. When their application went down, the support team would fix it within their service level agreement (SLA) window. However, the new hybrid cloud platform was designed to run multiple copies of the application in multiple zones and multiple regions, which provides the following benefits:
- Multi-zone capability allows us to run multiple copies of the applications across different data centers that are spread across a single region. For example, in the US-South region, the platform is spread across three separate data centers. This protects against failure of a single data center.
- Multi-region capability allows us to run multiple copies of the applications across multiple regions. For example, running the applications in the US-south region and in the US-East region protects against the failure in an entire region due to a natural disaster.
Even though these application teams knew about these possibilities, they saw no need to leverage them — they had operated this way before and brought that thinking with them to the new environment. That’s when we decided it was time to provide some opinionated guidance on how applications should be run in the new platform.
Architectural guidelines
We began thinking of ways to influence the application teams so they could take advantage of the built-in load balancing and multi-zone design discussed earlier.
We started looking at application data and use cases and came up with guidelines that would apply to the majority of applications that were migrating and modernizing.
We started with the basic design of a three-tier architecture (presentation, logic, data) and built upon that. We laid out exactly how application teams could take advantage of the platform’s multi-zone capabilities. Our minimal recommendation was for the application teams to deploy an active-active front end of their application, and an active-passive back end (databases), all within a single region. You can see an example of this pattern in the diagram below.
Our approach was to simply enable a mind shift for the application developers who have been deploying applications in the legacy platforms, but now are migrating to a more modern platform with additional capabilities. The capability of deploying an application in multiple zones as discussed above is a classic example. A failure of one instance of the application will not cause a total failure of the application with extended downtime, instead another instance of the application will continue to provide the service. We provide an easy way for an application developer to choose the number of application instances to deploy. If the number selected is more than one, then the platform automatically deploys a separate instance of the containerized application in different zones within the region and automatically provides a load balancer in front of it. This platform capability provides business continuity for the application in a manner that was not possible in legacy platforms and we enabled the application developers to leverage it.
The next guideline we created to build on top of this scenario was a high availability/disaster recovery (HA/DR) implementation and how it could be achieved, so application teams weren’t creating it from scratch when they began the migration process. Our most complete guide, as we called it, contained multi-zone, multi-region, data backups, and off-site replication and environments that could be used for disaster recovery — shown in the diagram below.
The goal with this guideline was to prove what was achievable on the new platform and how even the applications with the strictest requirements could build and run on our new platform.
One important thing regarding these guidelines is that application teams did not have to follow our recommendations, they could do whatever they needed for their requirements. But, what the guidelines did offer was ease of transition, a method to help teams take a step back and re-evaluate how they were deploying their current application, and what could be done in the platform.
Having the documentation was great, but once we put it all together with visual representations, along with links to guides on how it was implemented, what to watch out for, and where to go, the migration process became a lot smoother for teams. The scenarios listed above may not have worked out for every team and every application, but they did help to alleviate some pressure on the platform team and the Center of Excellence (COE) for a majority of cases. Most importantly, the application teams are now learning how take advantage of the benefits when using a modern hybrid cloud infrastructure.
Kevin O’Shea is a Cloud Architect on the CIO Hybrid Cloud Center of Excellence (COE) team at IBM. Gina Edwards is a Delivery Manager on the COE team. The above article is personal and does not necessarily represent IBM’s positions, strategies or opinions.
