Google Cloud Next 2018: Is this the year that Google embraces serverless?
At Nordstrom we invoke over two hundred million serverless functions every day in our pursuit to streamline and optimize the web experience for our customers. These functions back many of our services, from Reserve Online & Try In Store, to image processing pipelines, to personalizing our website and mobile app, and more. So naturally we were excited to hear about everything serverless at the Google Cloud Next 2018 technology summit.
When we arrived at the conference we immediately noticed that Google has started to describe lots of existing Google cloud services as serverless. This was our first hint that this may be the year that Google embraces serverless as a first-class design pattern. Additionally, in many talks the speakers pointed out that Google App Engine has been serverless for the last ten years. Whether you agree with these assessments or not, it is clear that as a company Google is beginning to notice momentum around this inexpensive, low ops, scale-to-zero, event-triggered, scalable paradigm.
In addition to this shift, there were also a number of interesting announcements and improvements. Let’s walk through what was announced.
Google Cloud Functions goes GA
If you’ve been following the serverless news, you’ll know that Google Cloud Functions have been in beta for a substantial amount of time. It’s hard to depend on a service for critical functionality without the general availability stamp of approval (and official SLA) from the cloud provider. The great news is that Cloud Functions are now GA and we can expect Google’s full support behind them.
More language support, more features
In addition to general availability and an SLA, Google has added beta Python 3.7 support, and promises to add more language support in the near future. Also welcomed is the addition of environment variables, which can make wrangling multiple stages and data layers easier. In the coming soon category we also heard about better VPC and VPN controls, scaling limits, and Cloud SQL connectors.
gVisor: the sandboxed container runtime
While gVisor won’t perhaps have a direct or immediate impact on developers, it plays to Google’s strong suit of deeply thinking through all of the layers of security within their infrastructure. gVisor is the system that allows multiple serverless functions to run on the same underlying hardware systems while preventing them from maliciously or accidentally interacting with each other.
Kubernetes moves towards serverless with Knative
In addition to serverless functions, our Nordstrom tech teams also deploy a lot of Kubernetes pods to run key features and infrastructure. In fact, our engineering standards require either serverless or Kubernetes for all new features. This ensures that we spend more time on customer-facing features and less time on code complexity and operations.
Knative (pronounced “kay-native”) and the associated GKE Serverless Containers implementation is a fascinating step in the serverless direction. A combination of build and deployment automation, an event-triggering definition, and scale-to-zero capabilities brings many serverless conveniences into the Kubernetes world.
It’s worth noting that Knative is still an ‘app-level’ implementation. This means that each instance of the application handles multiple events until it’s too hot — at that point another container is invoked. Google Cloud Functions are ‘event-level’ — each invocation only handles a single event at a time. Event-level serverless can be simpler to conceptualize and maintain.
What we’d love to see from Google
Serverless function basics: we’d like 429 responses when functions are over the account threshold instead of 500 errors, no deleted/un-deployed functions if they haven’t been used in a month (some functions exist to handle alerts and alarms that are rare), better least-privilege permissions, and better overall performance. As we get more experience using Google Cloud Functions, we’ll know more.
Event-trigger ecosystem: In some ways a serverless ecosystem is only as good as its event-trigger options. We’d love to see more coverage of GCP services that can directly invoke cloud functions. For example, we do a lot of triggering functions off of NoSQL change streams, and we would love to see something similar.
Ordered options: Pubsub is fundamentally unordered, which is great for most things — but sometimes you really want ordering. This is especially true in an at-least-once-guarantee world where you’d like to ensure idempotency of your function’s actions. For example, in an ordered system if you’ve already processed event #425 you can be sure that if you’re seeing event #421 you can safely ignore it as a duplicate.
To finish up
In a multi-cloud environment we strive to select and use core technologies that will help us create a seamless shopping experience for our customers. We’ve found value in serverless patterns, which allow us to spend more time creating new experiences focused on service and product, and less time on code complexity and operational burden.
We’re excited by the momentum that Google has shown in the serverless space and look forward to even more improvements in the coming year. What do you think? We’d love to hear about your experiences with serverless patterns and architectures.
Who am I?
My name is Rob Gruhl, and at Nordstrom I support a small team of engineers called the Emerging Technologies team within the Engineering Platform organization. On our team we do a lot of learning, teaching, and shipping to production in partnership with internal teams. Our goal is to understand both the capabilities and limitations of services, technologies, and patterns. For the past three years we’ve been largely focused on serverless and event-sourcing patterns.