Since I’m familiar with Openstack already, it’s easier for me to learn GCP from comparing corresponding componentes of these 2. Luckily, Google seems thinking the same way as I do, so here’s a quick link: Openstack VS K8s. Some of their views to me are not accurate, because Openstack itselft keeps evolving as well. I’m gonna put my personal understanding in this article.

OpenStack’s baseline services include:

  • Compute: OpenStack Compute (Nova and Glance)
  • Storage: OpenStack Block Storage (Cinder)
  • Networking: OpenStack Networking (Neutron)
  • Identity and access management: OpenStack Identity Service (Keystone)
  • Cloud Platform’s baseline services include:

Compute: Google Compute Engine and Google App Engine

  • Storage: Persistent disks, Google Cloud Storage
  • Networking: Google Cloud Virtual Network, Google Cloud DNS, and Google Cloud Interconnect
  • Databases: Google Cloud SQL, Google Cloud Datastore, and Google Cloud Bigtable
  • Identity and access management: Google Cloud IAM

General 3-tier App architect

According to what Google says, Openstack provides active-standby architect for regular 3-tier apps, which is true in their example case, but in real world I’d do it differently, e.g I may use NFS/CephFS/CephRBD to mount volume onto instances in different regions, so they always keep data synced. And a better solution now is to take advantage from K8s.

Openstack standard Approach

Openstack 3-tier

  • You deploy resources across two regions as two separate failure domains for redundancy.
  • The network uses a single subnet for all tiers in each region, and all servers are virtual machine (VM) instances.
  • You define security groups for the four server roles and assign them to the appropriate instances.
  • A Cinder volume is attached to the database server as a data volume. To ensure redundancy across failure domains, the database in the active region is backed up to object storage and restored to the one in the backup region when necessary. (This architecture does not use real-time database replication, because bandwidth is limited between regions.)
  • This architecture provides an active-backup configuration. When you failover the service to another region, you restore the most recent backup to the database server in the backup region.

Google’s Standard Approach

  • You deploy resources in a single subnet that covers multiple zones in a single region for redundancy.
  • You deploy web servers and application servers as VM instances.
  • You define firewall rules using tags to specify packet destinations.
  • You configure access control for the database connection based on the source IP address as part of the Cloud SQL configuration. Cloud SQL is a GCP managed service for MySQL databases that provides data replication between multiple zones. Scheduled data backup and failover process are automated, and you can access the database from multiple zones in the same region. Failover between zones is transparent to applications running on VM instances. You can access a single Cloud SQL instance from multiple zones. (Cloud SQL has two generations: Cloud SQL First Generation and Cloud SQL Second Generation. They have different characteristics and default behaviors for replication and failover.)
  • Google Cloud Load Balancing is an HTTP(S) load-balancing service with which you can use a single, global IP address (VIP) to distribute client access to multiple regions and zones.
  • The architecture provides an active-active configuration across multiple zones, resulting in a redundant service across failure domains.


In GCP, User can’t generate private routers as in Openstack(unless using Hybrid Connectivity for BGP routing), but can turn on internal routing feature to make GCP automate this action, everything about basic network setup is done automaticlly.

GCP has legacy and subnet mode: Legacy Mode is like all instances across different hosts in different region are connected under 1 neutron router. GCP Legacy

Subnet Mode is like instances are connected behind different neutron routers, turn on Private Google access will enable this feature, all instances can be routable internally without using external IP. GCP Subnet


Like Openstack, GCP has a similar design as security group in Openstack and AWS. The difference is it adds a field called target, it’s a tag you put on instance, in this way it achieves src/dst ACL, whereas in Openstack/AWS, only src ACL when using security group.

Openstack mimics AWS, it uses security group as distributed firewall blocking traffic at instance level. In newer version of Openstack, there’s FaaS(Firewall as a Service) providing src/dst ACL.

Openstack/AWS FW solution is more traditional as what we do on legacy FW, GCP’s solution is more cloud native, as everything is deployed with a purpose, and this purpose is the tag you put on the instances. Instead of using security group, tagging seems more clear and provides more flexibility.

Remarkable Difference in Terms