In the cloud computing field, there are already a lot of open sourced or private automation tools and infrastructure solutions such as Ansible, Chef, Puppet, OpenStack, Kubernetes. There are many on-premise or public cloud providers available for your infrastructure and applications. People asked why we need more orchestration solutions ?
What is Infrastructure Orchestructure ?
It is sometimes called orchestrator for orchestrator. True, you can all think OpenStack, Kubernetes, AWS, GKE, VMWare are all kinds of orchestrators and meet your cloud native application deployment requirements to some degree.
The Infrastructure Orchestructure is system wide orchestrator and using OpenStack, Kubernetes, VMWare, AWS and so on as underlining orchestrators to deploy system wide business applications across multiple cloud providers, multiple regions and heterogeneous underling technologies.
Why do we need it ?
Business cloud native applications need to deploy over hybrid clouds, over different underlying technologies. It needs an end to end, full scale Infrastructure as Code solution. That is what the Infrastructure Orchestrator provided.
How to do end to end Orchestration ?
Two types of solution exit for this requirement. One is a private solution such as Terraform from HashiCorp and the other one is open sourced, OASIS TOSCA (Topology and Orchestration Specification for Cloud Applications) template based solution by companies like Cloudify. All those realized the so-called Infrastructure as Code method.
Want to know each one’s strengths and best suitable use cases, here is quick discussion on this topic. Personally, I prefer the Cloudify solution for its open source characteristics, full scale capacity and more applicable to the VNF field.
Now, let’s take a little bit explanation of Cloudify solution architecture as illustrated by following diagram:
Basically, you code your infrastructure as code in yaml TOSCA template. The Cloudify rendering engine will start from there to deploy your solution end to end crossing multiple cloud providers. It will also take care of the tasks such as healing, scale up and down your end to end cloud resources based on business requirements.
Demo
Let’s break the gap between theory and real use cases using a trivial demo. Here, we have a deployed, working OpenStack cloud and I will use Cloudify solution to deploy an application over it. In a more real deployment scenario, your application can deploy over hybrid cloud, different public cloud (AWS, GKE, VMWare . . .), mix of VM, Containers, Bare metal, SDN and so on, end to end, automatically using a TOSCA template. This saves the hassles of deploying business applications needed by individual cloud providers one by one and then connecting those segmented pieces of solution into one end to end solution manually. Here is the summary of demo steps:
- Log into deployed, working OpenStack cloud through Horizon GUI interface to exame its deployed resources. The existing resources include private and public networks, Neutron router to connect those two network segments, VM image. But, there is NO VM deployed already.
- Log into Cloudify GUI interface, load TOSCA OpenStack plugins. You can think of plugin as the abstraction layer between the TOSCA engine and underlying, deployed clouds. By this way, the same application can be deployed over any popular public or private cloud such as OpenStack, AWS, GKE and so on to achieve cloud agnostic.
- The next step is to load the network blueprint and deploy it. Blueprint is the modeling template for your system, network and application. You can open the blueprint with any editor to view its content.
- Cloudify displays the deployment model itself and creation progress in a graphic way.
- Go back to OpenStack Horizon interface to check the new OpenStack resources created from network TOSCA template: new network segments, router are created. You can compare the network topology after and before the TOSCA template is applied there. There is no VM yet.
- Load application blueprint after the success deployment of network blueprint. After that, the VM running your application and its corresponding floating IP address is successfully deployed.
- You can then use the floating IP to access your application.
Here, we used the TOSCA modeling template, successfully deployed our application over OpenStack cloud.
Knowledge, Experience and Learning 