Comment by pech0rin | Hacker News Reader

Comment by pech0rin | Hacker News Reader

This sounds like an interesting setup, but honestly my alarm bells are seriously going off in terms of cognitive load for every developer. I would love to see how much time is spent on ops at this company vs actual dev time. Also once they are hitting scale I am really interested how all of this holds up. You have 7 devs now, what happens with 20 devs on different teams.

Also since this is a beta product, I am doubting that you would hit too many problems with any deployment solution at this point. Why are you using Aurora + serverless + event bridge at all? Its magical because you are all using the same dependencies as prod, but why are you using these dependencies at all? All you need is a single postgres database (easily spun up on any developer machine) + crud app (easily able to use full stack typescript with nextjs or the like).

Word of caution about having this many moving parts, they will bite you in the ass. Now it seems all rainbows and magic but there is a reason people on this website preach simplicity -- because when shit hits the fan the simple solutions are easy to debug and fix without spending 1000s of dev hours. The complicated magic solutions are the ones that cause 24+hr downtimes and need to be re-architected. You are a customer service tool, not a devops company, the choices here don't make too much sense.

I feel like the cognitive load here is just different, not worse.

Dev environments in traditional shops are usually a PITA and only really resemble production. We’re all just used to it. This model is different but once you’re used to it, must be quite a joy. The main drawback seems to be developing against real services (rather than emulated) is slower, but that seems like a worthwhile trade off IMO.

It seems risky though. One runaway process that accidentally floods this infinitely scalable Amazon cloud with requests and you could quickly rack up a huge bill. I'm not sure I want this hanging over my head during development and testing. It's problematic enough in production.

That’s a trade off. With the traditional approach you may introduce bugs into production when your dev environment isn’t a perfect emulation (works in dev!). With this approach dev and prod are much more identical.

True, but this problem is greately exacerbated by the incredible complexity of this sort of architecture. And running dev in the cloud doesn't completely solve it either as configuration issues have always been a major cause of the "works in dev" issue.

Again, “incredible complexity” is not correct, it’s just complex in a different way. Serverless is pretty remarkable because it abstracts a huge amount of pain away. Never deal with weird file issues or even having to think much about scalability.. that’s a huge luxury. There are other parts that are more complex but you’re basically trading a lot of nuisance away

I feel like we reached a sweet stop with Docker or dedicated VMs, where the dev environment was near-identical to production.

The serverless trend breaks this a lot by making the production environment cloud-only and not something that you can run offline.

This is how many (most?) teams develop at...Amazon. It definitely scales to large teams and large (1000TPS) projects.

so this company with 7 developers has the same amount of resources as amazon?

Clearly not, but this is a circular argument. As companies expand in size they naturally increase both their needs and their resources.

Are you arguing that using SaaS developer tools like the ones in this journal entry consumes a greater proportion of engineers' capacity than self-hosting does, and that this cost difference becomes proportionally greater as a company grows? If you're right, perhaps some cloud-based startups and also larger businesses will be eaten up by more nimble, efficient self-hosted competitors.

(I work for a cloud host)

The article clearly states how they scale this down to save on costs and dev time. No mystery here.

I had suspected something like that from how basic CRUD operations on AWS can take minutes of latency compared to seconds when running whatever-it-is locally.

At least their solution architects get some moral redemption from peddling these messes..

Most teams at Amazon are still using Brazil and Apollo (internal build and deploy systems that were brilliant 12 years ago but have aged poorly). CDK is just starting to become more common throughout the company. Many orgs barely use it.

And those systems have the entire Builder Tools org making sure they work.

When I try to visualize their full set of aws resources (say, their TF aws 'resources' etc) ... might not look pretty under the hood. You have to drink the serverless koolaid-on-steroids to be putting all your eggs into the 'aws-basket'. OTOH, this might be a brave thing to do, as devs we/I hesitate to cross that line when nothing is on our laptop & the IDE lives on the cloud. maybe that's the future.

One issue (that he mentions) is that not everything is mockable in the AWS (or any other cloud envmt) - this has some repercussions for TDD.

Reply on news.ycombinator.com