System Provisioning in Cloud Computing: From Theory to Tooling (part 2)
With the right system configuration in place, it’s time to install the applications. So why not use the same tools we used for the OS and middleware? Do we need yet another set of tools?”
Lost VMs or Containers? Too Many Consoles? Too Slow GUI? Time to learn how to "Google" and manage your VMware and clouds in a fast and secure HTML5 App.
It depends. You can use the same set of tools for middleware to install some applications. The middleware appears like an application to the OS as well. The difference is whether your application is stable enough and whether you need to customize per node. The tools like Puppet can be good for stable applications that can be deployed the same way across all nodes. If your application is still a work in progress and you need flexibility to tweak it, you need more specialized application provisioning tools.
The big technical difference between application and middleware provisioning tools is that application tools push the application to the nodes and remotely change anything as needed. The process is procedural.
The middleware provisioning tools normally have agents on the nodes to pull the software based on the prescribed configuration files. The process is declarative.
Beyond the “push” and “pull” difference, the application provisioning tools can also manage the lifecycles of applications (sometimes called services) distributed on different nodes with a single line of command or code. Given the nature of remote command dispatching framework, the application provisioning tool can do almost anything. If there has to be a limitation, it’s your imagination.
So if you develop applications by yourself, you most likely need application provisioning tools.
Let’s see what tools are there.
- Func allows you to manage an arbitrary group of machines all at once.
- Func automatically distributes certificates to all “slave” machines. There’s almost nothing to configure.
- Func comes with a command line for sending remote commands and gathering data.
- There are lots of modules already provided for common tasks.
- Anyone can write their own modules using the simple Python module API.
- Everything that can be done with the command line can be done with the Python client API. The hack potential is unlimited.
- You’ll never have to use “expect” or other ugly hacks to automate your workflow.
- It’s really simple under the covers. Func works over XMLRPC and SSL.
- Since func uses certmaster, any program can use func certificates, latch on to them, and take advantage of secure master-to-slave communication.
- There are no databases or crazy stuff to install and configure. Again, certificate distribution is automatic too.
Capistrano is an open source tool for running scripts on multiple servers; its main use is deploying web applications. It automates the process of making a new version of an application available on one or more web servers, including supporting tasks such as changing databases.
Capistrano is written in the Ruby language and is distributed using the RubyGems distribution channel. It is an outgrowth of the Ruby on Rails web application framework, but has also been used to deploy web applications written using other frameworks, including ones written in PHP.
Capistrano is implemented primarily for use on the bash command line. Users of the Ruby on Rails framework may choose from many Capistrano recipes; e.g. to deploy current changes to the web application or roll back to the previous deployment state.(http://en.wikipedia.org/wiki/Capistrano)
ControlTier is a community driven, cross-platform software system used to coordinate application service management activities across multiple nodes and application tiers…
The Command Dispatcher is a core function of the ControlTier software that provides the mechanism to send commands over the network seamlessly to the correct Nodes. This facility is used whenever you run a command or script, via the command-line (ctl or ctl-exec) or via Jobcenter.
Fabric is a Python library and command-line tool for streamlining the use of SSH for application deployment or systems administration tasks.
It provides a basic suite of operations for executing local or remote shell commands (normally or via sudo) and uploading/downloading files, as well as auxiliary functionality such as prompting the running user for input, or aborting execution.
Typical use involves creating a Python module containing one or more functions, then executing them via the fab command-line tool.
Func allows for running commands on remote systems in a secure way, like SSH, but offers several improvements.
What’s Different in Cloud Computing?
If you look at the varieties of software at different levels of the stack, you will find the lower the stack the fewer number of choices. When you move up to middleware, you will have more choices. At the application layer, the growth of possibilities gets exponential.
If we draw a diagram here, it’s then like an inverted pyramid shown in following diagram.
Installing an OS or Cloning from template?
With the use of virtualization in cloud computing, the demand for the OS provisioning tools will be much less than before. For one thing, OS plays a less important role for applications. Most of the time it doesn’t matter what OS is there as long as there is one. It therefore makes it possible to consolidate the OSes to several standardized flavors.
On the other side, virtual machines are really just a bunch of files. You can save the standardized OSes as templates or machine images in Amazon terms. When you provision a new machine, you include the OS as well. There is not much need to install it by yourself.
Still, service providers may see many different types of standard OSes even though each user just uses a handful. The service providers therefore still need to use OS provisioning tools to accommodate all the different requirements of their customers.
What about the extra storage space? Good question. Overall the portion of OS images is relatively small and manageable for the service providers who can cross leverage them for different users. Also modern storage de-duplication software has significantly reduced actual storage use, especially when the OSes are mostly the same (for example, Linux OSes of different flavors and different versions).
When it comes to the format of virtual machine template, you want to follow the OVF spec which is a DMTF standard supported by major players.
How About Middleware?
When it comes to middleware, things can get tricky. There are definitely more combinations than with operating systems. It may or may not be a good idea to pre-install the middleware inside a machine template.
The deciding factor is really how much you use the particular middleware. More often than not, you have a pre-defined set of middleware for a particular purpose – for example, building Java-based enterprise Web applications. You can install all the middleware components in a virtual machine image. It’s not only easier to deploy, it can also test as the gold image to standardize within an organization. It also saves time to maintain, patch, and upgrade the related middleware to save costs and improve system security.
There are certain cases in which you have a very specific combination of middleware. Given the rarity of usage, you may either use configuration tools or install it manually. You decide by whichever is more convenient. When you do something just once, you probably won’t bother with learning tools like Puppet. But if you are already familiar with one of the tools, why not use it?
Applications have the most varieties in terms of numbers and functionalities. In reality, you may not want to create a virtual machine image for each application most of the time. That’s especially true when you are in the process of developing applications – you don’t have a stable application to build a virtual machine image yet.
Can you wait for the stable release of the application? In theory, it’s possible. But in reality, it’s mostly not an option. You have to deploy it and test it in the staging environment continuously upon daily build or even every check-in.
To facilitate this continuous integration and deployment, you would like to use some automation framework as I mentioned earlier. Besides the application provisioning, you can also automate the testing with the same framework.
Life could really be this easy? Yes. That is the benefit of using a framework. However, no pain no gain. The pain is to set up the framework and write/test the commands. Once you set up the process, you cannot easily change the procedure of installation. This is not an option for most developments especially in initial stages, therefore you have to maintain that as well.
As I mentioned in my previous blog on cloud application architecture, you want to design your applications to be as stateless as possible so that you can standardize the application for massive deployment. If that is the case, you can build a virtual machine with your application installed on the fly. If you choose this approach, you should incorporate the building of a virtual machine as part of your release process, and deploy that virtual machine instead of pushing applications to virtual machines. Many tools like VMware Studio can assist you to do that.
System provisioning in cloud computing is an important aspect of system architecture, application design and operation. As virtualization gets more and more popular as the enabling technology for cloud computing, we will see more use of virtual machine images/templates for system provisioning, including operating systems and middleware. The standardized templates provide not only operational efficiency but also high quality, pre-qualified software stacks for building cloud applications.
Application provisioning frameworks will still play an important role in system provisioning and other activities such as lifecycle management, automated testing, and more. It’s not only a tool for system operation, but also an essential tool for continuous system integration.