There are two things I’m certain of:
- The serverless community is really pumped about their new toy
- Like every other time a hot new toy has come out since I was 8, I have to go through a soul-searching process to decide how to spend my allowance (i.e. limited time)
Some people will say serverless isn’t a new concept – we’ve had CGI for ages. Others will say it is new because CGI is hard to deploy to.
My read is that we’ve been doing cloud for a long time and we’re starting to find abstractions that work – in particular, abstractions that make our applications work well with deployment and load balancing.
Serverless isn’t better than CGI at runtime, it’s better when you have to manage it. And for an increasing number of businesses, that’s ‘all the time’.
Serverless also may reduce the amount of code you have to manage and check in to git. My rule of thumb for maintenance costs by LOC is: code you write and maintain, 1x. Library code you don’t check in, 0.3x. Library code you have to paste / check in to git, 2x. Managed infrastructure is in theory some new, even less expensive category.
Does that mean serverless will take over?
Code will need to work in more & different runtime environments, of which serverless will be one. Maybe your handler is started by a web request, maybe by a message, maybe by a smart load balancer that calls it with a continuation.
The missing link in developing these services is that they only work on managed cloud, or they don’t work the same on managed cloud and my laptop. That makes them hard to try, hard to learn, and hard to test.
What I expect to see in the next 12 months
What new infrastructure components will make a real difference in developers’ lives (i.e. jobs) this year?
Environment standardization between cloud and laptop.
Docker made a big difference when it first came out, causing near-instantaneous adoption, but hasn’t improved that much since then. To stay relevant it needs to find a way to provide standard environments between laptop and cloud, so people can work on apps instead of just on containers.
It’s silly to me that hub.docker.com doesn’t have a way to host compose files. This is creating a hole in the market that’s getting filled by kube helm (among others). But kube doesn’t work well on the local machine. Like hannibal lecter, minikube is apparently only safe inside a VM and even then will eat (yeah) your laptop battery.
There are lots of recent projects to provide a standard base environment where you can run containerized services without knowing how they work. Sandstorm is an example, digital ocean droplets is a (bad) example, and the wordpress community has been doing this for years.
Docker hasn’t added features for this and when they do, it’s often in an 80%-compatible new product that may share branding with an old one. (Do secrets work with compose or stack or swarm? Compose v3?).
Kube already has a plugin architecture; my understanding is that it allows applications to manage containers. If docker (moby?) could standardize the plugin API for container-aware infrastructure tools, that would go a long way to simplifying how apps ask for what they need.