Cloud Adoption Journey

Table of Contents:

Introduction…………..….…………… 1
Challenges……………….……………. 1
Cloud Considerations ….…….………. 1
Our Solution.……….….…………….. 2
Cloud Adoption Stages.………………. 2
Assessment ………….……………….. .2
Pilot Phase …………..……………….. 3
Data Migration ……...……………….. 3
Move applications ….………………… 4
Optimize/Cloudify …………………… 4
Conclusion ……….…..……………….. 5

Introduction

“Cloud” is the response to business challenges today, which requires rapid adoption of new technology, processes, new products, its features and new business models. Small, medium or large organizations of any sizes are adapting to cloud technology. So, we at Gamigo decided to adopt and harness the power of cloud and its benefits.

Just few words on Gamigo, we are predominantly a game publishing company focusing on B2B business strategy and slowly gearing up towards a technology company with many acquisitions and technology platform innovations to achieve different business goals.

With lot of acquisitions in last few years, there has been increase in number of data centers (roughly 16). Therefore, a DC consolidation and migration to cloud was inevitable, to streamline support and minimize cost. This article explains, exactly what we did to migrate our workload to Google Cloud Platform.

Challenges:

As we grew with lot of acquisitions, the IT complexity increased as well. Following are key problem statements that we faced as we grew.

• Multiple DC management.
• Multiple vendor management for various 3rd party technology stacks.
• Different tool sets to manage infrastructure or development environments.
• Difficulty in maintaining resilient infrastructure in terms of HA, Backup, DR etc.

With the above stated problem statements, our only way ahead to make life easier for all our team members was to go with DC consolidation and Cloud migration. Below are few general cloud considerations, I would like to mention.

Cloud Considerations:

The first question that one should ask themselves even before planning the cloud move, Do we really need to move to cloud? What are the things that our on-prime datacenter cannot do that cloud can? If we closely try to find the answer to this question, we will have enough reasons to move to cloud. As per my understanding and experience here are few key points why we should move to cloud.

• Infrastructure cost. There is no upfront investment. We pay only for what we use, reducing overall cost. Gone are the days of negotiating vendors for buying hardware, installing, configuring etc.
• Future proof infrastructure with latest and greatest technology stacks. All public cloud providers use customized hardware stack to support the growing demand and massive workload being generated. Every hardware device has its lifetime. Its very painful to refresh hardware in a on-prime datacenter as it brings disruption to your running operations. With cloud this problem is solved permanently as cloud provider takes care of this hardware refresh.
• Elastic resources, scale to meet demand, and pay only what you use.
• Big data solutions made easy, with various managed data warehouse, data processing and analytics solutions available with all public cloud providers. These solutions are easily integrated with other cloud managed services.
• Business agility and infrastructure automation. With the use of orchestration and DevOps tools, businesses are able to deploy updates, features much faster than earlier days, hence contributing to “time to market” success.
• Cloud managed services enables organizations to concentrate on core business while underlying infrastructure is being taken care by cloud provider.
• Ability to expand globally. With the presence of data centers (availability zones) across the globe, it gives organizations easy expansion of their business in any geolocation around the globe.

Our Solution:

• Consolidate 16 Datacenters into Google Cloud Platform and 2 European/North American Hubs on-prem DC for internal data.
• Harmonize technology stack with standard tools for CI/CD pipeline.
• Automation First approach.

In general following cloud adoption strategies we have followed. At the end of every step I have mentioned the exact tasks we (at Gamigo) did for the migration.

Cloud Adoption Stages

First thing first. Every greater objective needs proper planning. The more time we spend on planning stages better chances are for a smooth transition to cloud. Therefore it is very important to have a clear and detailed plan in hand before cloud migration. Next question would be, where to start? Below are the cloud adoption stages that should help in guiding you throughout the cloud migration process.

1. Assessment: Every organization has different types of workloads running with different applications to meet various business goals. All these workloads contribute to the success of the business, and every business unit head has the tendency to resist the move as this brings disruptions to their smooth operations. Therefore we have to carefully assess the workloads across all business units and identify candidates for the cloud migration. With the context of cloud migration and some of evaluation criteria, such as application criticality, compliance, licenses and ROI (Return On Investment), we could categories the workloads or applications into 3 categories.

• Easy to move: These are the potential candidates which are cloud native in nature and doesn’t affect company reputation or revenue even if we have downtime. An example would be any internal portal used by employee which could remain offline without a huge impact.
• Hard to move: These are the set of applications which are complicated and needs utmost care while migrating to cloud. A typical example would be ERP system for an organization. However depending on business nature it might vary for different organizations.
• Cannot move: These are the set of application which are legacy in nature and are running on very old hardware, probably more than 15 years old systems. The only possibility to move these type of workload is to modernize them with new technologies compatible with cloud services.

There is another very important step during the assessment phase, which is carefully mapping the on-prime technology against a cloud service. For example, if we have containers running on virtual machines, we can choose kubernetes engine in google cloud, or if we are running SQL based backend storage, we can use managed services like “Cloud sql” in GCP or RDS in AWS. These are just few examples. We can even refactor our existing workload to match a cloud service to have resilient, high performance and cost effective cloud solutions.

At Gamigo, we did our assessment for all our workload and found that, approximately 50% of workload were qualified for a “lift and shift” migration approach. Another 30% workload was qualified for a “improve and move” approach, which means while we move the workload we could use selected cloud managed services offering more off the shelf tools to be consumed. Rest 20% workload were not cloud ready/native. We had to refactor the code/application for cloud migration. In google cloud migration terminology it’s called “Rip and Replace”. In a nutshell we are talking about few thousands of virtual machines and some terabytes of data to be migrated.
The biggest “rip and replace” move we did is for our backend platform called “GAS” (Gamigo Accounting System). This is the core system of our user base. The entire system was running on physical servers in a 42HU rack. After moving to GCP now its running “as microservices” in a 16 core Kubernetes cluster. Thats we call power of cloud.

