The serverless computing model doesn't exactly embody truth in advertising. There are servers behind the popular application development method. But the machines are out of sight -- in a cloud provider's data center, where they're maintained and serviced. And they don't incur costs unless they're explicitly being used.
"There's definitely an efficiency and economic side to this," said Rich Sharples, senior director of product management at open source software vendor Red Hat. "I think that's what most people talk about. They talk about this way of really being able to scale up to super-low prices. And that's definitely interesting."
What's more interesting, Sharples said in an interview with SearchCIO, is the "human economics" of the serverless computing model.
"Developers are very, very expensive, especially in North America and Europe. You're optimizing the developers to deliver quality software faster, and serverless can definitely help that," he said.
Sharples, "a developer in a previous life," gave a brief overview of serverless computing; explained how it stacks up against alternative development tools, such as containers and microservices; and laid out steps development teams and CIOs need to take to be successful "serverless" practitioners. Following are excerpts of that conversation.
What is serverless computing, and how did it come about?
Rich Sharples
Rich Sharples: Serverless is currently where we are in this long arc of really trying to optimize the use of your servers. Back in the day, you had to buy a machine or a bunch of machines, and you had that dedicated hardware for a particular app. We then moved to virtualization. And then containers came along and really allowed you to optimize that idea of slicing up a real machine into virtual partitions to provide even greater density and control.
The latest is taking that idea even further: How do you further optimize this idea of your running workloads? All the previous examples -- whether dedicated machines, virtualized, containerized -- you're still generally running a piece of server software like an app server or web server. And you're just hanging around waiting for responses, whether they're web responses coming from a cellphone or browser. You're sitting around waiting for stuff to happen. So, you are paying for idle time.
With serverless, you really remove that. You do not pay for idle time. In terms of CPU usage and usage, you are only really paying the price for the amount of time it takes to handle a particular request. So, there's definitely an efficiency and economic side to this.
Is that why the serverless computing model is so hot right now?
Sharples: The bigger angle here is really about the developer productivity. Speaking as a developer in a previous life, developers are very, very pragmatic animals. They will follow the line of least resistance to get their job done. And, right now, serverless presents just an incredibly easy way to deploy code. Basically, it's an abstraction above all of the infrastructure and app servers, routing and images and versions. You do not have to care about any of that stuff as a developer. You just focus on your application logic and you have just a really simple means of getting that up and running and deployed and working.
Now, there's a trade-off. There's no silver bullet. With serverless, you're fairly limited in the kinds of workloads that make sense. And as an abstraction, it insulates the developer from all of the complexities of packaging applications and provisioning and deploying and configuring. It insulates you from all that stuff, which is good -- but it's also bad, because you, as a developer, do lose some control. So, it's really a trade-off in control and productivity. Serverless gives you fantastic productivity, but you are going to lose control versus a more flexible solution like containerized applications.
Which applications make sense for serverless computing, and which don't?
Sharples: It's really well-suited and optimized for very, very short-running tasks that don't have blocking -- not waiting for database queries to finish or waiting for some user input or whatever. So, they have to be fairly asynchronous and very, very fast to execute to make sense in this environment.
Serverless is a very, very simple model. You get an event from an event source. It could be an image appearing on a file system. It could be a row change in the database or a message appearing on a message queue. And in response to the events, you execute some code and you produce an output. If you can't break your application or your service down into that very, very simple model, it's not going to be a good fit. If you're doing a Monte Carlo simulation or some crazy big data analytics thing, it may not be a good fit. It's just perfect for a very, very rapid, reactive, event-based style of application execution.
How can IT departments determine when they should use the serverless computing model and when to use other methods of building applications?
Sharples: There are two threads here. One is maintaining the stuff we already have -- so, the app modernization. I certainly don't have the budget to be able to rewrite my existing applications just because a thing's come along, but I do want to get some of the benefits of maybe containerization and DevOps automation. So, containerizing those apps might be attractive. Breaking them down into microservices -- so, doing some kind of practical decomposition -- might be very attractive. That might increase my agility without having to do a massive rewrite. Sometimes you are going to be using traditional microservices; sometimes serverless will make sense. And whether serverless makes sense within that context is really going to come down to developer productivity and whether it fits that particular execution model.
We've been moving from a 30-year-old, well-understood, waterfall, predictable model to this [serverless computing] model, and it's tough.
Rich Sharplessenior director of product management, Red Hat
There are definitely going to be some speed and cost savings with serverless. Again, a lot of the interest around serverless is the machine time, the economics of execution. I think the more interesting thing is the human economics. Developers are very, very expensive, especially in North America and Europe. You're optimizing the developers to deliver quality software faster, and serverless can definitely help that.
The other thing I'm seeing relates to the whole idea of microservices. This is hard stuff. This is breaking down a traditional, well-understood, well-architected, monolithic application into smaller, fine-grained services. We're now into the realm of distributed computing -- I've got to think about a gazillion different failure modes that never existed before. Microservices is really hard stuff -- many people will fail at microservices. I'm definitely seeing some organizations, for some workloads, just leapfrogging the microservices and going straight to serverless.
Is serverless computing creating the need for skills that are less prevalent in IT departments today?
Sharples: From a developer's perspective, it is a different programming paradigm. It's event-driven, asynchronous, reactive. That's a little bit of a head shift for many people. To get the benefit from any of these big initiatives around automation and DevOps, there is an organizational aspect. How do you break up a 40-person developer team into smaller chunks so that, individually, they can move faster and independently?
Probably the bigger challenge is teaching developers how to do reactive programming and think asynchronously. Going to your development organization and demanding they break up into functional pieces and own the application or own the feature from idea all the way to production -- that's a massive, massive change. And I think that's where most organizations struggle. We've been moving from a 30-year-old, well-understood, waterfall, predictable model to this model, and it's tough.
And quite a lot of technology change can happen bottom-up -- it comes from the ops side and the developers' side. That kind of organizational change can't come bottom-up. That's something that CIOs and CEOs are going to have to care about. They are going to have to lead some of that change. Your teams aren't just going to naturally reorganize themselves.
Rich Sharples
