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

This is Part 1 in the Forbes' Road to the Cloud Series

Two years ago, we at Forbes embarked on a digital transformation. We established a KPI-driven product development approach, focused on creating a passionate team culture, and moved towards continuous deployment. Achieving these goals required taking a long overdue step - migrating from our data center to the cloud.

The cloud migration journey was full of twists we didn’t expect, both in terms of people and technology.  I will cover the challenges we faced, mistakes we made, lessons we learned and benefits we gained.

Why Move to The Cloud?

Three outcomes drove our need for cloud migration: velocity, abstraction and stability.  We live in a world where interfaces, formats and technologies change daily. Velocity is critical to remaining relevant.  Being in the cloud allows us move to continuous deployment and spin up unlimited environments on the fly. These new capabilities have empowered us to create prototypes faster, share them more easily with stakeholders and release features more quickly.  The ability to scale on the fly removed the need to overprovision our servers which saved us tremendous overhead.

The Challenges

While the decision to move to the cloud was ultimately ours, we still needed to architect the lift, retrain the team, select a cloud provider, and plan the timeline.

Architect The Lift

Forbes.com is a service based architecture. In total, it consists of 50 different services that all had to be moved to the cloud. Below is a diagram of Forbes.com architecture prior to the migration.

Retraining Engineers

With a very strong and established in-house Operations team, we were very adept at handling anything required in the datacenter.  By moving to the Cloud, we quickly realized that we need to invest in retraining our Ops team. We started by building a progressive DevOps culture.  Some of the main principles we’ve instilled were: collaboration between teams, focus on automation, prototyping, customer satisfaction and engineering excellence.  At the same time, we’ve invested in the team learning new technologies and specifically learning best practices. With a passionate team culture our existing Ops team was eager to learn and were more than up to the challenge.

Selecting Cloud Provider

For our cloud service, we chose Google Cloud Platform or GCP.  Due to its higher level of abstraction, our engineers found working with GCP more enjoyable.  As we’ve become accustomed during our digital transformation, we made sure to validate our decision.  We ran two week POCs with our internal team and multiple vendors on AWS and GCP to decide which cloud platform met our needs best.  We considered the following four criteria:  

• Cost
• Adoption 
• Ease of on-boarding
• Available feature set e.g., ML, Cloud Functions

After careful consideration, our team felt most comfortable and excited about GCP.

Chart Our Timeline

We had an aggressive migration timeline set and didn't want to waste any time in getting started.  As I've discussed in the above paragraph, we started with picking a cloud provider. We took a very similar approach to picking a cloud migration partner.  We did two weeks POCs and made a decision based on experience, skill and our comfort level. One of the most important milestones during the migration was auditing our infrastructure: creating missing architectural diagrams, deep diving into every application that we had running, documenting all our networking and security.  Without doing this grunt work, I’m confident we would not have been successful in meeting our deadline. We kicked off our migration in early December, by moving our applications to a development environment followed by a move to staging. On staging, we conducted aggressive load testing and QA. During this process we discovered a critical dependency that needed to address prior to moving to our production environment.  There was an unexpected latency between our datacenter and our cloud. Therefore, we architected a phased rollout by breaking down applications in a way where our core applications and databases moved in one shot. The architecture of our migration was critical to our success. The next part in this series will dive into this deeper.