Application Model: A document or API that describes a cloud application's configuration and requirements in a way that can be deployed and run.
Application models, delivery, and deployment tooling is a target-rich environment with many projects. Developers don't like application deployment and aren't good at it, but making developers more productive is always an important problem to solve. Complexifying this, there are many different models of how organizations work, whether they have separate disciplines, and which people have different responsibilities.
The result is that there's a huge diversity of a projects, no standard terminology, and no one project gets critical mass.
Projects that start as developer-tools often "grow" an application model as they move from build/test to production. CI/CD and application delivery projects are either coupled to an application model (Kubernetes) or grow their own to solve their needs. Control planes and runtimes also provide an application model because it's core to what they are doing - in this case it's not an abstraction, they providing a API for the configuration of their runtime.
Many projects are attempting to abstract over Kubernetes, either with non-Kubernetes portability in mind (OAM) or just to be a "better Kubernetes" (KNative). In enterprise, we see "better Kubernetes" all over the place. Late-majority organizations are adopting Kubernetes now but don't want their developers to engage with it - the next step they take is to write their own abstraction layer.
Overwhelmingly application model projects are focused on compute and the things compute needs. The dependencies of the application are either modeled as compute themselves, or not in scope of the model. This generally makes sense because application model projects grow out of other projects organically.
Application models that are focused on compute miss the "whole app". They can't include direct dependencies like databases and message queues. They can't include indirect dependencies like logging dashboards and authorization systems. Focusing only on compute means developers need to use multiple tools with different points-of-view. Using multiple tools means developers are responsible for the "glue" and composition of all of the systems they use.
Most projects in this space are either compute platforms, developer tools, or infrastructure tools, and they stay in their lane. Infrastructure tools (like Terraform) are positioned as "for ops" to manage cloud resources. As a result all of our developer tools and developer-centric platforms avoid building opinionated concepts - they have no point-of-view on infrastructure management, and no point-of-view on how developers and ops should work together. When enterprises try to build their own platforms, they want to address this need, but their resources, skills and time is limited - they bite off more than they can chew.
Many projects in this space are "close enough" to Kubernetes that they never achieve escape velocity. The biggest competitor is nothing at all - just using Kubernetes and Helm directly will always be an attractive option.
We wanted to build a project that empowers developers to do more than what they do today with production deployments. This means being both easier to learn by being closer to a developer's mental model and providing features that feel like magic. If you've used systems like this before you know that getting all of the configuration and glue right is a painful, iterative process. We want to take all of that away. Features like Recipes and Connections are close to a developer's heart and formalize what successful teams are already doing.
As we got further into the project we realized that we're really doing is creating opinionated concepts and workflows that support the needs of the whole organization. We're getting developers to buy into our concepts because of the expressive power and convenience, and then using the information we get to build tooling experiences that everyone needs and no one has.