Google Cloud – TerramEarth Case Study

TerramEarth manufactures heavy equipment for the mining and agricultural industries. About 80% of their business is from mining and 20% from agriculture. They currently have over 500 dealers and service centers in 100 countries. Their mission is to build products that make their customers more productive.

Key points here are 500 dealers and service centers are spread across the world and they want to make their customer more productive.

Solution Concept

There are 20 million TerramEarth vehicles in operation that collect 120 fields of data per second. Data is stored locally on the vehicle and can be accessed for analysis when a vehicle is serviced. The data is downloaded via a maintenance port. This same port can be used to adjust operational parameters, allowing the vehicles to be upgraded in the field with new computing modules.

Approximately 200,000 vehicles are connected to a cellular network, allowing TerramEarth to collect data directly. At a rate of 120 fields of data per second, with 22 hours of operation per day, TerramEarth collects a total of about 9 TB/day from these connected vehicles.

Key points here are TerramEarth has 20 million vehicles. Data is stored on the vehicle and is only available for analysis when the vehicle comes for servicing. Only 1% of the vehicles currently have the capability to stream real time data which produce 9 TB/day.

Executive Statement

Our competitive advantage has always been in our manufacturing process, with our ability to build better vehicles for lower cost than our competitors. However, new products with different approaches are constantly being developed, and I’m concerned that we lack the skills to undergo the next wave of transformations in our industry. My goals are to build our skills while addressing immediate market needs through incremental innovations.

Key point here is the company wants to improve their vehicles while building new skills and reducing cost.

Existing Technical Environment

TerramEarth’s existing architecture is composed of Linux and Windows-based systems that reside in a single U.S, west coast based data center. These systems gzip CSV files from the field and upload via FTP, and place the data in their data warehouse. Because this process takes time, aggregated reports are based on data that is 3 weeks old.

With this data, TerramEarth has been able to preemptively stock replacement parts and reduce unplanned downtime of their vehicles by 60%. However, because the data is stale, some customers are without their vehicles for up to 4 weeks while they wait for replacement parts.

Key point here is that the company is working with stale data and hence have increased downtime.

Application 1: Data ingest

A custom Python application reads uploaded datafiles from a single server, writes to the data warehouse


  • Windows Server 2008 R2
    • 16 CPUs
    • 128 GB of RAM
    • 10 TB local HDD storage

Application 2: Reporting

An off the shelf application that business analysts use to run a daily report to see what equipment needs repair. Only 2 analysts of a team of 10 (5 west coast, 5 east coast) can connect to the reporting application at a time.


  • Off the shelf application. License tied to number of physical CPUs
    • Windows Server 2008 R2
    • 16 CPUs
    • 32 GB of RAM
    • 500 GB HDD

Data warehouse

  • A single PostgreSQL server
    • RedHat Linux
    • 64 CPUs
    • 128 GB of RAM
    • 4x 6TB HDD in RAID 0

Key points here are TerramEarth has its infrastructure in a single location – US West Coast. The data from vehicles is uploaded as CSV files through FTP on the data warehouse. As the data is delayed TerramEarth is only able to reduce unplanned downtime of their vehicles by 60%. Some customer vehicles do not have replacement parts for over 4 weeks.

Business Requirements

  • Decrease unplanned vehicle downtime to less than 1 week
    • Current bottleneck is mainly collection of data available for analytics. If the data collection can be improved i.e. more vehicles can be moved to Cellular connectivity the data is available more real time and hence the feedback loop can be completed earlier.
    • Can be handled using Cloud Pub/Sub, Cloud IoT, Cloud Dataflow to capture the Cellular data and have analytics done using BigQuery and Cloud Machine Learning.
  • Support the dealer network with more data on how their customers use their equipment to better position new products and services.
    • can be handled using running analytics over collected data regarding the usage and consumption
  • Have the ability to partner with different companies—especially with seed and fertilizer suppliers in the fast-growing agricultural business—to create compelling joint offerings for their customers.
    • can be handled using building APIs to expose the data externally and using Cloud Endpoints to expose the APIs.

Technical Requirements

  • Expand beyond a single datacenter to decrease latency to the American midwest and east coast
    • Can be handled using multi-regional Cloud Storage and other AWS managed services like Pub/Sub, Dataflow and BigQuery
  • Create a backup strategy
    • data can be easily backed up in Cloud Storage or BigQuery
  • Increase security of data transfer from equipment to the datacenter
    • data can be transferred using HTTPs for more security
  • Improve data in the data warehouse
    • can be handled using BigQuery as the data warehouse solution instead of a single PostgreSQL which is limited in capability and scalability
  • Use customer and equipment data to anticipate customer needs
    • can be handled using running machine learning models over the data collected

Reference Cellular Upload Architecture

Batch Upload Replacement Architecture


Google Cloud – Mountkirk Games Case Study – v1

Mountkirk Games makes online, session-based, multiplayer games for mobile platforms. They build all of their games using some server-side integration. Historically, they have used cloud providers to lease physical servers.

Due to the unexpected popularity of some of their games, they have had problems scaling their global audience, application servers, MySQL databases, and analytics tools.

