That 70’s Serverless Article

This article has been making the rounds on Twitter & LinkedIn, inciting and resonating with people. Either “I completely disagree with this guy! 🤬” or “YES, this guy gets it! 🙏🏼”. I’m… both.

He invokes both my 20’s-Jesse-thinks-he-knows-everything-and-must-own-this-wrongness and my 40’s wistfulness at simpler tooling. Let’s tackle both.

Serverless workflows aren’t slow; I have no idea what in Zeus’ name he’s doing. Here’s Python; all steps are milliseconds to 5 seconds:

  • python
  • pytest
  • aws lambda update-function && aws lambda invoke
  • behave (depending on mock speed)

You see the logs in your Terminal/IDE. If you want to log into AWS CloudWatch to see your logs, sure, you can do that.

As an art student UI guy turned back-end, function as a service is WAY simpler. I don’t have to know anything about Unix. I can deploy it as a monolith OR a microservice. I can use both a monorepo OR repo per service. My code just works.

More importantly, I don’t have to update servers every month w/security patches & re-test and hope the latest AMI doesn’t sabotage my logs or some other whack permission again.

You do microservices because large codebases are horrible, regardless of language.

CloudFormation/Terraform/Yaml are all terrible. Dhall is nice, but we need much better tooling here.

Erlang’s deployment process is the best. The industry moving away from that model is quite sad.