Forbes’ Road To The Cloud

This is Part 2 in the Forbes’ Road to the Cloud series.

After dealing with internal and external challenges, including choosing the cloud provider and getting the right team in place, the next critical phase of our journey was to focus on Architecture in the cloud. We had to plan thoroughly to ensure success. In this chapter we will dive deeper into our thought process and decision making for how to structure our migration.

Architecture

The first architectural decision made was structuring GCP projects so they are both secure and easy to manage. We considered three different structural approaches, the first being the creation of separate projects for each of the 50 applications. While all the applications are isolated from each other, there remain issues with security concerns and the overhead of managing 50 separate projects. The second approach considered was the creation of a single project for everything, which offers ease of maintenance. However, anyone who has access to the overarching project also has access to all the applications both in staging and production, which was a substantial risk from a security standpoint.  The approach finally chosen was option 3 a hybrid of the first two architectures: we separated our architecture into three projects, Development/Staging, Production, and Management (which included Jenkins, monitoring, and project management tools). This approach gave us the benefits of easy management and clear separation between production and staging.

The next major structural decision was how to separate the multiple applications into clusters, where we went through 4 or 5 iterations before settling on the one shown below. The rule used for separation was to keep applications that communicate the most with each other as close together as possible, while also having enough separation that an issue in one cluster would not affect the others.

Security

Early in the project, we recognized a critical need to focus on security in the cloud. We were extremely comfortable with security in the data center and had spent years building our skills but found it necessary to learn new approaches in order to address cloud-related challenges. Our primary focus was on locking user permissions and access to our applications. Significant time was spent verifying that access was opened only to applications that needed to talk to one another. Clusters were also made private and access only opened when required. As a group, we adapted to a new way of viewing networking by using Istio and were fortunate to have a networking and security team that learned rapidly and adjusted along the way.

The Refactor

Our original plan was to evaluate whether a managed solution exists and, if there were not one, then we would lift and shift everything as is. It seemed highly logical for us to pursue this course of action. However, we concluded that if we were going to containerize, then why not orchestrate. And, if we were going to orchestrate, then why not set up a network mesh. If we were going to set up a network mesh, then why not automate. And if we automate, then why not abstract.

Our lead architect created a highly configurable Jenkins master build file that turns a helm chart, docker image, and your configurations into a single uniquely identifiable, upgradeable, Kubernetes deployment with the automated DNS management. This level of automation was critical to the overall success of our project.

In our GCP Architecture, we fully switched to using one CDN and removed our dependence on an F5 load balancer. Our CMS is a SPA and lives in a Cloud Storage bucket. All our core applications, from templating to APIs, are autoscaling with Kubernetes. We’ve moved the on-premises MongoDB databases to MongoDB Atlas, which is a managed solution provided by MongoDB.

In the next part of this series I will focus on benefits and lessons learned.

Forbes’ Road To The Cloud – Why, Challenges and Timeline

Send me a secure tip.