One of the main challenges when working on any automation project is writing the automation templates. Each cloud provider has its own template language, which means that you can’t reuse anything already written by other frameworks. This makes many automation projects substantially longer than they would have been otherwise.

This blog piece explores how an ‘automation-first’ approach addresses this challenge by allowing the reuse of existing artifacts from different frameworks—substantially speeding up the time it takes to achieve end-to-end automation. It also discusses how Cloudify handles this approach using TOSCA.

What Is An Automation-First Approach?

Automating your infrastructure in a cloud environment is a challenge that can be solved using your cloud provider’s template language for deploying services like network components, virtual machines, load balancers, functions, etc. Amazon has its own template framework called AWS CloudFormation; Google Cloud created Cloud Deployment Manager; and Microsoft Azure offers Resource Manager templates.

Each of these options has its own syntax for provisioning resources programmatically. This complicates things a bit when trying to run an infrastructure on multiple cloud providers, as you would have to write separate templates for each service running. The question is: how can this can be avoided—and how can you provision all of your resources without depending on the cloud provider? The answer? Topology and Orchestration Specification for Cloud Applications (TOSCA).

Topology And Orchestration Specification For Cloud Applications (TOSCA)

TOSCA is an open-source language that can be used to describe cloud computing platform services’ relationships and dependencies. With TOSCA, cloud computing services and components can be documented and described in order to provide insights into how these components are organized. This allows you to have a consistent way to manage your cloud applications and services, which become portable and deployable across different cloud platforms.

To describe cloud services, TOSCA uses “templates” and “plans.” Cloud services are defined with templates, and plans are used to define how cloud services are started, stopped, and managed. The relationships between many different technologies (services, endpoints, containers, virtual machines) can be described with TOSCA, which allows faster and more scalable application deployments.

Because of TOSCA’s high extensibility, adding vendor or domain specific mechanisms for specific use cases is really easy. Standardizing cloud services is easier with TOSCA because it can be used to create a service that can map infrastractures in cloud-based environments.

Introducing Cloudify

Cloudify follows the automation-first approach by leveraging TOSCA’s language extensibility characteristic. TOSCA is used as the interoperability layer and a set of integration plugins. That way, each framework is exposed as a set of node-types and interfaces that can be referenced later. In this way, Cloudify can call different templates from a wide range of automation frameworks and glue them together under a common automation scheme. Cloudify with TOSCA focuses on an automation-first approach to enable easy deployment of resources across multiple cloud platforms. Cloudify DSL is based on TOSCA’s YAML Simple Profile and enables writing blueprints for easy deployment of cloud services.

Automation-First Best Practices

This section outlines some of the best practices that should be followed when defining TOSCA-based blueprints:

• The unit values recognized by TOSCA Simple Profile for size-type units are based on a subset of those defined by GNU (a non-normative reference to this specification). TOSCA treats these unit values as case-insensitive (e.g., a value of ‘kB,’ ‘KB,’ or ‘kb’ would be equivalent), but it is considered a best practice to use the case of these units as prescribed by GNU.
• Some cloud providers may not support byte-level granularity for storage size allocations. In those cases, these values could be treated as desired sizes, and actual allocations would be based upon individual provider capabilities.
• Do not use transparent user names (IDs) or passwords when provisioning your resources.
• The network modeling can reside in the same service template file, but the best practice should be placing it in a separate self-contained network template file.When designing Node Types in TOSCA, you shouldn’t export two capabilities of the same type if they truly offer different functionalities (i.e., different capabilities) which should be distinguished using different Capability Type definitions.

Summary

Automation is very important when building your applications and services, and with a wide range of technologies and cloud vendors, it is helpful to provision applications and resources in a unified way. An automation-first approach using TOSCA can help with faster delivery, as well as with unifying your infrastructure.

The original version of this piece was first published on the Cloudify blog.