Zero Configuration cloud deployment

Question

What are the options out there for "zero configuration" (meaning minimal configuration) deployment of code on an arbitrary cloud service?

I realize that there are thousands of cloud platforms, each supporting a particular set of languages, a particular set of packages, and sporting a particular workflow, often with proprietary set of commandline tools to make deployment less painful.

But what if I don't want to know anything about particular cloud platforms, and I want to write code that will be easy to deploy in a cloud for years to come?

Obviously the most concrete answer would be simply: build a virtual machine image with whatever you want and then run that on the cloud (this way is pretty much zero-configuration and we can expect a VM image I build today to still work on most VM hosts in 10 years).

So my question is: What is the next tier down from the VM image ideal? What are the most open and widely-accepted standards for encapsulating a complete description of an arbitrary software stack in machine-readable form such that I can throw my software stack at any generic cloud-like hosting service without thinking about any configuration specific to that hosting service?

Answer 1

If by 'cloud' you mean an IaaS (Infrastructure-as-a-Service provider), such as EC2 etc - as opposed to PaaS (Google App Engine, Heroku, etc), then the trend these days seems to be Infrastructure-as-Code, and DevOps. This is not exactly 'zero configuration'; it is more like configure once, and describe the configuration of your stack as whole in a DSL which can be used to build or rebuild your entire stack from nothing but a set of freshly booted VMs running on whatever cloud.

So you have a configuration management system, and a bunch of machine-readable 'recipes' that the configuration management system understands. It's usual for the recipes to be expressed in some sort of custom DSL, though there do exist systems where the language is actually XML.

Some well-known examples of such configuration management systems include:

1. Chef
2. Puppet

There are many others; but I've no experience with them (CFEngine, bcfg2 (uses XML))

These tools are idempotent. Which means, you can keep re-running the configuration as many times as you want, and only what needs to be done to meet the description specified by your recipes will be done. If you have specified certain files to be placed in certain directories with certain contents, then they will be created (or modified) only if they need to be. Packages will be installed only if they need to be, or if their version differs from what the recipes specify.

For example, in Chef, to specify that a user tomcat must exist, and that a certain version of Java must be installed, and that postfix should be running, and that a certain XML file must be available at a given location, you would have a recipe that looks like:

user "tomcat"

package "java" do
  version "1.6.0_u27"
end

directory "/etc/yourapp" do
  owner "tomcat"
end

package "postfix"
# Ensure that postfix is installed and running.
service "postfix" do
  action [:enable, :start]
end

tempate "/etc/yourapp/config.xml"
  source "config.xml.erb"   # This will be a template file that references variables
  variables(
    :db_server => '10.1.2.4' #just an example; there will be ways to automate this
  )
  mode "0755"
end

Chef for one, provides a bunch of pre-written recipes or 'cookbooks' that you simply download, include and use as part of your infrastructure. In Chef, you write your cookbooks based on what you want the servers to be - then you define roles, which specify what cookbooks will be applied to what class of servers that make up your stack. You simply assign roles to your instances, boot them, and watch the entire stack bring itself up.

I'd say that this is becoming the standard method of maintaining full-stack executable descriptions of infrastructure (doesn't have to be just cloud - I test on VMWare and/or VirtualBox but deploy to multiple public cloud vendors with the same recipes.)

The downside is you'll need to learn the DSL. And possibly, make significant changes to your workflow. These systems also have their individual pros/cons. But doing things this way is certainly the next tier down from maintaining a customized VM image, and in many ways more flexible. If for example, every cloud provider gives you an NTP server address to keep your instances in sync, then images will have to be changed depending on the provider. With Chef/Puppet, this can be automated and abstracted away neatly.

While VM Images are frozen copies of your desired 'configuration', they do not capture how each component - each instance in the stack - is to interact with one another. For example, an application server needs to know about the database server, it's address, various connection parameters - the database server needs to know about all the application servers that might want to connect to it (in a cloud context, the application servers may even grow or shrink in number with time). This is dynamic stuff that is very easy to automate with a system like Chef.

Answer 2

I think the answer to your question is Jelastic. To make your application stay in the cloud and let others to view it, you will bare minimum conform to http protocol and at least I think that way PHP win hands on there as a language. If that is true than there is only platform right now available in the market and it is Jelastic. Try yourself and let me know. Zero configs and vendor lock in free with superb web console, it is simply the best.I might sound like an evangelist but I am a satisfied customer of their stack(I use Java as programming language and have a startup) and really love their platform.

Surya

Answer 3

Zero-configuration is more likely a characteristic found in "Platform as a Service" than "Infrastructure as a Service". Maybe we should say "minimal-configuration" rather than "zero". PAAS hands you a semi-fixed architecture to live within and exposes some levers to configure things. With IAAS you do it all, maybe with the help of some tools.

I can speak of my experience with Google App Engine, where you develop your code locally, package it up with a descriptor file, and then deploy it to App Engine. You're not supposed to care about the underlying machines, nor care about how to scale up or down with traffic, etc. The platform takes care of this stuff for you, whether it does a good or bad job of it. The idea is that you only focus on your app. Though in reality, you must still understand a bit of the underlying architecture that you are handed in order to make good design decisions.

AppEngine supports Java, Python, and Go.

Heroku and Engine Yard are also PAAS, and started out with support for Ruby. Heroku supports Java, Python, and Node.js now too.

There is also Rackspace's Open Stack initiative, which is along the lines of defining an architecture you can live within, but let it be "portable" to various IAAS providers. Great concept, but I don't believe many have adopted it. http://www.openstack.org/software/

Answer 4

I believe the most straight forward answer to wards application longevity is abstraction.

Describe your applications requirements in abstract and simple terms, build or use an application framework that support this and carefully isolate the parts that are particular to your application needs.

In python this could translate to building something on Google App Engine. The core idea to take away from this is that you (or google) always have the ability to improve the underlying infrastructure without touching the application because it describes it's operation in terms which makes no assumptions about it. The cost if this approach is defining the what and the how of your application can be described in an abstract and portable manner, but if you get this right the only thing you should have to worry about is changes in the core language you use.

Now one of the big aspects that this question is missing out is Change is good. You should never be afraid to scrap an entire application stack. In fact technology changes so fast today that it is a requirement for staying ahead and relevant. For this sole reason it is very unlikely that you will even want to do write applications the same way for years to come.