Is it? If you compare to serverless, you'd almost have to compare AWS EKS Fargate and with that, there's a lot less operational overload. You still have to learn ingress, logging, networking, etc. but you'd have to do that with serverless as well.
I'd argue between AWS serverless and AWS EKS fargate, the initial complexity is about the same. But serverless is a lot harder to scale cost efficiently and not accidentally go wild with function or sns loops.
This is my experience too. We served fairly complex data requests, around 200,00 per day, for mobile and commercial users using ECS Fargate and Aurora Postgres as our main technologies and it coped fine.
Used Golang and optimised our queries and data structures and rarely needed more than 2 of whatever the smallest ECS Fargate task size is, but if we did it scaled in and out without any issues.
Realise that isn't at scale for some but it's probably a relatively common point for a lot of use cases.
We put some effort into maintenance, mostly ensuring we kept on an upgrade path but barely touched the infrastructure code other than that.
One thing we did do was limit the number of other AWS services we adopted and kept it fairly basic. Seen plenty of other teams go down the rabbit hole.
This is one thing that REALLY frustrates me about enterprise. So often the c-suite wants to push for going cloud platforms (aws, azure, snowflake, along with all the costs, "because they need it". It's this narrative of scale that drives these discussions - so few companies are genuinely dealing with 200,000 requests per day!
Genuine question - have you come across good/useful case studies/summaries of going cloud?
All I can really get is "pretty toys", "everyone is going cloud", "we don't need to have network engineers (we now need azure network engineers)", etc.
I have been involved in several cloud migrations of existing systems. These where all successful and a lot was driven by not having to own and manage the underlying servers and/or the need to replace aged systems at the very last point possible.
Like most things understanding the rationale and desired outcome are key. One of the things you get from going to cloud is, as you point out, is a wider group of people who already know and understand key parts of the architecture/infrastructure choices.
I see this as an opportunity to not use YAML and use a better IaC framework like AWS CDK or Pulumi where you can write expressive code in many languages and can use full language features including DRY declaration of constants in a single place.
I gave it an honest chance, but couldn’t get a single PR out of it. It would just continue to make mistakes. And even when it got close I asked it a minor tweak and it made things worse. I iterated 7 times on the same small problem.
Currently in the stage of evaluating Codex (mostly comparing it to Aider and my own homegrown LLM setup). I'm able to get changes out of it, that mostly make sense, but you really need to take whatever personal guidelines you have for coding and "encode" them into the AGENTS.md, and really focus on asking the right question/request changes in the right way.
Without AGENTS.md, it seems to go of the wrong end really quickly, and end up with subpar code. But with a little bit of guidance, I do get some results at least. This is the current AGENTS.md I'm using for some smaller projects: https://gist.github.com/victorb/1fe62fe7b80a64fc5b446f82d313...
With that said, it does get mislead sometimes, and the UX isn't great for the web version. It's really slow, you can't customize the environment, the UI seems to load data in a really weird way leading to slowdowns and high latencies, and overall it's just cumbersome. My homegrown version is way faster for the iterations, + has stateful PRs it can iterate on and receive line comment feedback on, but the local models I'm using are obviously worse than the OpenAI ones, so I'd still say Codex is probably overall better, sadly.
Try this experiment. Install a few apps, like Time Doctor and Wakatime to track where you spend most of your time while on the computer for work purposes.
After a week, take note of how many hours you spend actually writing code.
I won’t share my exact count, but it’s shockingly low in relation to all of the hours spent working.
My bottleneck to more productive output is 100% not “unable to write more code faster”. It’s actually people. Other people.
reply