You're in an IT department. How does the rest of the organization see you? As a valuable asset whose code and APIs make a difference in the marketplace, or as a necessary evil that should be trimmed as much as possible? Containers, microservices, and serverless computing can make you more responsive, flexible, and competitive, which in turn makes your organization more effective. And that puts you solidly in the asset column.
After sprinting through the streets of San Francisco from the stage of the opening keynote at Red Hat Summit 2018 (replay available here), Burr Sutter hosted a packed house in Moscone South to talk about these technologies. Containers are widely accepted (see the announcement from Red Hat and Microsoft for an example), microservices are increasingly popular as an approach to modernizing monolithic applications, and serverless computing is emerging as an important new programming model.
We won't cover containers here (if you're still reading, we assume you're on the container bandwagon). Moving along to microservices, Burr went through several steps in modernizing a monolithic application:
- The monolith is broken down (conceptually, at least) into modules.
- Each of those modules is an obvious candidate to become a microservice.
- As those modules are rewritten as microservices, the microservices turn into a collection of pieces of code.
- Inevitably, the collection gets out of hand. It may have several entry points, you don't know how the microservices in the collection call each other, and many of those microservices manage their own data.
The Istio service mesh was created to solve these problems. As microservices are deployed into a Red Hat OpenShift cluster, Istio sets up proxy objects that let you manage and control how your services interact without changing any of the source code of any of those services. (See Don Schenck's excellent Introduction to Istio blog series to fully comprehend this awesome technology.) Istio makes microservices safe for the enterprise.
Burr made the point that serverless functions—also known as FaaS (Functions as a Service)—are different from microservices in several important ways. With FaaS, your code is:
- Hosted in an environment you don't control
- Short-lived (most FaaS offerings cut you off after 60 seconds or so)
- Built on a different programming model (for starters, if you're writing in Java, the
main()method you've been using for 20+ years doesn't work anymore) - Event-driven and asynchronous
You can tie together services with FasS, whether those are microservices you built in-house or XaaS offerings from the cloud. When an event happens, your serverless function invokes the appropriate services. You could, for example, use FaaS to call one of your microservices every time someone makes a change to a cloud-hosted database. Once you've defined the function and associated it with an event, the FaaS provider handles everything for you. Whether your function is invoked once a month or a million times an hour, the provider makes sure your code has the resources it needs.
Most importantly, the rise of FaaS changes the "build versus buy" considerations you've used in the past. Using a serverless function is much cheaper and simpler than provisioning and paying for the infrastructure required to handle any workload a traditional function might need.
Check out Burr's slides for the full story and links to other useful stuff, including the GitHub repos for the Istio demo and the FaaS demo.
You can watch the video of the session online: