A manifesto for cloud-oriented programming.

Don’t get me wrong, I love the cloud! It has empowered me to build amazing
things, and completely changed the way I use software to innovate and solve
problems.

It’s the “new computer“, the ultimate computer, the “computerless computer“.
It can elastically scale, it’s always up, it exists everywhere, it can do
anything. It’s boundless. It’s definitely here to stay.

But holy crap, there is no way this is how we are going to be building
applications for the cloud in the next decade. As the cloud evolved from “I
don’t want servers under my desk” to “my app needs 30 different managed services
to perform its tasks”, we kind of lost track of what a great developer
experience looks like.

Building applications for the cloud sometimes feels like spilling my kids’ bag
of unused Lego blocks all over the living room floor, and trying to build a
castle. After going through torn up play cards, scary Barbie-doll heads, and
leaking dead batteries, you read the instructions the millionth time, only to
realize you ended up building basically the same thing you’ve built last time.

Sorting Lego blocks is fun! It passes the time with the kiddos. It even feeds my
OCD… But hell, this is not how I want to build professional software!

Let me try to describe what me and my developer friends are struggling with.

I want to focus on creating value for my users​

When I build professional software, I want most of my time to be spent within
the functional domain of my application, instead of non-functional mechanics
of the platform I use.

It doesn’t make sense that every time I want to execute code inside an AWS
Lambda function, I have to understand that it needs to be bundled with
tree-shaken dependencies, uploaded as a zip file to S3 and deployed through
Terraform. Or that in order to be able to publish a message to SNS, my IAM
policy must have a statement that allows the sns:Publish action on the topic’s
ARN. And does every developer need to understand what ARNs are at all?

All that stuff doesn’t have anything to do with the value I am trying to create
for my users. It’s pure mechanics. Can we get rid of it?

I want to be independent​

One of the most frustrating and flow killing situations for me as a developer is
when I have to stop and wait for someone or something in order to continue.

It’s like gliding happily in the air, enjoying the view, beautiful music in the
background, and suddenly, BAM! A concrete wall.

This concrete wall takes many shapes and sizes when you build applications for
the cloud. It’s the DevOps person with an endless ticket queue; it’s the IAM
policy that needs to be updated; it’s the deployment failure that only the
external part-time consultant knows how to debug; It’s the endless backlog of
missing knobs and APIs in the internal platform that we hoped will change
everything.

These barriers are frustrating because they force me to switch context, to apply
“temporary” security policies and to invent ugly hacks that I don’t want to talk
about. It’s a broken world.

I want to be independent. I want to be able to get things done, to stay in the
flow. I want to improve the world one commit at a time, and move on to the next
thing after I am finished. I want that dopamine rush of completing a task, not
the shameful feeling of yet another unfinished thread.

I want instant feedback​

I said I want independence, but don’t mistake that for a belief that