It has been a couple of years since I switched from oh-my-zsh to zsh4humans. Since then, I never had to worry about any performance related issues when starting my shell. It always felt instant. Until now.

The Problem

A couple of months ago, I noticed considerable lag when starting a new instance of my shell. I’m not really sensitive to shell startup time, since I’m not a heavy shell user (mostly inside VSCode when coding and sometimes in iTerm to trigger one-off commands or navigate something buried in a hidden folder). But startup times (more specifically, time to first command or first_command_lag in zsh-bench lingo) measured in seconds instead of milliseconds is too much. So I digged into my ./dotfiles to find the culprit.

Our team, a bunch of experienced software engineers without prior contact to cloud deployments, wanted to deploy our OCPP-compliant EV Charging Station Simulator (EVCSS) publicly, so that early users and other stakeholders can easily test it.

Sounds simple enough, right? That’s what we thought. And optimistically pulled the “Cloud Deployment” Issue in our current Sprint because we had a couple of additional days to work on it.

Let’s make it a size M, just to be sure…

On our first introduction to AWS, we were greeted with an admin panel, a considerable selection of services and found ourselves right in the middle of choice paralysis. What do we actually need? It was difficult to find the best or even any way to deploy our simple client server application. So we enlisted a specialist, someone with prior experience with AWS and cloud deployments, who may shed some light on the path we couldn’t see in the haze of three-letter acronyms and similar-sounding services (is that what S3 stands for?).