2. Pilot Phase: At the beginning, it is very important to run a pilot project or a POC (Proof Of Concept) run. Any application which false under “easy to move” category can be a good candidate for this pilot project. This phase helps organizations to get familiarize with the entire cloud migration process, potential bottlenecks that might come across, impact on business processes and daily operations, identifying various aspects of the migration and the key performance indicators (KPI) we could use during the actual migration to rate the entire migration process. During this phase we start mapping roles for all concerned teams with only needed permissions.

During Pilot Phase at Gamigo, we identified a “game” (Aura Kingdom) as best candidate for a POC model, followed by actual migration. The key point in this game was to retain certain game management architecture within GCP setup as well. Entire deployment of the required infrastructure was done via GCP “Deployment Manager” tool. This is a very powerful tool for IaS (Infrastructure As Service) service. With Deployment manager templates we could create the entire infrastructure setup needed for the game within few minutes, which otherwise would take days. We could clearly see the efficiency of cloud here, without using managed services so far.

3. Data Migration: After a successful pilot phase, we are in a much better position with good cloud knowledge and their capabilities. By this time the migration team also gains confidence. Next comes the migration of data. There are few important considerations in this phase.

• Move data before application. Data migration might take time depending upon its size and method we use for migration. It is always advised to move data first before application to minimize cutover downtime.
• Evaluate storage options: This is very important stage of the entire move, to choose the correct storage service in cloud environment. There are many factors which needs to be evaluated before choosing the right storage solution, however in a very high level concept we can say any unstructured data should go to “cloud storage” (in GCP) or “S3” (in AWS). There are different cloud services available for small/medium/large data sets for SQL or NoSQL database solutions. Also different services available for data warehouse solutions, analytics, data processing etc. Specially in GCP most of these solutions are managed services and can massively scale to hold petabytes of data.
• Transfer methods/tools: In this stage, depending on data size we can use various tools/methods to transfer data to cloud storage. This methods/tools ranges from simply copying data over internet or VPN connection, to using cloud providers appliance service. When we have some petabytes of data to be transferred, we could use this appliance service which cloud providers will ship to our on-prime data center and after copying the data they will pick it and connect to any of their facilities and restore the data.

When it comes to selecting storage options in GCP, there are a lot in the offering. For our workload and game architectures we mostly used “cloud storage” for data retention and backup options and static content for many websites. Managed RDBMS solutions like “Cloud SQL (mysql), and traditional database setup on compute engines instances.
Data migration was primarily carried out via DB replication (wherever possible). Other tool used for data migration was “gsutil”, which is a very effective data copy tool in GCP. We could copy Terabytes of data very efficiently without a long downtime.

4. Move applications: In this stage we migrate the applications. There are few considerations which should be in mind during application migrations.

• Self service or partner solutions: All public cloud providers work with certified partners who help organizations in the entire cloud adoption journey. Either we can perform migration ourself (if we have the technical skills needed) or we could use cloud providers certified partners, of course they come with a price. Based on application complexity, technical skills availability and cost, we have to decide the right way.
• Keep it simple: It is always recommended to use simple methods and without performing any major changes to the application, during migration. As-Is migration should be the preferred method. This will keep things simple and less complicated and easy debugging in the event of any problem.
• Hybrid strategy: Another migration option is a hybrid solution. In this method we use both cloud and on-prime datacenter together in a hybrid mode to achieve our desired goals. Start with migrating few applications to cloud and keep critical workload still run from on-prime DC. This helps gaining more confidence on cloud performance and capabilities, and slowly after gaining more confidence with cloud capabilities we could shift our critical workloads to cloud.

Application migration is in our case game migration or game installation/setup in the GCP environment. This was primarily done by game developers in parallel with operations team. Devs used their deployment tools to deploy the game in respective environments. Further configuration changes were done by Ops team to integrate the game with backend platforms for monetization and BI related pipelines.

5. Optimize/Cloudify: This phase if very important and my personal favourite. We can also refer to this phase as “cloud makeover”. This is a continuous improvement stage post successful migration to cloud. After a successful move, in this phase we try to adopt more cloud services/technologies like managed services and automation wherever possible, to truly take advantage of cloud services and offerings. For example, use of cloud load balancers, deploying managed instance groups with autoscaling, enable versioning and life cycle policies in storage buckets, improving CI/CD pipeline by leveraging cloud services etc. This stage not only restricts to technology improvements, but also improves daily operational procedures. With the new technology stack comes the new operational process and procedures, basic example being access management for developers and cloud engineers. Cross function collaboration is redefined as well, with the cloud adoption. All these changes and improvements of course need some time to propagate through the organization.

Optimization is an ongoing process and will never end. As long as we are using public Cloud, optimization is a key task. Following activities are taken care of as part of cloud optimization.

- Shutdown test/QA environments whenever not in use and during weekend.
- Apply Google recommendations to compute engines asap.
- Copy DB backups to storage buckets and remove the backup drive on DB servers.
- Periodic script to check unused public IP and release them.
- Check unused storage disk across all projects and delete them if needed.
- Optimize game for more efficiency.

Conclusion

In general we at Gamigo Group are really happy to move to GCP. It has enabled us to concentrate more on our business and less operational activities. Incidents were reduced by 40% and DC cost by 60%. Most of the operational tasks like game maintenances are now automated.

Our digital transformation in a nutshell

Our presentation at Google Cloud Summit — Munich 20/11/2018