Hybrid Cloud — Linking GCP with on-premise datacenters
This week has been hectic; yet rewarding for our team as we succeeded in implementing Google hybrid cloud for a customer by linking public cloud workloads to on-premise workloads. In the interest of keeping it short, I’ll split this blog into two parts (first part for the solution overview and second part for implementation details). In this blog, I’ll be penning down my thoughts on the major obstructions to cloud adoption and how hybrid cloud solves it.
What’s blocking public cloud adoption?
Every technology comes with its own pros and cons. We are all aware of the benefits of using public cloud. Then why are enterprise apps still stuck on on-premise datacenters? Let’s take a look at primary factors on both sides.
Preferences for Public Cloud
- Latest hardware and software
- Reduced IT costs with quick and easily deploy-able resources
- Data Analytics
- Auto-scaling
- High availability (across multiple regions/zones)
Preferences for On-Premise
- Legacy locations
- Legacy Hardware
- Poor network connectivity
- Data Restrictions (data protection laws)
The industry demands the benefits of both public and on-prem datacenters. This necessity led to the development of Hybrid cloud!
Let’s take a look at how we implemented hybrid cloud for the customer
Day 1 : On-prem setup
Our customer has a microservices application hosted on their on-prem datacenter and wanted to leverage the capabilities of Google Cloud. Their application has a web-based frontend and a MySQL backend with following requirements
Front End Services
1. Autoscaling (seamlessly scalable depending on the workload)
2. Highly available (multi-region deployment for US, Europe, APAC customers)
3. No-Ops (quick and easy management)
Back End Services
1. Adheres to data protection laws
2. On-prem connectivity to the database
The backend requirements are well suited for on-prem setup whereas the front-end needs a public cloud to overcome the resource limitations.
Hybrid Cloud Architecture
We had to find a solution to split the microservices app in such a way that frontend components are migrated to GCP while retaining the backend services on-prem connected to MySQL in the private datacenter. We achieved it with Istio (Gateway-Connected Clusters feature) combining two separate Istio service meshes into one logical, hybrid mesh. If you are not aware of Istio and GKE, I’ll touch on those fundamentals in a separate blog in Geeky Corner.
Please note that this hybrid cloud solution is built for containerized microservices running on Kubernetes only.
Implementation
Step 1 : Created a GKE cluster in GCP for the front-end services
Step 2 : Created another Kubernetes cluster on-prem for back-end services
Step 3 : Setup separate Istio control planes for both clusters (on-prem and cloud).
Step 4 : Configured KubeDNS to talk to Istio’s CoreDNS. This is the key to link both clusters. It allows services in one cluster to refer to services in the other cluster as if they were part of their own mesh.
Step 5 : Deployed the microservices application and configured the Istio Ingress gateway for both clusters to communicate with each other.
Our solution is similar to the one shown below (except that following figure shows both clusters on GCP; whereas our solution is for hybrid cloud).
In my next blog, we will deep dive into each of these steps (with supporting scripts) to implement hybrid cloud for a microservices demo app. Also, take a look at Google’s hybrid and multi-cloud product Anthos which lets you build and manage modern hybrid applications across environments.
That’s all for now. We will deep dive into implementation in the next blog. I’ll also be uploading my project on GitHub for you to implement your own hybrid cloud. Watch this space!
Priya Saxena
Strategic Cloud Engineer, Google
Originally published at www.priyasaxena.co.uk on April 5, 2019.
