We might have a different concept of "architecture", but for me it looks like all cloud apps share the very same one. A bunch of (hopefully) cpu bound workers connected to one huge, intransparent persistence service. Not that this is not a viable architecture, but there exist different ones.
You’re not looking beyond the most trivial services. Most complex applications are best designed and scaled through multiple services.
For example, how do you handle long running asynchronous processing, distributed pub sub, or services that have widely different performance and scaling characteristics?
If you haven’t seen this, it might be time to start looking for a more interesting job.
I did not say that you usually need multiple services for scaling. I just noticed that the end architecture looks roughly the same to me once you go into the cloud.
For a truly distributed system just look at a distributed hashtable. You can do it with a cloud provider, but it somehow contradicts the point of a DHT to control the nodes, does it not?
I don’t understand, you acknowledge that vanilla web apps wrapping CRUD aren’t the only architectures but are the only ones suited to cloud? The entire point of the post you’re responding to is that cloud makes many architectures easy, including that one. I can personally vouch for having done wildly different use cases on cloud involving analytics and data processing.
This is the only use case you see for what I described? Most data processing I saw works exactly like that, too: some compute cluster using a shared persistence layer (either object store or a network filesystem).
Edge computing, otoh, explicitly exists because not everything can be handled well in that way.
