Calm uses application blueprints to model details of an entire application running on the cloud. Reading that definition answers what the overarching goal of Calm, but doesn’t get into the deeper question How does Calm model applications? Today we’re going to dive into exactly what and blueprint is, and how Calm models application with blueprints. First, we need a new, more tangible definition of a blueprint, one that explains what it truly is.
Blueprints are Application Recipes. These recipes encompass Application Architecture and Infrastructure choices, Provisioning & Deployment steps, Application Binaries, Command steps, Monitoring endpoints, Remediation steps, Licensing & Monetization, Policies. Every time a Blueprint is executed it gives rise to an Application.
Calm uses Services, Packages, Substrates, Deployments and Application Profiles as building blocks for a blueprint. Together they fully define applications. By encoding these into a blueprint, Calm can understand the application as a whole and properly automate the life cycle.
ServiceAn application is made up of multiple components (or services) working together. App architecture is composed of components of different types (compute, storage, network) and their connections and dependencies. Scaling-out a webserver from 1 to 10 VMs for load balancing doesn’t change that all these web servers are providing the same functionality for your application and thus captures them as a single service.
PackageInstructions for configuration and state and URI pointers to application binaries for the actual software needed. This captures the steps it takes to take a fresh VM and turn it into your web server. Calm uses SSH/Powershell/API calls natively and can also pull in Ansible/Puppet/Chef profiles.
SubstrateSubstrates are the infrastructure abstraction layer for Calm. Put simply, substrates translate service configuration (‘create 5 VMs’) into the correct API calls based on that configuration (‘deploy 2 on a AHV, 3 in AWS). Thus substrates represent the actual, physical (virtual) infrastructure in a blueprint. This abstraction is critical as Calm can quickly change where or how applications are deployed by simply changing the substrate (the package, dependencies, and other configurations follow without change).
ActionsActions are any task that you run against your application. Using the same format as packages, you can automate any process like backup, upgrade, new user creation, or clean-up and easily enforce an order of operations across services. An action is effectively a runbook to accomplish a particular task.
DeploymentDeployments are specialized tasks that contains the commands/scripts/configuration needed to setup the Services to run on the provisioned infrastructure (Substrate). These steps are run on each node of infrastructure to setup the node-specific software. Deployments are also used to scale services and track specific deployment policies, such as scheduling, placement, and load balancer specs.
Application ProfileAny useful blueprint needs Infrastructure for instantiation. A blueprint can specify the exact infrastructure needed (n AWS VM, m Nutanix VM), a predefined palette or can be completely left to user to specify at instantiation time (late binding). Infrastructure choices can be given in a blueprint with the help of Application Profiles.
ConclusionLet’s bring it all together with one last blueprint definition, combining the goal (to model details of an entire application) with the how (all the components we just covered):
No wonder we shorten it!
Want to learn more? Checkout the documentation for a detailed breakdown, explore the v3 API to see all the specs, and as always join us on the next.nutanix.com forums to continue the conversation!
©️ 2018 Nutanix, Inc. All rights reserved. Nutanix, the Nutanix logo and the other Nutanix products and features mentioned herein are registered trademarks or trademarks of Nutanix, Inc. in the United States and other countries. All other brand names mentioned herein are for identification purposes only and may be the trademarks of their respective holder(s).