A few weeks back, Google held their annual Google Cloud Next event out at the San Francisco Moscone Center. I was really jazzed up to also get an invite from the community folks to attend the pre-conference Community Summit over at the Google Developers Launchpad. During the four days I was immersed in the world of Google and even ended up Getting ‘Googley’ with the developer community.

I’ll definitely tip my hat to Sarah Novotny, Program Manager of Kubernetes Community, for piecing together an action packed day covering machine learning, serverless, big data, containers, support, and so forth from heavy hitters like Sam Ramji, Kelsey Hightower, and William Vambenepe. These aren’t marketeers pitching slides – in fact, very few slides were ever shown – but folks with real world, hands on knowledge of how their areas of expertise perform.

You can troll through my Twitter feed for the hashtag #GoogleNext17 to see various reactions like the one below.

Sarah’s team also organized a half-day “un-conference” in which attendees could break apart into groups to discuss topics of interest. These are so incredibly valuable. In short, everyone writes down thoughts, questions, or concerns onto sticky notes. These are then organized into larger ideas that become discussion points. In our case, we had 8 different breakouts as shown below. I spent most of my time with the “E” group discussing abstraction layers with various Google Site Reliability Engineers (SREs) who melted my brain with their knowledge.

Nerdy Takeaways

It was extremely cool to hear their take on solving the CAP theorem with Cloud Spanner (or at least trying to). For those new to the technology, it is billed as “the first horizontally scalable, globally consistent relational database service for mission-critical applications.” One question that stands out was “why would I use Cloud Spanner?” with respect to another distributed key-store-esque database … the answer being that if you want to bring back some of the traditional SQL queries, joins, and other relational database goodness, and also reap the benefits of a database that can scale, then you might enjoy Cloud Spanner. Plus, the writing is on the wall for other Google databases; I get the strong feeling that everything at Google will live within Cloud Spanner at one point or another.

The other piece was how Google uses machine learning to do some fairly amazing work for their support organization. Google considers support to be a product, not a service, and handles it as such – in fact, the main presenter for our little group was the Product Manager for Support. The title sort of confused me for a bit, I’ll admit, but made sense after describing the use of a multitude of data points coupled with artificial intelligence to auto-magically solve a plethora of problems. There were also digs towards pretty much all of the traditional support structures and how legacy vendors twist arms with skyrocketing support contracts to squeeze a customer after the procurement was finished.

I also heard a great keynote presentation from the illustrious Dr. Fei-Fei Li, Chief Scientist of AI/ML for Google Cloud, who is one of the smartest people I’ve had the pleasure of hearing twice: she also did the closing keynote at VMworld Las Vegas a few years back. Among the more standard life improvement proof points that AI can bring about, there was also several references to open APIs that can be leveraged by the world to search video, natural language, provide translation, and even teach a computer to see. For the full suite of APIs, check out the API Explorer.

My one gripe, if you can call it that, is the need to build more reference architectures. As I allude to at around the 9:28 marker in the video at the top of this post, there’s a strong sense of respect that emanates from the Googlers to avoid telling people what to do. But I think there is a lot of value in showing a few ideas on how to build solutions in a Googly fashion. I don’t think people will generically hold Google’s feet to the fire for having a validated design of sorts to copy from – my enterprise infrastructure peeps like to see these. Cisco, VMware, and many other enterprise tech companies have provided these for years as an architectural talking point and reference guide for years, and I sort of like them. My two cents.

But Wait, There’s More …

More than the technical bits and bytes, which were a treat, was the sense that Google employees really wanted to hold a conversation with community members that are dealing with real technical challenges. After all, It’s The Community, Stupid! There was a strong sense of respect for all cloud platforms without the need to bash competitors. It didn’t matter that most of my knowledge revolved around Microsoft Azure; the teams really wanted to hear my input and feedback on using cloud compute, my future projects, and even details on challenges I was actively tackling with on-premises vSphere deployments. I enjoyed the level of respect and active listening (a very rare trait) that all of the highly technical engineers provided. Because, to be honest, it’s a bit nerve wracking to walk into a group of PhDs and well-known inventors of various solutions. Impostor syndrome is a real thing, believe me! 🙂

And there were donuts. Which helps.

Over all, attending Google Cloud Next 17 was one of the most valuable conferences I’ve had the pleasure of wandering around in a long time. This year I plan to also hit up Amazon re:Invent and Microsoft Ignite. I’ve watched a lot of their content online, but there’s nothing quite like being in the room with folks to ask spur-of-the-moment questions as they arise. If you get the chance to attend next year’s Cloud Next event, I highly recommend booking the travel and time!