<p>This section discusses the core concepts in CompanyName. Most of these concepts will be familiar, as CompanyName does not introduce any unnecessary abstractions. The picture below shows the main entities, and their relationships to each other. Each of these concepts are further defined below:</p> <p><img src="/images/concepts.png" alt="image"></p> <h5 id="applications">Applications</h5> <p>Applications are composed of multiple Components. Applications can be defined in a Catalog and can run in one or more Environments. While CompanyName has been designed for Microservices-style applications, it is easy to model and manage traditional 3-tier applications as well.</p> <h5 id="application-components">Application Components</h5> <p>A Component is simply part of an Application. A Component maps to Kubernetes workload API constructs. For example a stateless component will map to a Deployment and be exposed by a Service, whereas a stateful component will map to a StatefulSet and may be exposed by a headless Service. CompanyName&rsquo;s intuitive and powerful user interfaces provide step-by-step guidance to building Kubernetes applications, but can also support low-level YAML manipulation for expert users.</p> <h5 id="environments">Environments</h5> <p>An Environment contains runtime instances of one or more Applications. Environments can be created for different stages of a development pipeline, such as dev-test, staging, production or can be based on deployment characteristics such as regions.</p> <h5 id="clusters">Clusters</h5> <p>Clusters represent Kubernetes components and nodes. With CompanyName, you can deploy and operate Kubernetes clusters from scratch, or can discover and operate existing clusters created by other providers.</p> <h5 id="policies">Policies</h5> <p>Policies are used to govern resource usage, application constraints, and ensure scalable, consistent, and repeatable behaviors across multiple teams. In CompanyName declarative policies are used to manage all resources.</p> <h5 id="cloud-providers">Cloud Providers</h5> <p>Cloud Providers supply resources to run application containers. You can create one or more cloud providers, setup pools of hosts (Host Groups) from them, and then compose clusters from the Host Groups.</p> <p>CompanyName currently supports the following cloud providers:</p> <ul> <li> <p>Public Clouds</p> <ul> <li>Amazon Web Services (AWS)</li> <li>Microsoft Azure</li> <li>Google Compute Engine</li> <li>Oracle Cloud Services</li> </ul> </li> <li> <p>Private Clouds:</p> <ul> <li>VMware vSphere</li> <li>OpenStack</li> <li>Diamanti</li> </ul> </li> <li> <p>Direct Connect (any virtual or physical server)</p> </li> </ul> <p>CompanyName can securely manage both public and private clouds, without requiring any special network or firewall configuration.</p> <h5 id="host-groups">Host Groups</h5> <p>Host Groups are pools of container hosts with the same configuration, created in a Cloud Provider. For example, you can allocate pools of resources based on service tiers, application characteristics, or application lifecycle needs.</p> <h5 id="containers">Containers</h5> <p>Each Service runs in a Container. CompanyName uses the <a href="http://www.docker.io">Docker Engine</a> as its container technology. Since Docker is an open technology, you can always keep control of your images, and can also run them outside of CompanyName.</p> <h5 id="image-registries">Image Registries</h5> <p>An Image Registry stores Docker images, which are typically produced by a build system. CompanyName supports both public and private image registries. You can setup your build tools to generate images for each service, and then trigger CompanyName to deploy the images.</p>