What comes after Serverless?
Thinking out loud about a Deployless future (and what that means for Container Images)
I remember when continuous deployment was controversial. You want us to deploy to prod how often? I remember when continuous integration was a suspicious idea. You want us to ship software with no QA phase? How would that even work?
I remember when Cloud was all very well for toy apps but real businesses weren’t going to outsource their infrastructure to someone else. What if it broke, who would we shout at?
Many of the best ideas are entirely crazy - until they’re not.
You may sense that I’m trying to soften you up for something, and I am. The next evolution of continuous integration and continuous deployment is also the next evolution of IaaS and PaaS and FaaS. It’s Deployless development.
Continuous integration said let’s make testing so integral to our workflow that we’re always ready to ship, so we don’t need a separate QA phase after development. Continuous deployment said let’s make testing and rollback and deployment so effective that we always do ship, multiple times a day. Deployless development says let’s not even deploy: no source control vs execution environment, no staging vs prod, no deployment artifact — just code.
Infrastructure as a Service said let’s forget about owning specific data centres, Servers can be acquired on demand, as needed. Platform as a Service said let’s forget about Servers, middleware can exist on demand, as needed. Function as a service says forget about Middleware, functions can exist on demand, as needed. Deployless says forget about functions, deployment can happen on demand, as needed. Just work on the application, the platform will handle deploying it, running it, scaling it.
Deployless development will look a lot like distributed smalltalk. There’s a code base that you update which is the running application (yes, this is also a bit like ssh-ing in and editing a PHP file except with a service mesh so not everyone immediately sees that edit). You don’t move an artifact between ‘dev’ and ‘test’ and ‘staging’ and ‘prod’, or even between ‘source control’ and ‘infrastructure’. You update the application code. “Staging” and “prod” are routing decisions, not infrastructure decisions.
Let me remind you: most of the best ideas are entirely crazy — until they’re not. Continuous Deployment was not a good idea until we figured out how to do it right. Deployless is currently a bad idea but I think the pieces are falling in to place to make it work. Now that we have functions as a service and service meshes “deployment” stops being an infrastructure concept, and becomes a feature of the service mesh. In a micro-service environment and especially a Function as a Service environment “test in prod” is a practical necessity. And if we need to test in prod we need to develop in prod and we need a development flow that embraces that. When you can effectively rollback and between individual functions and when you have tools that support observability of the emergent system this starts to become possible.
The corrolary of this is a lot of the thinking about “immutable images” that can be shipped between environments becomes quite irrelevant. There are no environments. There is no staging environment and CI environment and production environment which a container image flows between. There is no server or middleware for us to package source code in to an artifact to deploy on. There is the service mesh, there is code, there are versioned functions, there are routing decisions (perhaps initially only test code can actually see the latest version of a function). There is no “test locally” because in a microservice environment you’re almost inevitably deploying and testing against a distributed environment. You’re updating a function in the running application, not updating code that you then “build” in to a container and “deploy”.
I don’t know when (or if) this will happen, but this is my best guess at an answer to the question of what comes next.