Their current model is to write game statistics to files and send them through an ETL tool that loads them into a centralized MySQL database for reporting.

Solution Concept

Mountkirk Games is building a new game, which they expect to be very popular. They plan to deploy the game’s backend on Google Compute Engine so they can capture streaming metrics, run intensive analytics, and take advantage of its autoscaling server environment and integrate with a managed NoSQL database.

So the key here is the company wants to deploy the new game to Google Compute Engine (not GAE or GKE) configured to scale (managed instance groups) to handle streaming metrics and analytics. It also needs to integrated with a NoSQL database (either Cloud Datastore or BigTable)

Executive Statement

Our last successful game did not scale well with our previous cloud provider, resulting in lower user adoption and affecting the game’s reputation. Our investors want more key performance indicators (KPIs) to evaluate the speed and stability of the game, as well as other metrics that provide deeper insight into usage patterns so we can adapt the game to target users. Additionally, our current technology stack cannot provide the scale we need, so we want to replace MySQL and move to an environment that provides autoscaling, low latency load balancing, and frees us up from managing physical servers.

So the key points here are the company wants to move to cloud and use more of scalable managed services without them needing to manage physical servers. Also they want to move from relational MySQL database to a managed database.

Business Requirements

  • Increase to a global footprint
    • Can be handled using Global HTTP load balancer with managed instance groups in each region.
    • Using multi-regional services like Cloud Storage, Cloud Datastore, Pub/Sub, BigQuery
  • Improve uptime – downtime is loss of players
    • can be handled using managed instance groups across zones and regions coupled with load balancer for High Availability
    • GCP managed services like Pub/Sub, Datastore provide a high uptime
  • Increase efficiency of the cloud resources we use
    • can be increased with scaling the resources as per the demand
    • can be increased further using Stackdriver metrics and monitoring
  • Reduce latency to all customers
    • can be reduced using Global HTTP load balancer, which would route the user to the closest region
    • using multi-regional resources would also help reduce latency

Technical Requirements

Requirements for Game Backend Platform

  1. Dynamically scale up or down based on game activity.
    • can be handled using autoscaling with managed instance groups with the ability to scale as per the demand
  2. Connect to a transactional database service to manage user profiles and game state.
    • can be handled using Cloud Datastore, which provides transactional NoSQL database service and is ideal for user profiles and game state
    • it does not need a relational database, so Datastore should work fine
  3. Store game activity in a timeseries database service for future analysis.
    • can be stored using BigQuery as it would provide a low cost data storage (as compared to Bigtable) for analytics 
    • other advantage of BigQuery over Bigtable in this case its multi-regional, meeting the global footprint and latency requirements
  4. As the system scales, ensure that data is not lost due to processing backlogs.
    • seems relevant for capturing streaming data and can be handled using Pub/Sub and Cloud Dataflow
  5. Run hardened Linux distro.
    • can be handled using Google Compute Engine, as it is the only compute option that would support custom Linux distro

Requirements for Game Analytics Platform

  1. Dynamically scale up or down based on game activity.
    • can be handled using GCP managed services which scale as per the demand
    • can be handled using Global HTTP load balancer and autoscaling managed instance groups
  2. Process incoming data on the fly directly from the game servers.
    • can be handled using Pub/Sub for capturing data and Cloud DataFlow for processing the data on the fly i.e real time
  3. Process data that arrives late because of slow mobile networks.
    • can be handled using Cloud Pub/Sub and Cloud DataFlow
  4. Allow queries to access at least 10 TB of historical data.
    • can be handled using BigQuery for storage and analytics
  5. Process files that are regularly uploaded by users’ mobile devices.
    • more relevant for kind of batch processing, which can be handled using storing the files in Cloud Storage and processing the same using Cloud DataFlow

Reference Architecture

Refer to Mobile Gaming Analysis Telemetry solution


Google Cloud – Dress4win Case Study

Dress4Win is a web-based company that helps their users organize and manage their personal wardrobe using a web app and mobile application. The company also cultivates an active social network that connects their users with designers and retailers. They monetize their services through advertising, e-commerce, referrals, and a freemium app model. The application has grown from a few servers in the founder’s garage to several hundred servers and appliances in a colocated data center. However, the capacity of their infrastructure is now insufficient for the application’s rapid growth. Because of this growth and the company’s desire to innovate faster, Dress4Win is committing to a full migration to a public cloud.

The key here is the company wants to migrate completely to public cloud for the current infrastructures inability to scale

Solution Concept

For the first phase of their migration to the cloud, Dress4Win is moving their development and test environments. They are also building a disaster recovery site, because their current infrastructure is at a single location. They are not sure which components of their architecture they can migrate as is and which components they need to change before migrating them.

Key here is Dress4Win wants to move the development and test environments first. And also, they want to build a DR site for their current production site which would continue to be hosted on-premises

Executive Statement

Our investors are concerned about our ability to scale and contain costs with our current infrastructure. They are also concerned that a competitor could use a public cloud platform to offset their up-front investment and free them to focus on developing better features. Our traffic patterns are highest in the mornings and weekend evenings; during other times, 80% of our capacity is sitting idle.

