Wherever there is Innovation, IT and Cloud, you will find Devoteam at the forefront! And this year, Devoteam is pumped to be heading back to Google Next ’19 in San Francisco from 9th-11th April. Today, David Frappart and Ludovic Nonclerq, Devoteam Technology Consulting, will talk to us about Google Cloud’s Vision of Networking.
Yes, we know, it’s less sexy or exciting than all the AI or Kubernetes stuff that we usually bring to the forefront in the Google Cloud Offer, but still, it is necessary to successfully adopt and/or migrate to the Cloud. So what is this about?
Google implements its Cloud network based on a feature called the Virtual Private Cloud (or VPC). Don’t let this seeming lack of originality put you off, and let’s dive a little deeper into Google’s implementation of the service.
Let us explain. In any Public Cloud offer, it usually starts off with defining a landing zone or the foundation of a Cloud architecture. Call it whatever you want, you need to define it!
In Google Cloud then, it is so defined with the VPC as a first building block. The VPC allows for one company to define a logical Network environment with all its associated sub-objects which are the subnets, the routing rules and the Network filtering features.
Where Google differs is in the VPC’s region distribution. To understand the VPC architecture, we should consider Google’s global network. It is said that Google owns one of, if not the first, globally distributed private network.
Thanks to this, Google is able to offer a globally distributed VPC, which is unique among all the Public Cloud offers, as illustrated in the picture below:
In this perspective, while other Cloud offers rely on region-wide design, leveraging hub and spoke design with managed or unmanaged network hubs, we get a simplified landing zone designed with only one VPC required for a start.
To let more than one entity access the VPC, Google also allows for deploying a shared VPC. This entity is a global logical network, which is shared among multiple projects (the billing boundary of Google Cloud) and thus allows for the interconnection of the On Premise world with a VPC-based landing zone design.
It is enough? That’s a legitimate question and it would seem so. VPC’s limits on a compute aspect is about 15,000 Compute Engine instances, so plenty of capability here!
Also, in the VPC, subnets are associated with a zone and it is possible to deploy a subnet in each of Google Cloud’s zones. Nevertheless, it is still important to plan IP addressing, since it will consume RFC 1918 address ranges, and those cannot overlap between different subnets in GCP or, with the on premise world – once it is connected to a shared VPC.
With automated configuration, a VPC will take the range 10.128.0.0/9, which is large enough to fill all the zone with a private IP but may not be available in the IPAM of the On premise network. If so, the alternative is the custom VPC, which gives the flexibility of choosing the range to attribute each subnet.
So if we can do it so simply, why would we do it differently? The question will find its answer not in the technical arena but, as is often the case, in the governance and compliance one. Indeed, it may be difficult for organisations to accept that the network could be visible by all stakeholders.
This is particularly the case if the network on-boards a connection with the on premise world: not one network team will feel comfortable with sharing its network space with business-oriented IT teams. Fortunately, securing the environment is possible through Google IAM features and if that isn’t enough, through the use of more VPC, which would be interconnected with the on premise world and controlled by IT teams, as well as connected to other VPCs – ones dedicated to non-production environments – and interconnected through the VPC peering service:
Thanks to this, we can still keep the globally distributed VPC, and even without giving full access to the shared VPC, we can still access it and communicate with shared services if required. On the other hand, we may lose the simplicity of the initial design which was only one network space for all.
In conclusion, we can say that Google Cloud is able to offer a robust and globally distributed VPC that could suffice as an initial landing zone for projects. Offering this simple design is a possibility but not a limitation, since we can still add more isolated/dedicated VPC to this base design. In any way, the target architecture should be defined with Security, compliance, and operations in the picture to find the best achievable balance.
Follow the rest of our series in the build up to Google Next! If you want to learn more about Virtual Private Cloud, come find David Frappart & Ludovic Nonclercq at Google Next!
