Phoenix (web framework for elixir) famously has the meme out there that “Phoenix is not your application”, with various articles etc explaining that the web interface should be a layer on top of the application code. They made a big deal of adding Contexts [1] as part of the scaffold which isn’t much more than a directory to put core app code.
A big part of the difference has to be that if you have a small number of developers (esp. n=1) and you can deploy everything at once, then those layers just get in the way of fast change. It seems Amazon were optimising for the ability to distribute data because they had big volume, and hide its form so they could change it without having to change lots of applications.
Of course, there’s some cargo culting around services where people jump to that architecture before they need it, but for most apps YAGNI. it’s cool that their architecture was driven by clear needs “just in time” to allow them to continue to scale
If you’re among those others, I’d be really interested to hear a critique of the article. It seemed pretty convincing to me, as well as constructive by suggesting that green investment is the right path forward
I used to work in an overseas office and quickly learned the ping times to the other branches worldwide so got a “feel” for how long things should take. 10/10 would recommend
Interesting to note that cloud storage and realtime collaboration isn’t 100% tied to a browser-based interface though. Even though many existing apps work like that, there are desktop clients for a bunch of cloud-native SaaS (and even though some of those are Electron).