Author here, and I mostly agree with this sentiment. With that said, part of my Kiro spec here, had Kiro read my other blog posts and attempt to emulate my style.
I too found the write-up to be a little dry and long-winded, even though the same critique might be leveled at myself [hopefully to a lesser extent]. I did feel like it was a good step up from the usual AI slop out there, and served to illustrate Kiro's capabilities.
I suppose in this context, I wanted to see whether I could take my reader on a journey long enough for them to be surprised by the AI reveal at the end. I'm not sure whether it achieved that but that was the artistic intent of this specific piece.
I absolutely agree with the first part of this advice.
As to the assertion that complexity is not worth worrying about, I could not disagree more. I have watched projects fail time after time because of complexity, dependencies, and lack of budget.
Managers should encourage their engineers to spend time trying to simplify architecture and reduce code, infrastructure, and package dependencies. Smart engineers can learn to think simply over time, but this will not happen automatically. (I plead guilty to gravitating toward complexity in the early part of my career, but I have since learned better.)
Managers should place emphasis on using existing patterns wherever possible rather than re-inventing the wheel. Practicing laser focus on delivering value, evaluating solution dependencies with an eye to keeping things simple, and accurately modeling the problem domain in question.
Rather than trying to fight with engineers about implementation approaches, managers should try to guide engineers toward arriving at these conclusions themselves. I have also found that stressing simplicity as a key performance metric for engineers is a useful tool.
> I have also found that stressing simplicity as a key performance metric for engineers is a useful tool.
Some of the smartest engineers I've ever worked with produce code that is so well crafted it feels simple when you look at it, but it's actually extremely clever.
I think the conversation about "clever", "smart", "volatile" programmers tends to align the axis of _code_ complexity with cleverness, but often the cleverness is in finding the perfect simple solution.
"Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better." -- Edsger W. Djikstra
Complexity sells better because it's cheaper. This is not the, "look at this novel abstraction I wrote and proof of its correctness with respect to our specifications," kind of "complexity" that folks often mean. It's the hand-waving, just add the simplest patch you can to make it work for the business problem at hand, type of complexity. The kind of complexity that ends up with giant balls of "really simple" code that nobody understands entirely anymore.
It sells better for all the usual reasons that driving slightly over the speed limit gets you where you're going a little faster. It's only a problem if you get caught or cause a collision.
Your comment touches on the awol concept of clarity in this conversation: "The quality of being coherent and intelligible".
Balls of mud are the very essence of simplicity (in one sense) yet lacking any clarity.
Clarity is a (bad sort of) hot commodity in an immature yet rapidly developing technical field. In our field this is exacerbated by the fact that the entire field can be viewed as a monument to the peter principle (but thankfully the imposter syndrome is there as a collective salve for us all.)
I think highly intelligent engineers that can penetrate the essence of a problem and come up with effective & coherent conceptual models are a valuable but (in places) untimely assets. My recommendation to such engineers (who also wish to be responsible team members) is to recognize the cognitive impedance mismatch and broaden the 'scope' of the solution to include the human element, and descend to norm if necessary. The ultimate goal is to serve a broader goal, and fighting against impedance mismatch is un-/counter-productive.
My personal red line is the 'big ball of mud' teams.
A couple of points:
1. Cloud Run is more analogous to AWS App Runner than Fargate.
2. Cloud Run isn't a great analog to lambda. Lambda is built to host functions. Cloud Run is built to host applications. Lambda is more analogous to GCP Functions.
3. Cloud Tasks should probably be built with EventBridge + Lambda or EventBridge + StepFunctions or EventBridge + ECS.
I don't profess to be a GCP expert so it's hard for me to make a judgement call on what's better. I can, however, say that most of this post ignores some of the real serverless power provided by AWS. AWS AppSync, AWS API Gateway, DynamoDB, CloudFront Functions, Lambda@Edge. It also makes comparisons that are not very fair.
Huh. I had this long call with our AWS Account Reps (+ Support Engineers) the other day and no one mentioned App Runner! This is the first I've heard of it. Looking at it now.
Ah I see, launched originally in May 2021. That's probably why they weren't aware of it. Yes, this looks cool. Very much what I was looking for.
The differences that I can see are...
* AWS App Runner lacks an advertised free tier. Not a big deal for all but the smallest projects though.
* AWS App Runner bills rounded up to the next second, whereas GCP Cloud Run rounds up to the next 100 millisecond.
* AWS App Runner doesn't charge per request (?!), whereas GCP Cloud Run charges $0.40/1M requests.
* AWS App Runner has fewer CPU/RAM configuration options. The lack of low end options may be a blocker for us.
* It's cheaper than GCP Cloud Run - $51.83 @ vCPU/1GiB, but 2GiB minimum, in Runner vs $69.642 @ 1 vCPU/1GiB (v1) $97.50 @ 1 vCPU/1GiB (v2) in Cloud Run.
* I'm confused by the networking model. In App Runner, you have to make an ENI for your App Runner service to access your VPC? Weird. There's some extra cost there I think.
Things that I can't determine based on the documentation...
* Does App Runner support committed use discounts?
* Does App Runner throw a SIGTERM before shutting the container down? I hope yes but I can't find docs on it.
* Is there a file system accessible on App Runner and is it just in memory or is there actually a disk to write to?
* The quotas & limits page on App Runner feels incomplete and I'm left with a lot of questions about it.
* Is there an SLA?
* In fact the documentation for App Runner just feels a little incomplete.
It looks like AWS definitely wants App Runner to be the answer to Cloud Run, but to me, it feels like it's not quite there yet.
It's also weird, that ECS Fargate lets you run a container without thinking about the server that it runs on, and App Runner does too, just with a few extra things. Why is it a whole separate service? Why didn't they just add it onto Fargate?
Re: Other services. I've only heard of API Gateway, DynamoDB and Lambda@Edge; I'll have to spend time investigating the other ones. Thank you for mentioning them!
I know this is an old thread now, but I just came back to it and thought to dig in a bit. First thing my Googling hit was this, which provides a good comparison of App Runner and Fargate
