I’m not sure how controversial this is - but 100% code coverage is almost always a waste of time, paid both immediately and long term, for certain languages. Go, for example, requires explicit error handling, but the way errors are handled are usually plain and homogenous. Adding unit testing everywhere creates a phenomenal amount of test code that can become 3x the size of the source, and certain changes (like interface changes) can require updates to all tests, especially if mocking is used.
Obviously with AI maybe those issues I have go away. But I really don’t like letting the AI modify tests without meticulously manually reviewing those changes, because in my experience the AI cares more about getting the tests passing than it does about ensuring semantic correctness. For as long as tests are manually maintained I will continue keeping them as few as necessary while maintaining what I view as an acceptable amount of coverage.
Even internal Amazon tooling is impacted greatly - including the internal ticketing platform which is making collaboration impossible during the outage. Amazon is incapable of building multi-region services internally. The Amazon retail site seems available, but I’m curious if it’s even using native AWS or is still on the old internal compute platform. Makes me wonder how much juice this company has left.
Amazon's revenue in 2024 was about the size of Belgium's GDP. Higher than Sweden or Ireland. It makes a profit similar to Norway, without drilling for offshore oil or maintaining a navy. I think they've got plenty of juice left.
You’re right about that. I guess what I mean is, how long will people be enthusiastic about AWS and its ability to innovate. But AWS undeniably has some really strong product offerings - it’s just that their pace of innovation has slowed. Their managed solutions for open source applications is generally good, but some of their bespoke alternatives are lacking over the last few years (ecs kinesis code* tools) - it wasn’t always like that (sqs ddb s3 ec2).
The universe's metaphysical poeticism holds that it's slightly more likely than it otherwise would be that the company that replaced Sears would one day go the way of Sears.
Sure, but it’s not reasonable that internal collaboration platforms built for ticketing engineers about outages doesn’t work during the outage. That would be something worth making multi-region at a minimum.
I saw a quote from a high end AWS support engineer that said something like "submitting tickets for AWS problems is not working reliably: customers are advised to keep retrying until the ticket is submitted".
I worked at <large tech company everyone hates> and we had this exact architecture. The senior engineer (who went to Stanford and was proud of it) designed this system. I had long arguments with him about how this system wouldn't scale when we launched it, and used real production data to prove that it would happen. No one listened to me, it launched and imploded within a few weeks, and soon after I transferred off the team. The worst part is, that senior engineer was eventually promoted and that system was passed off to an entirely new team to battle with. That entire system was terribly designed, and I think you can guess why.
Show me your tables, and I won't usually need your flowchart; it'll be obvious." -- Fred Brooks, The Mythical Man Month (1975)
It astonished me that people can ever think this is a good idea (everything in a single json document) or that anyone who thought it was could ever get funding or even get through any basic customer due diligence.
One part of my work entails entering companies on their death bed and going through their software development and related investments. I see a lot of JSON-storage in the initially well funded ones. They cough up some crap on Firebase, get some tens of millions of dollars in venture funding, burn through, and never leave Firebase.
It's really, really hard to sell systems implemented with these sexylicious clown technologies. Like, extremely hard. Apparently no sane person with money wants to pay a non-trivial amount for a pile of locked in JSON and Python scripts, and I haven't managed to add any insane ones to my network yet.
The small companies without funding that topple over and end up in my way, more commonly they instead put some stuff on a VPS or two, and typically the market values them quite a bit higher.
Fashionable technology choices burn through a lot of investment money. Seems to me like maybe a sign that money has been a bit too cheap a bit too long.
The lock-in is very bad, especially in the auth and user management but migrating out of the JSON-storage isn't easy either. It also encourages bad patterns, like developing stuff straight into cloud functions rather than locally with version control.
Personally I prefer SQL-RDBMS-style data storage in part because it has these algebraic qualities that makes transitions between 'schema'-versions fairly robust and predictable. Extending and transforming JSON-storage is in my experience rather brittle, even if we ignore the hurdles and indirections around export and import in the clown solutions.
You can go with firebase for version N of your application when you have all relations between entities defined. If version N+1 redefines what your documents are, you're looking to write a migration script. That's not so different from SQL with all the joins. But there are people who can't design a data schema for neither a SQL database nor a document store.
Generally something like Postgres or MySQL would have been a better choice in these cases. You can migrate those, as well as handle growth through sharding or clustering, and more easily adapt to changing business or market requirements.
You'll need to recruit differently to build that way, though. Have someone that knows a bit of nginx and Linux, someone able to stitch together a bit of auth, things like that.
Languages with explicit types are also preferable, as a prospective buyer you'd want to have your people become somewhat efficient fast when they start working with the system. If obvious type constraints you kind of have a guarantee that IDE tooling will help with this, whereas Python, Ruby, JavaScript can be rather inscrutable at first glance.
Now, I have a financial interest in these things, it helps me if a system is well built and somewhat easy to evaluate, change and sell, so I have a bias. But in practice it seems that the basic setup of auth, storage and initial business logic takes very little time compared to the time it takes to flesh out the entire system needed to start making a profit, and since most (IT-)companies fail within three to five years it's probably a good bet to try and make the software you build be reusable and/or resellable.
It works great at a small scale. It's really convenient to have all the data at hand and be able to manipulate it directly in your programming language without having to go through SQL, which, no matter how comfortable you may get with it over years of experience and/or no matter how much library/ORM/etc. you throw at it, is always a foreign imposition into your programming language.
If you know beyond a shadow of a doubt that you will never leave "small scale", it's honestly not a terrible approach. It's also easy to define how to backup "the one file that is everything". You also ought to be confident that the worst case of the One File becoming corrupted is something you can deal with. (Although this is an often-overlooked issue in systems design anyhow.)
I've got some systems that have bits and pieces of this idea... but I'm really, really confident they'll never scale any bigger because for the systems in question it's simply impossible they ever would. I've got one that is, for instance, bounded on the set of wiki pages of a certain type that for it to grow into the 10,000s of pages where the approach would finally start to creak (from the "dozens" it has been in for the last several years and to all appearances will remain indefinitely) would require so much human effort to create those 10,000s of pages that I'd certainly have the budget to upgrade the approach anyhow as it would be negligible compared to the rest of the effort.
It also helps if this not something you're loading per HTTP request; in my case it's one-time on startup of a persistent service.
But you need to know you understand the relevant scales, because this is an immense trap if you don't do the math (it's not hard math, but it's math). Your prototypes work well and are easy to write and then are just total trash when they go to production, and presumably, if the engineer didn't do the math in the first place, it will emerge that they don't understand why the system is crashing in production either. Huge, huge trap. I've not quite seen this exact one with JSON files but I've definitely witnessed the "prototype that any experienced engineer could have absolutely guaranteed would not scale in about 5 minutes of examination".
Obviously with AI maybe those issues I have go away. But I really don’t like letting the AI modify tests without meticulously manually reviewing those changes, because in my experience the AI cares more about getting the tests passing than it does about ensuring semantic correctness. For as long as tests are manually maintained I will continue keeping them as few as necessary while maintaining what I view as an acceptable amount of coverage.