15-Minutes-Driven-Development, Or Why You Should Use a Server

In the past few weeks there’s a topic I find difficult to approach without imagining my doctor bugging me about my blood pressure. Which is why I’ve decided to tell everyone about it, so let me get you up to speed.

A Brief History Of Timeouts

It was July of 1969, and the landing module of the Apollo II was about to leave the moon, sadly their memory buffers had them doing it uncomfortably quick.

Apollo 11 Command Module On-Board Voice Transcript

Ah, yes, the grand space era where engineering really shined brightest, seeing up and coming ad-hoc solutions seeping deeply into our day-to-day habits.

One of those, as we see, was the timeout methodology, in which if you failed to run a specific electronic circuit over a specific timeframe then you’d break the entire task circuit, to recover onto a new circuit flow. This is where the term circuit breaking comes from, like Apollo’s famous life support circuit breaker that saved their lives.

The original broken circuit breaker switch from Apollo 11. The Museum of Flight in Seattle, WA.

Servers and Workers

Since then, we’ve managed to push the bounds on memory and processor utilization. And in the era of communications we were feeling free to create C/Java/Python/Ruby servers that took a long time to perform consecutive tasks on separate thread-workers without having to worry about recovery flows.

We would simply tag erroneous jobs in the database, kill the worker and go on with our lives, technically putting aside the worries of infrastructure-mandated time-out limits.

Oversimplified task worker server

Serverless Lambdas

So, we all got really cushy in our CRUDs, Threads and Restful everything environments but this was not very economical, so we’ve said the thing that makes the most sense.

”If we can run a container on any environment, and I only need to run a single function, then why not do that”

And that, as any friend would tell you about buying an old car, “was a great idea at the beginning“

We can fully rely on an event-driven cloud environment which would only run our most atomic functions, when we need them, if we need them. A real game changer for the digital era.

Extremely oversimplified serverless infrastructure, but we need some pictures because we all have ADD

But What About The Timeou…

If only we weren’t so greedy and used the lambdas for what we were aspiring. Minimal functions that reduce operational overhead costs but no, “What if we ran an entire express server inside it?” you asked, glibly, and added ”That’s technically a function, isn’t it? We only need to deal with this pesky timeou…”.

Why You Should Use A Server

Okay, I’m done ranting, which brings us to our issue; Sometimes, you should use a server. And it’s not a matter of style, a technical lenience, or a personal preference, it’s a matter of necessity.

Derive From Usage Not Preference

I think by this point it’s pretty obvious what bothers me, looking at it from a utilitarian point of view, all code runs on some sort of computer. Whether we’re simulating them for a few minutes(lambdas) or running them “indefinitely”(servers) is a crucial implication to the overall design of our codebase, which means that we cannot fully decouple these two decisions.

What Should I Do? You Ask

This means that if we expect a piece of code to have an extensive complexity footprint, we should either break it down to smaller functions which could be used as a smaller lambda function or use a server which would be able to orchestrate this load.

Now I know that tools such as the sam cli and others are awesome, I love them as well and the ease that they provide but this should not dictate our architectural needs.

So let me give you these rules of thumb

  1. If you need a task orchestrator, use a server
  2. If you have long-running tasks that you can’t/won’t break up, use a server
  3. But if you only wish to run the router of a server, still, use a server
  4. If it’s not a function, you guessed it, use a server
  5. If you want to run a server, use a server

Basically, if your lambda was too complicated to debug, you reached a hard timeout, missing a good orchestration mechanism, could not recover from a failed state without rerunning your entire task, or you just don’t understand the benefit of lambdas in your architecture.

I beg you, use a server.




Senior Software Engineer @Melio

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Windows 10 Post-Installation Checklist (December 2020 Updated)

READ/DOWNLOAD%$ Software Assessment: Reliability,

2020 Jina X Hackathon Retrospective

Birthday problem. Rehashed…

Why I am Betting on Polkadot (DOT)

BabySwap x YieldMagic — Optimized BABY Yield Farming

Web infrastructure design

Deploy WordPress Application On Kubernetes(Minikube) with AWS RDS Using Terraform

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Shaked Lokits

Shaked Lokits

Senior Software Engineer @Melio

More from Medium

Why Serverless is ideal for Startups

Update an Existing DynamoDB Table Resource to be a GlobalTable Resource

Growth System @Luko Engineering

Introduction to serverless databases