When serverless makes sense

The use of serverless computing is growing in the public sector. For example, Alameda County, Calif., used it during the 2016 election to avoid spending $20,000 on upgrading on-premises capacity after surging internet traffic during the 2014 election crashed the county’s server. Using a serverless solution, the county spent only $25 to keep things running smoothly.

The technology is fairly new, and government IT managers are still wrapping their heads around it. To get a clearer picture of what serverless means, its pros and cons and what can be expected from the technology, we chatted via email with Niko Köbler, a software architect, developer and trainer who has written a book on the topic. This interview has been edited for length and clarity.

GCN: What is serverless computing?

Köbler: Serverless is a new paradigm in cloud computing. The name itself is badly chosen -- of course there are still servers, but you as a customer don’t have to care about units like servers, virtual machines, containers or anything. You can focus completely on your code and thus on your business value. Or, more generally said, it’s an evolution of PaaS -- platform as a service -- which we already love and have used for several years. But with serverless, you just pay for what you actually use. There is no idle time of infrastructure you have to pay for. If there is just one event per hour, and your function will just run one second, you’ll pay only for one second per hour, not the whole hour as currently with VMs and other platforms, because you need the environment available just in case there will be an event. And if there suddenly are thousands of events per second, your cloud provider will take care of that; the whole environment will scale transparently without forcing you to do anything.

GCN: What are the advantages to using it?

Köbler: With serverless, you only have to deploy your code to the serverless environment, and your cloud provider will take care of setting up the runtime environment, scheduling it transparently upon the requests your code will process. The deployment unit in serverless isn’t a whole application or service anymore. Instead think of deploying and executing "functions." Small, independent pieces of code which will do exactly one thing, without side effects -- just like the definition of function in math. Also, don’t think in terms of “requests.” “Events” is the better approach for serverless where the code represents the desired behavior of the events (although HTTP requests can also be events).

GCN: What are the downsides?

Köbler: As deployment units become smaller, the number of deployment units will increase. The management of these units, in terms of functions and resource definitions (e.g., how a database table or storage type will look) is still a challenge.

Currently, there’s a thing called “cold startup latency,” which isn’t solved yet by the providers. When you are just deploying your function code, it has to be packed into a container for execution. And this container has to be powered up, and all the code and objects you are using must be initialized. This still takes some time. Depending on the programming language and the environment, this can be milliseconds to seconds.

Also, there are people saying that with serverless you are locked in to your cloud provider and that this kind of vendor-lock must be avoided at all costs. I don’t get this because everything you do today is a kind of lock-in. If you do things in-house, you are locked to your development and operations team. If you run your enterprise resource planning software, you are locked to this vendor. Of course, you have a certain kind of dependency on your cloud provider, but you’ll also get a massive bunch of advantages for your use cases. If you’re afraid of vendor-lock, you shouldn’t do anything in the cloud or, more generally said, you shouldn’t do anything in the IT business.

GCN: What are the best things to use serverless for?

Köbler: While you are able to build any application you like -- like before, just with a different architecture -- serverless is currently best suited for processing events asynchronously in a data pipeline. This can be mass data from an event stream or just converting documents and images from one format to another.

GCN: How secure is this technology?

Köbler: Running serverless applications is exactly as secure as running regular applications in the cloud. In my opinion, it’s also more secure than running all the infrastructure on your own because the people at your cloud provider know what they're doing to secure the infrastructure and to run it reliably. It’s their core business; they do it all day (and night) long.

But you have to take care of some security features. Your vendor will provide them to you, but you must use them in order that they work properly. So, as a rule of thumb, everything in the cloud should be encrypted, no matter if it’s data at rest or data in transit. Furthermore, you have to manage who or which resource is able to access other resources, services, storage, etc. You have to define some policies for resource usage; otherwise anybody out in the internet may be able to access your services and data.

GCN: What do you expect to see in the future?

Köbler: Currently [serverless] is a good complement to containers, but in the future, it will replace the handling of them. As already said, there are and will always be servers and containers, but in the future no one will care about them, as we all use serverless components from various cloud providers and let them do what they can do best: manage infrastructure. And we should do what we can do best: manage our business.