I’ve been thinking a lot about serverless architecture and I’ve realised what bugs me about it.

This is gonna be a long one. Not gonna lie, I wrote a draft first. If I hadn’t, this thread would end right before it got interesting because I’d get distracted by a butterfly.
At its heart, serverless/FaaS/lambda/whatever-you-call-it works for me because it ties action to cost. The more I do (or the more inefficiently I do it), the more I pay. More users, more money. @gojkoadzic wrote about this years ago. It’s not new. gojko.net/2016/08/27/ser…
The problem, I find, is that in doing so, it breaks your application apart. Now we have many applications. They all work with HTTP, or message queues, or some other data interchange layer I don’t care about when I’m designing functionality for a user.
I’ve been preaching the joy and value of functional programming since I was but a child. I firmly believe that a functional core to an application lends it reliability, debuggability, testability and all that stuff you need but never prioritise.
(Seriously, I learnt Haskell when I was 17 and never looked back.)
Serverless architectures fuck this up. They reward “do one thing” programming, but at the expense of that functional core. There are no cores any more, just the imperative shell. (Thanks, @garybernhardt, for that awesome wording in destroyallsoftware.com/screencasts/ca….)
Suddenly, our high-level infrastructure is decoupled and neatly structured, but our low-level code is error-prone and full of duplication. It’s all HTTP, no logic. JSON, not objects. Validation, not behaviour.
So we’ve gained a way to structure our application, but lost our code structure. We might be able to regain some of it by factoring out infrastructure libraries, but then we’re tied to one language again. We’ve lost value.
Jumping sideways a bit: Elm is a beautiful language. (I hope it survives.) One thing it showed us is that with a *very* minimal framework, our code could be completely pure. No side effects, just input and output. Message comes in, messages go out.
Call it Functional Reactive Programming or whatever you like, Elm demonstrates a programming style that is flexible, decoupled, extensible, type-safe and robust. My Elm projects don’t break. Ever.
Messages go in. Messages come out. Purely functional. Why aren’t we writing serverless functions like this?
I believe the next step after serverless architecture is a simple translation layer. Instead of dealing with HTTP, your function accepts a message and returns zero or more messages. Functional all the way through. No side effects.
Other functions do the same. They’re just like you. You deal with user-level HTTP (or other endpoint infrastructure) with system messages. How they’re sent is an implementation detail. Probably intra-app HTTP.
What does this buy us? Stability. Even if the code’s wrong and you mishandle a message, you *know* you did. Why? Because you have an event log. An immutable record of everything that happened.
So what do we get for free, aside from the benefits of FP? A log of all events. Replayability. Reproducibility. A time-travelling debugger. Full information on everything of importance that’s happened in your system. Event sourcing for free.
So why aren’t we doing this yet? I wish I knew. I don’t know why people aren’t writing Elm or Rust or Haskell either.
If we’re going to make software, let’s make it the best ways we know how. Life’s too short to make problems for ourselves later.
For the morning people. I’d love your feedback.
(It’s on the blog too, because @PeterHilton asked. monospacedmonologues.com/2018/07/functi…)

• • •

Missing some Tweet in this thread? You can try to force a refresh

Keep Current with samir, doing far too much, yet again

samir, doing far too much, yet again Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!


Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

Did Thread Reader help you today?

Support us! We are indie developers!

This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Don't want to be a Premium member but still want to support us?

Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal

Or Donate anonymously using crypto!


0xfe58350B80634f60Fa6Dc149a72b4DFbc17D341E copy


3ATGMxNzCUFzxpMCHL5sWSt4DVtS8UqXpi copy

Thank you for your support!

Follow Us on Twitter!