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.

Leave a Reply

Your email address will not be published. Required fields are marked *