Google Cloud Next Developer Day

I set out to Google Cloud Next Developer Day last Friday, expecting an event of maybe two or three hundred people catching up on Cloud Next announcements. Something along the lines of the AWS EDA Day I went to last month.

I was pleasantly surprised to find myself at a conference of well over a thousand people. This reflected positively on the community around what is often referred to as the third cloud. The attendance made sense; for me, Google Cloud may not have the mindshare of AWS or Azure, but it is the cloud of choice for many developers to build and innovate.

I expect more infrastructure-centric and operations people at an AWS event and Azure attendees to be heavily invested in the Microsoft ecosystem. This was a conference targeted at those building, scaling and securing applications.

I also went in with a product-centric view of what made Google Cloud different; GKE, Cloud Run, Global VPCs, load balancers, and strong data-centric services. By the end of the day, my view was changing and afterwards, I realised the differentiator was something more fundamental.

The day was kicked off by Stephanie Wong , a familiar face from all the Google Cloud YouTube videos and a familiar voice from the Google Cloud Podcast. Stephanie talked about Google Clouds networking but most interesting for me, she spoke about the building blocks, the undersea cables, Jupiter, the data centre network fabric and Andromeda, the software-defined network. This deep engineering and the abstractions built on top enabled the Global VPC, the Global Load Balancers with DDoS protection and CDNs built in.

During the day, a WhatsApp thread was going on with some friends discussing @DHH's article on why 37Signals was moving off the public cloud after finding it significantly more expensive than on-prem. I argued that DHH was still thinking about EC2 app servers and RDS database servers and that because of this he was unlikely to see much benefit.

That was not what I saw at this conference. Yes, Google Cloud provides bare metal machines and VMs, but that is not its strength. Like networking, it is about the well-engineered building blocks behind the scenes and the abstractions product they enable. Colossus presents storage in terms of bytes and IOPS required; Borg allocates compute capacity, memory, and bills by the second. The products follow, built with the benefit of a fast global network and independently scalable computing and storage.

For example, unlike AWS, the compute products fit together nicely. In AWS, Lambda feels on its own, a compute option unrelated to EKS or ECS. In Google Cloud, the latest Cloud Functions run on Cloud Run, and the container is abstracted away. The same containers that run on Cloud Run can run on GKE Autopilot and be billed per pod or can run on classic GKE and be billed per cluster. If needed, you could also run these containers on Azure AKS, AWS EKS or an on-prem Kubernetes without modification.

As a developer, you can choose a compute abstraction that meets your level of cloud native maturity and reap the benefits. There is an incentive to move up an abstraction level and stay there as there is little reason to move down. Cloud Run reminds me of Heroku or Cloud Foundry; if you can architect your application to run within the constraints, you get the cost, scalability and developer experience benefits of a fully managed service. However, unlike Cloud Foundry, if you are still getting there, you can drop back to GKE Autopilot, GKE or the lower-level abstractions, as they are all available.

Google seems genuinely interested in helping developers to consume cloud native services using the highest suitable abstraction. That means going straight for Cloud Run, GKE Autopilot or even Cloud Functions and skipping over some of the Kubernetes adoption challenges discussed in Saffi Ali ’s talk. This makes sense as Google’s building blocks are attempting to fully utilise underlying compute resources, and leaving idle CPUs is not helpful for either Google’s capacity, customer’s costs or, ultimately, carbon consumption. It makes no sense to have GKE clusters or VMs with idle capacity if you can avoid it.

I particularly enjoyed John Abel 's talk about sustainable development principles, which higher-level abstractions unlock. An example is running portable workloads such as Cloud Run, where there is the greenest energy available at any time. I look forward to Google possibly joining the Green Software Foundation in future, as they have the knowledge to contribute. Something that did stand out is how 1PB of SSD is estimated to use embedded carbon equivalent, powering 60 homes per year.

Another Google Cloud abstraction that sits well for me is the use of PostgreSQL as a standard across multiple services; Cloud SQL, AlloyDB and Cloud Spanner are different database offerings, each making increasingly optimal use of cloud native networking, storage and computing. The great thing, however, is that they can be accessed by a PostgreSQL API, making it easy for an application to transition as performance, scale and availability requirements increase.

Overall the most interesting new feature for me is Cloud Workstations, where I can use my IDE, Jetbrains Goland, with a thin client locally to consume a development VM on Google Cloud via SSH. The development VM has access to all the cloud services within a VPC. This means that code never needs to leave the security of the Google Cloud and move onto a developer’s laptop, code exfiltration being a big headache in regulated industries.

I used to use Cloud 9 to work with AWS and Eclipse Che on OpenShift via a browser on my Chromebook, but this is much nicer as it is a full IDE suitable for all-day development. My one gripe is as an individual developer, I hope Google drops the 24/7 $0.20 per hour management cluster fee, so I can genuinely only pay for the VM when in use. If I were managing a hundred developer workstations, it would be understandable, but I can see myself accidentally spending $150 every month unnecessarily for a single workstation.

The investment in new security tooling throughout the software delivery lifecycle was noticeable with a talk by Daniel Perry on Software Delivery Shield, which adds a layer of security at points through the software supply chain, from providing trusted versions of 3rd party libraries to securing deployments. There was also a talk by Carlos Leonardo Rosario on Denial of Service (DDoS protection) with Cloud Armour that demonstrated the scale of attacks that have been happening.

Later in the day, I spoke to speakers about this as I was interested in what motivated the security focus, as I assumed it came from customers. It came from customer needs, government investment and what has been done within Google to protect its services. The threat level has increased dramatically over the last year, and these products are part of the response.

In summary, this was a positive conference. I like how Google openly encourages developers to use its cloud native services efficiently. There is also a desire to use open standards, which minimises lock-in. The security focus is also encouraging, providing powerful tools within the platform and making it more enterprise-friendly. Google Cloud is differed by its approach, and its ability to use well-engineered foundations to build services that meet developers with the right level of abstraction for their cloud native maturity. For developers, I believe Google Cloud is worth taking seriously.