Orchestration of Applications on the cloud
The cloud gives you the option of using as many resources as you want, essentially “endless” resources on demand, where you only pay for what you use. In a world where everything is dynamic and IT environments are constantly changing, this is becoming an ever-growing need.
In order to take advantage of the promise of the cloud, you need to be able to migrate to the cloud in a manner that isn’t too painful from a cost and resource perspective.
The majority of us have likely encountered the terms, DevOps and infrastructure automation in the past few years. Still today, infrastructure automation is mostly focused on setup and deployment of complex systems.
A typical deployment is usually comprised of a number of artifacts that include configuration management, monitoring configuration, custom scripts to deal with availability, SLAs, and integration with third-party components, not to mention networking. This leads to a high degree of complexity.
For instance, if you wish to deploy your application to the cloud, you would likely automate the steps of provisioning the cloud resources, installing the right components on top of these. This is crucial, not only when considering time and costs but also since over the course of the last few years, 80% of outages of mission-critical services are a result of human error on manual provisioning. As seen, just one hour of downtime for Amazon in January 2013 cost them $5 Million in revenue.
Cloudify- New Intelligence in Orchestration. Check it out.
When considering cloud automation and orchestration tools, most people use tools like CloudFormation, Chef or Puppet in mind. These tools do a great job at allocating infrastructure resources and configuring them. But in reality, when deploying and managing complete application stacks, there’s much more to it. You need things to be done in a certain order; there are dependencies to consider and information to share between your application tiers, and then there’s everything related to post-deployment – recovering from failures, scaling and continuously deploying your code, just to name a few.
Orchestration vs Automation
This is where the difference between cloud automation and cloud orchestration comes into play. Automation is mainly discussed in the context of tasks; whereas, orchestration on the other hand refers to the automation of processes and workflows. In short, orchestration automates your automation.. that being, the automated tasks in a specific order and across tiers and machines, particularly where there are diverse dependencies involved.
Essentially, after going through the steps of automating infrastructure provisioning, the startup of your components will then need to be orchestrated. Even for the simplest application that has a web server and database, after installing and configuring everything, you would first need to ensure the database is started and only then, the web-server. In addition, you would be required to propagate specific runtime information from the database to the web serves, such as the databases’ host and port. At large, this stage is what most automation processes focus on today.
Still at the most basic level, orchestration is an advanced version of automation which will help you set up the pieces related to your application, starting from the infrastructure, (VMs, networks, block storage volumes, security groups, etc.), to the platforms your applications run on, (database, web server, etc.) and all the way to the application modules and code. This entire setup is often referred to as topology.
TOSCA, (Topology and Orchestration Specification for Cloud Applications), an emerging standard for cloud orchestration which has been adopted by the likes of OpenStack for their cloud orchestration framework Heat, is a great reference in this regard. The role of an orchestration framework is to materialize a certain topology. More advanced orchestrators go beyond materializing the topology and adjust it to meet the current workloads and needs of the application.
What comes after deployment?
Ultimately, it’s not just a case of deploying your application to the cloud and then dismissing it. What then happens after that? For example, if your deployment or environment is under heavy loads, how can you maintain your SLAs for your clients? What if you have too many machines? How can you downsize your deployments without adversely affecting your customers and users in the process? Cloud orchestration tools are built to manage post-deployment through built-in management, logging and monitoring capabilities, as well as the built-in workflow for automating failover and auto-scaling processes.
Cloudify, is an example of the way Cloud Orchestration works. As an open source cloud orchestration framework, with Cloudify you are able to consolidate all the different artifacts into a single blueprint, which then becomes the “single- source of truth” for the entire stack. Cloudify then parses this blueprint and executes the definitions defined therein, through a single command to create a fully consistent environment. This includes the configuration, application binaries and all of its dependencies as well as post-deployment SLAs. This process provides a single-source for updating changes to the application blueprints and the SLAs, including updating monitoring and management metrics, high availability policies, failure detection policies and configuration changes.
As established, both monitoring and log gathering are an essential part of any running application and in turn an integral element of the orchestrated application topology. Since the orchestration process is topology aware, it is able to wire and configure monitoring for your application with ease. Undergoing through these processes without a global view of the topology would seemingly be time-consuming and error-prone. Furthermore, as the topology adjusts, you need to reconfigure and rewire your monitoring tools.
This single-source facilitates continuous delivery and deployment processes, from staging through to production. It consolidates tooling across teams, allowing the build process to be consolidated into a single build pipeline, that is agnostic of the technology stack and language runtime, through custom commands. These custom commands enable continuous interaction with a live system, in the post-deployment phase, for upgrades of new code to production.
In summary, when looking to deploy your applications to the cloud, it doesn’t stop with the simple automation of configuration and provisioning. In order to maintain your SLAs, increase agility and to reduce costs, you must be aware of what is going on with your app at all times. We’re not just talking about deployment automation, but cloud management as well, and thats where a good orchestrator comes into play.
The real long-term benefit of using a cloud orchestration tool is to manage post-deployment through built-in management, logging and monitoring capabilities, as well as the built-in workflows for automating failover and auto-scaling processes – which all eventually leads to faster rollouts and improved TCO.