You can’t build a great building on a weak foundation.
Gordon B. Hinckley
At the time of writing, Google Cloud Platform (GCP) holds the third place in the public cloud market, trailing behind Amazon Web Services (AWS) and Microsoft Azure. With AWS commanding a significant mindshare and Azure capitalizing on Microsoft’s expansive corporate presence, one might question the rationale behind opting for Google Cloud. Why not consider other players such as IBM Cloud, Oracle, or Alibaba?
One reason I choose Google Cloud for cloud native development is the integration of services. AWS famously has two-pizza teams that work on each service independently. This produces a wide range of services quickly, often with overlapping capabilities. On the other hand, Google seems to put more emphasis on integration, having fewer services that work well end to end, making it easier to build the laboratory, factory, citadel, and observatory.
Although Google Cloud represents approximately 10% of the cloud market share, it powers 70% of tech unicorns at the time of writing. This disproportionate representation suggests that Google Cloud resonates with digital natives for valid reasons. AWS and Azure may host a multitude of traditional applications, but digital natives, unhindered by legacy infrastructure, favor a cloud native development style, and Google Cloud aligns better with this approach. In essence, Google Cloud is built by cloud native engineers for cloud native engineers, and this resonates with developers.
However, it’s important to note that many services discussed in this book also have equivalents in other public clouds. The techniques and considerations, therefore, can be adapted to other platforms. It’s a Herculean task to understand every feature and service of a single cloud, such as Google Cloud, let alone grasp multiple services across diverse cloud platforms.
In my experience, focusing on services built on open standards or those that have become de facto standards can be particularly beneficial. These services are universally accessible, both on-premises and across multiple clouds. Learning them once gives you the ability to apply them anywhere. Containers, Kubernetes, Knative, PostgreSQL, and HTTP are a few notable examples where Google Cloud’s support for standards shines.
If you are familiar with and favor these abstractions, applications will be more portable, and you will minimize “vendor lock-in.” This is where you become reliant on a particular provider’s service. Some cloud providers seek to minimize these concerns. Still, if suddenly they decide to double the price, discontinue service, or stop offering a service in a region you need to run your application, you are stuck. This means vendor lock-in should always be at least a consideration. I use the Google Cloud services that are widely available.
Ultimately, the real strength of Google Cloud lies in its robust foundational infrastructure, the hidden backbone built by Google’s engineers to run their global services. This strength truly sets Google Cloud apart from its competitors.
Strong Foundations
Google Cloud data centers are purpose-built with proprietary power distribution, cooling, and networking. The compute hardware within them is also custom designed and standardized throughout.
Google uses the term machine to refer to a unit of hardware and server for a piece of software that implements a service. As all hardware is standardized, any machine can run any server.
Machines are the smallest building block, with 10 machines assembled into a rack. Racks stand in a row. One or more rows make a cluster. A data center contains multiple clusters. Multiple data centers make a zone, and a region is then made up of three or four zones.
Each machine in a data center is linked together using a high-speed network fabric called Jupiter. Data centers are then connected using B4, a global software-defined network.
Even though Google Cloud is vast, think of it as thousands of standardized machines distributed around the globe, linked together by a fast network.