Qovery, Porter, and FlightControl are at least a few examples

Kubernetes is kind of the intellectually honest, logical end point of this stuff.

Kubernetes is a powerful platform. It has become a standard language for building and operating cloud/on-prem infrastructures. It will be the end point for how infrastructure is orchestrated and configured.

However, Kubernetes is more a primitive for infrastructure rather than a tool to build automation workflows for software teams. Our focus is to complement teams that may or may not choose Kubernetes.

That's like saying hammers are a logical end point of trying to get carpentry work done.

Kubernetes is an incredibly useful tool, but it needs at least one layer of abstraction (possibly multiple) on top of it to make it useful for the typical company that isn't doing anything out of the ordinary.

I think of kube as the new de-facto OS, just like Linux back then. Of course it needs config to make it useful for your needs but I think it's really the platform to target for the next decade at least.

(I'm the cofounder of Coherence)

I consider the "best-in-breed" tools with this shape to break into the following categories:

"Infra Abstractions": DuploCloud, Massdriver, Stacktape "PaaS in your own cloud": Nullstone, Zeet, Quovery, Porter, Architect.io, FlightControl "SDLC Platform for Teams": Coherence (withcoherence.com) - the key difference here is in how CI/CD (incl integration tests) are handled, how development environments are configured alongside other environments, and how production is segregated from other environments.

This a somehow both a crowded space and an emerging one. But we believe that even with the diversity of choice that there are clear reasons that most teams will by (vs. build) their internal dev platform in the future: namely the cost to buy vs. to build/maintain, and the productivity from better tools.

We are from DuploCloud and hence the following note might be biased. The downside of a pure paas solution like porter, Quovery at al. is that they have a limited scope say kubernetes, pieplines and diagnostics. All of the lower layers of the Devops stack from IAM, networking, AWS services (including non containerized workloads like Lambda, EMR, Airflow etc), scores of compliance and security controls are left out of scope. Then one needs a expert Devops to write boat loads of TF. Our apporoch is of a E2E platform that should do all of what a human devops manually scripts. Thus fundamentally deliver self-service, labor reduction and compliance.

I built yet another similar platform with the goal to keep accounts fully isolated, while it started with preview environments only, we started handling some prod deployments too.

There are nice perks on this approach but the complexity (for us) is non-negligible.