IT pros increasingly turn to Chef and Puppet for open source cloud automation and orchestration. But other options, such as TOSCA, are also worth exploring.
Deploying software isn't easy, and it's more complicated in the age of service-oriented architectures, web services, microservices and the cloud. Virtualization presents new challenges, with applications and servers in new roles. Basic software operations tools are transforming into automation and orchestration tools, and open source software leads the way especially Chef and Puppet.
The software tools used today to deploy applications derive from early tools that simplified deployment by allowing developers to build operations guidelines into the applications themselves. This concept, called DevOps, embraces the goal of accurate and speedy deployment, but the varying approaches to getting there quickly prove divisive.
The Chef and Puppet divide
The simplest way to automate deployment is through scripts. Deploying software manually means issuing commands using the operating system or cloud management system's tools, and scripts are a flexible way to write the commands as a file that can be quickly executed. Two popular open source automation tools are Chef and Puppet.
The Chef model is regarded as imperative or prescriptive since it is procedural it explicitly describes tips on how to deploy and connect cloud application components. Chef creates "recipes" and "cookbooks" which might be built within a programmer-friendly way. Each deployment step could be described independently, and bringing those independent recipes together generates a repeatable application deployment process. Since every operations step is usually described in a very recipe, there is nothing that is usually deployed manually that Chef can't automate.
That same programmer-friendly model can be a negative for many users. To them, the logical method to deploy a questionnaire is to describe inside a model the end-state from the deployment would resemble. The open source DevOps tool would then process the models to generate that state. This process, referred to as declarative or intent-based DevOps, could be the basis for Puppet, another popular tool.
If Chef is programmer-friendly, Puppet's origins lie with operations people, who will be more informed about describing what they already want than the detailed measures in getting there. Like a high-level programming language which enables programming simple, Puppet's models can simplify deployment descriptions. Furthermore, because an end-state approach might be used to describe any step up application lifecycle management (ALM), Puppet can naturally accommodate an extensive ALM function, which Puppet fans like.
The issues with Puppet is you can deploy that which could be modeled. As new challenges in deployment arise, the model-building process sets out to resemble imperative script development, and, actually, cloud evolution starts to bridge the divide. Chef and Puppet appear to be growing closer together, and many new DevOps tools are straddling the declarative/imperative line. However, the key candidates for first time deployment and configuration management all support a declarative model; none are purely imperative.
Options in cloud
The cloud can be forcing an evolution of deployment and configuration management tools. With cloud deployment working with two amounts of virtualization, any deployment and configuration automation grows more complicated, and DevOps is forced to confront both deployment and lifecycle management. This is reflected within a new cloud term: orchestration. This reflects the requirement for arranging complex steps in a unified composition.
Orchestration bridges the declarative and imperative models, but declarative orchestration looks like it's the favored approach; describing the present and desired state of something is usually a good solution to approach lifecycle management. Two new purely declarative alternatives CFEngine and Juju carry on and gain popularity alongside Chef and Puppet. These tools emphasize model-building and supply policy and library support. In addition, tools that support both declarative and imperative orchestration Ansible and SaltStack now challenge the polarized approach on the past.
The tools mentioned until now have evolved from DevOps and traditional deployment. What about something especially for the cloud? The international standards group Organization for your Advancement of Structured Information Standards launched a declarative-model approach called Topology and Orchestration Specification for Cloud Applications. TOSCA addresses both definition of end-state application deployment plus the specific modeling of virtual resources and pools. TOSCA also integrates management definitions to guide lifecycle automation.
Varieties of open source packages and also some commercial ones support TOSCA, even though it is really a relative newcomer to orchestration. Some popular cloud orchestration tools depend on TOSCA, including Cloudify, OpenStack Heat, Alien4Cloud, together with ARIA and OpenTOSCA, which can be both reference implementations on the specification. TOSCA can be being embraced for network functions virtualization and software-defined networking. Many would argue its success of these areas means it is the future of orchestration.
Orchestration could be the key to the way ahead for applications. It's a way of DevOps which could simultaneously manage agile applications and agile virtual resources. No matter what your way of orchestration, review and revise the important points as both applications and virtualization evolve.
Reference (http://searchcloudcomputing.techtarget.com/)
