Reactive and evented models are much harder to reason about and design properly. When you're just doing things sequentially in a fabric script it is much easier to make sense of what is going on. As soon as you make things reactive and evented to support dynamic cloud topologies you are basically on another planet and none of the old rules apply. This is why it is hard to design "cloud native" systems. I don't think it is the lack of interfaces and standards but the model being inherently non-sequential. In many cases it is also non-transactional and barely eventually consistent.
> Let’s go back to first principles. To describe Cloud Native in one word, we'd choose "automatable".
Most existing applications are not.<p>This is doubly true for Enterprise Customers. Most of them are cloud minded without understanding their applications which aren't cloud conditioned.
I understand the benefit of designing software components (and stacks) to run and autoscale on Kubernetes - I actually did that with my open source project SocketCluster. See <a href="https://github.com/SocketCluster/socketcluster/blob/master/scc-guide.md" rel="nofollow">https://github.com/SocketCluster/socketcluster/blob/master/s...</a><p>I think that standardisation should happen at the level of the stack/component (not at the application level). Most application developers don't know enough about specific components like app servers, databases, message queues, in-memory data stores... to be able to effectively configure them to run and scale on K8s (it's difficult and requires deep knowledge of each component).<p>I think it should be the responsibility of open source project owners to standardize their components to run and autoscale on K8s. It's not practical to delegate this responsibility to application developers (whose primary focus is business logic).<p>Application developers should be able to use an OSS stack/component at scale on K8s without having to understand the details of how that stack/component scales itself.<p>So for example, if I wanted to run Redis as a cluster on K8s, I should be able to just upload some .yaml files (provided in the Redis repo) and it should all just work - Then I can start storing data inside Redis cluster straight away (without having to understand how the sharding works behind the scenes).<p>Rancher has the concept of a 'Catalog' which pretty much embodies this idea.
Would be cool if this were a thing nowadays:<p><a href="https://en.wikipedia.org/wiki/Single_system_image" rel="nofollow">https://en.wikipedia.org/wiki/Single_system_image</a>