Cloud Resource Provisioning Methodology with Cloudify

Shay Naeh
5 min readJan 17, 2021

Introduction

TOSCA, Have you heard this acronym?

TOSCA, Topology and Orchestration Specification for Cloud Applications,was born long-time ago and nowadays it’s value is amplified by the necessity to manage multi-cloud environments.

What if I tell you that there is a tool that abstracts cloud resources and by utilizing the same DSL (domain specific language) you can provision and manage a resource’s life-cycle on different clouds in a homogeneous way.

WOW, that’s great and it is almost true. By utilizing a TOSCA-based orchestrator like Cloudify, one can provision compute, network and storage resources on different clouds in a similar way. Here is a simple example to provision a VM on Azure and AWS.

You can see that only the node type changes but the rest is basically the same.

This is an excellent solution for multi-cloud management, BUT not all clouds are born the same. Each cloud has its unique services and add-ons on top of the basic cloud services. This requires special treatment and the way to abstract it is to utilize cloud templates like Azure ARM templates or AWS CloudFormation templates.

Provisioning Common Cloud Resources

Utilizing TOSCA Common cloud resources like networks and compute and especially Kubernetes resources are provisioned the same on multiple-clouds.

We saw above an example for a VM provisioning. Let’s look now at network resources.

Here is an example how to provision a virtual network on Azure and AWS

Kubernetes resources look the same as well. Below is an example to provision resources on Kubernetes.

Using Templates

When you need to provision special resources or you already used cloud templates like Azure ARM and AWS CloudFormation templates, you can do it with Cloudify.

Cloudify, as an orchestrator of orchestrators, utilizes resource templates. For example, you can use an Azure ARM template almost to do anything including vWAN resources. Cloudify can update dynamic run time attributes in templates and “push” higher level parameters to cloud templates. This is an example of doing it. Below is an example of an Azure template and how it is being defined in the TOSCA blueprint.

The TOSCA blueprint create an Azure deployment of a Cosmos DB and it does it by using an ARM template (see template_file: cosmos_db.json)

The Cosmos DB template file is shown here

Templates files can define any resource type, so if you already created those templates, Cloudify can utilize them and build an orchestration layer on top of those templates. So if you need to add another cloud, let’s say AWS you can have Cloudify using AZure ARM templates and AWS TOSCA nodes or vice versa.

Basically there are templates for any kind of resource, but there could be some resource like objects that do not have templates.

Objects that have no Templates

There are some objects that are not pure resources but rather artifact types like Git Repos or process types like pipelines. For these resources that do not have templates, Cloudify provides an API based mapping or a serverless Lambda function that provides the maximum agility and flexibility.

One can define a TOSCA node template that invokes a Lambda function. When the serverless Lambda function is triggered you can define pre-processing tasks, API calls, and post-processing tasks.

Let’s look at an example on how to do it on AWS.

The process is divided into two steps, in the first one you define and configure the Lambda function and in the second one you invoke it.

First step, Lambda definition and configuration:

Second step, Lambda function invocation

The actual TOSCA nodes that utilize the above data types are shown below

Summary

Cloudify is a multi-cloud orchestrator of orchestrators. Cloudify is using TOSCA as its base DSL (domain specific language) and it abstracts cloud resources, aka you can define common cloud resources on different clouds the same way utilizing TOSCA. Basically there are three steps for creating cloud resources, starting from the most abstracted one to the more specific one.

  1. Use TOSCA to provision common cloud resources on multiple clouds. Define resources once and just change the TOSCA type to provision these common resources on different clouds.
  2. For cloud specific resources like AWS SQS, SNS or Azure vWAN use cloud templates like Azure ARM templates or AWS CloudFormation templates.
  3. For objects or resources that do not have templates like “processes” use a Lambda function to map it to a generic TOSCA type. The Lambda function provides flexibility and agility to define pre-processing, API calls and post-processing capabilities for maximum flexibility.

--

--