Our capital expenditure is now exceeding our quarterly projections. Migrating to the cloud will likely cause an initial increase in spending, but we expect to fully transition before our next hardware refresh cycle. Our total cost of ownership (TCO) analysis over the next 5 years for a public cloud strategy achieves a cost reduction between 30% and 50% over our current model.

The key here is that the company wants to improve on the application scalability, efficiency (hardware sitting idle most of the time), capex cost reduction, and improve TCO over a period of time

Existing Technical Environment

The Dress4Win application is served out of a single data center location. All servers run Ubuntu LTS v16.04.


  • MySQL. 1 server for user data, inventory, static data,
    • MySQL 5.8
    • 8 core CPUs
    • 128 GB of RAM
    • 2x 5 TB HDD (RAID 1)
  • Redis 3 server cluster for metadata, social graph, caching. Each server is:
    • Redis 3.2
    • 4 core CPUs
    • 32GB of RAM
  • MySQL server can be migrated directly to Cloud SQL, which is GCP managed relational database and supports MySQL.
  • For Redis cluster, MemoryStore can be used which is a fully-managed in-memory data store service for Redis.
  • There would be no changes required to support the same.


  • 40 Web Application servers providing micro-services based APIs and static content.
    • Tomcat – Java
    • Nginx
    • 4 core CPUs
    • 32 GB of RAM
  • 20 Apache Hadoop/Spark servers:
    • Data analysis
    • Real-time trending calculations
    • 8 core CPUs
    • 128 GB of RAM
    • 4x 5 TB HDD (RAID 1)
  • 3 RabbitMQ servers for messaging, social notifications, and events:
    • 8 core CPUs
    • 32GB of RAM
  • Miscellaneous servers:
    • Jenkins, monitoring, bastion hosts, security scanners
    • 8 core CPUs
    • 32GB of RAM
  • Web Application servers with Java and Nginx can be supported using Compute engine, App Engine or even with Container Engine with auto scaling configured.
  • Although the core and RAM combination would need a custom machine type, the same be configured or tuned to use an existing machine type
  • Apache Hadoop/Spark servers can be easily migrated to Cloud Dataproc
  • RabbitMQ messaging service is currently not directly supported by Google Cloud and can be supported either with
    • Cloud Pub/Sub messaging – however this would need changes to the code and would not be a seamless migration
    • Use Compute engine to host the RabbitMQ servers
  • Jenkins, Bastion hosts, Security scanners can be hosted using Google Compute Engine (GCE)
  • Monitoring can be provided using Stackdriver

Storage appliances:

  • iSCSI for VM hosts
  • Fiber channel SAN – MySQL databases
    • 1 PB total storage; 400 TB available
  • NAS – image storage, logs, backups
    • 100 TB total storage; 35 TB available
  • iSCSI for VM hosts can be supported using Cloud persistent disks as it needs a block level storage
  • SAN for MySQL databases can be supported using Cloud persistent disks as it needs a block level storage. However, a single disk cannot scale to 1PB and multiple disks need to be combined to create the storage
  • NAS for image storage, logs and backups can be supported using Cloud Storage which provides unlimited storage capacity

Business Requirements

  • Build a reliable and reproducible environment with scaled parity of production.
    • can be handled by provisioning services or using GCP managed services with the same scale as on-premises resources and with Cloud Deployment Manager for creating repeatable deployments
  • Improve security by defining and adhering to a set of security and Identity and Access Management (IAM) best practices for cloud.
    • can be handled using IAM by implemented best practices like least privileges, separating dev/test/production projects to control access
  • Improve business agility and speed of innovation through rapid provisioning of new resources.
    • can be handled using Cloud Deployment Manager for repeatable and automated provisioning of resources
    • deployments of applications and new releases can be handled efficiently using rolling updates, A/B testing
  • Analyze and optimize architecture for performance in the cloud.
    • can be handled using auto scaling compute engines based on the demand
    • can be handled using Stackdriver for monitoring and fine tuning the specs

Technical Requirements

  • Easily create non-production environments in the cloud.
    • most of the services can be created using GCP managed services and the environment creation can be standardized and automated using templates and configurations
  • Implement an automation framework for provisioning resources in cloud.
    • can be handled using Cloud Deployment Manager, which provides Infrastructure as a Code service for provisioning resources in cloud.
  • Implement a continuous deployment process for deploying applications to the on-premises datacenter or cloud.
    • continuous deployments can be handled using tools like Jenkins available on both the environments
  • Support failover of the production environment to cloud during an emergency.
    • can be handled by replicating all the data to the cloud environment and ability to provision the servers quickly.
    • can be handled by using DNS to repoint from on-premises environment to cloud environment
  • Encrypt data on the wire and at rest.
    • All the GCP services, by default, provide encryption on wire and at rest. Encryption can be performed using Google provided or Custom keys
  • Support multiple private connections between the production data center and cloud environment.
    • can be handled using VPN (multiple VPNs for better performance) or dedicated Interconnect connection between the production data center and the cloud environment