After reading up a bit more on AWS CloudFormation [1] and OpenStack's work-alike Heat [2], they actually differ quite a bit from VMware vApps. I thought it might be worth talking about some of the differences.
CloudFormation is a general purpose provisioning system for AWS services, but under the hood, it's essentially a workflow engine (similar to vCenter Orchestrator or HP Operations Orchestrator). The problem CloudFormation is solving is runbook automation, where you might have a 20 step process for deploying an app into AWS that you want to completely automate. It competes with tools like Puppet and Chef (although they can work together). The templates used by CloudFormation are less config files and more like scripts or XSLT. They include variables, user inputs, outputs, flow control, and a small standard library of functions. [3] Templates require testing and debugging. It's possible to have run-time bugs related to a wait condition that cause a deadlock and trigger a rollback. When you execute a CloudFormation template, the resulting set of provisioned resources is called a "stack". A stack could be a multi-tier app with several VMs, but it could also be 3 empty VPCs, an SNS queue, and an IAM user. If we follow a similar convention, a stack would not necessarily map onto a project. A stack might include VMs in multiple projects. Or no VMs at all. To extend the workflow coordination and configuration capabilities into the guest OS, CloudFormation provides a set of helper scripts that can fill a similar roll as cloud-init, creating files and running commands with content and arguments dynamically generated from the template. [4] It helped me to look at some real templates to understand everything that CloudFormation was doing. Here are a couple examples... (the first provisions an Active Directory server, the second creates an instance of OpenShift) https://s3.amazonaws.com/cloudformation-templates-us-east-1/Windows_Single_Server_Active_Directory.template https://github.com/openstack/heat/blob/master/templates/OpenShift.template By contrast, vApps are much simpler. They are effectively just a collection of one or more VMs, their associated network settings and some limited additional metadata. You can start and stop a vApp. You can import or export a vApp as an OVF file if you wanted to move it from one cloud to another. A vApp could roughly map to a project. To me, it sounds like we need vApps, with some limited features of CloudFormation. Just enough to enable a user experience of clicking a "Launch Blueprint" button and having everything magically provisioned, like AWS does here: http://aws.amazon.com/cloudformation/aws-cloudformation-templates/ Thoughts? - Chris [1]: http://aws.amazon.com/cloudformation/faqs/ [2]: https://github.com/openstack/heat [3]: http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-anatomy.html [4]: http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-helper-scripts-reference.html On Wed, Jan 16, 2013 at 1:59 PM, Mohammad Nour El-Din < nour.moham...@gmail.com> wrote: > Hi > > Sent from my Samsung Galaxy S3 > Apologies for any typos > On Jan 16, 2013 6:01 PM, "Shane Witbeck" <sh...@digitalsanctum.com> wrote: > > > > +1 for YAML. After all, YAML is a superset of JSON [1] which is the > primary objective of the 1.2 spec. > > > > Here are my pros and cons: > > > > Pros: > > - relational anchors and aliases (potential here for less verbosity > through reuse) > > - more readable > > - comments > > - projects which I respect, choose yaml over json for similar types of > configuration [2], [3] > > > > Cons: > > - more complex to parse, less mature libraries compared to json > > > > All this being said, I would advocate that more initial focus should be > on the "model" and how it solves the problem of defining the "blueprint". > Serialization format discussion should be secondary and around whatever > best fits the model, not the other way around. > > +1 on that > > > > > > > [1] http://yaml.org/spec/1.2/spec.html#id2759572 > > [2] > http://www.elasticsearch.org/guide/reference/setup/configuration.html > > [3] > https://github.com/cloudfoundry/bosh-release/blob/master/micro/aws.yml > > > > > > -- > > Shane Witbeck > > > > > > On Thursday, January 10, 2013 at 1:20 PM, Kelcey Damage (BT) wrote: > > > > > +1 for YAML, I find JSON good for when I never look at the data and > simply pass to a Python dictionary, however for interaction I am going to > back the YAML choice. > > > > > > KELCEY DAMAGE > > > Infrastructure Systems Architect > > > www.backbonetechnology.com (http://www.backbonetechnology.com) > > > > ------------------------------------------------------------------------- > > > kel...@backbonetechnology.com (mailto:kel...@backbonetechnology.com) > > > > > > address: 55 East 7th Ave, Vancouver, BC, V5T 1M4 > > > tel: +1 604 713 8560 ext:114 > > > fax: +1 604 605 0964 > > > skype: kelcey.damage > > > > > > > > > > > > > -----Original Message----- > > > > From: Alex Heneveld [mailto:alex.henev...@cloudsoftcorp.com] > > > > Sent: Wednesday, January 09, 2013 4:39 PM > > > > To: cloudstack-dev@incubator.apache.org (mailto: > cloudstack-dev@incubator.apache.org) > > > > Cc: Min Chen > > > > Subject: Re: [DISCUSS] PaaS Enablement: Composite Application > Blueprints > > > > (#576) > > > > > > > > > > > > Hi Min, Jie, > > > > > > > > Min, nice questions. I've given my answers in-line. > > > > > > > > Jie, my answers also respond to some of your points, re TOSCA and > > > > YAML/JSON. > > > > > > > > > > > > On 08/01/2013 17:50, Min Chen wrote: > > > > > +1 on this feature to extend CloudStack from pure IaaS to PaaS or > SaaS > > > > > area. Some questions in my mind: > > > > > > > > > > 1) Does your proposed blueprint only contain functional component > > > > > description or contain both functional and deployment aspects? For > > > > > example, for a 3-tier app containing three functional components > like > > > > > web tier, server, and DB, users can define different deployment > models > > > > > for the same functional components, like small deployment > (co-hosting > > > > > all components on one VM), or medium or large deployment. > > > > > > > > > > > > > Great use case. Introduces a _lot_ of complexity: > > > > > > > > (1) allow parameters to be passed to the blueprint (e.g. "size") > > > > (2) separate the components that are to be created from the > customizations > > > > performed > > > > (so you could define customizations for webserver, appserver, and > data, > > > > then either > > > > apply the customizations either to a single VM (small), distinct VM's > > > > (medium), > > > > or distinct VM groups (large)) > > > > (3) allow blueprints to refer to other blueprints > > > > (so the "webserver customization" lives as its own reusable module) > > > > (4) allow conditional branching based on parameters > > > > (e.g. if user selects "size=small" then run all customisations on > single VM) > > > > > > > > I'd be inclined to DEFER them as features, until phase 2 or 3, but we > should > > > > consider how the description might support them as I'd like to see > some of > > > > this functionality eventually. > > > > > > > > What do other people think? This is obvious functionality to want, > what's the > > > > right way to support it but without making the description language > > > > complicated? > > > > > > > > (BTW one of the reasons I think TOSCA could be a good choice is that > it has > > > > considered many of these. You can define properties (1 above), > arbitrary > > > > nodes (2), and references to other definitions (3). It also has the > concepts of > > > > requirements / capabilities, relationships, policies, and plans -- > some of which > > > > could be used to support (4) > > > > eventually.) > > > > > > > > > 2) Have you thought of creating Service offerings from your defined > > > > > blueprints? This may allow CloudStack to provide some SaaS > functionalities. > > > > > > > > > > > > > I like this idea, although it might break assumptions made elsewhere > about > > > > service offerings so we should look at it carefully. > > > > > > > > > 3) As for blueprint description language, easy-to-read and > > > > > easy-to-edit by human being should be necessary if we don't provide > > > > > any visual GUI tools to create/edit a blueprint. I have seen some > JSON > > > > > format before in BMC Cloud LifeCycle product 2.0. > > > > > > > > > > > > > Wow JSON seems popular so far. And yet YAML is more concise and > > > > expressive. Designed to be easy for people to read and write > configuration > > > > just like this. Whereas JSON is designed for serializing objects, in > a way that > > > > isn't too hard for people. YAML seems the right language for this > purpose to > > > > me -- and my experience has been that it is easier to read and to > write, > > > > without the litter of curly braces and quotes. > > > > > > > > But I don't want to be a language bigot! I can go with JSON if that's > what > > > > people want. :) > > > > > > > > > 4) For a multi-tier application, blueprint should not only describe > > > > > different components, but also connections among those components, > > > > > like open port, LB and FW rules among them. I assume that your > > > > > blueprint is also taking that into consideration, and your backend > > > > > orchestration layer can provide enough flexibility to provision any > > > > > such app, seems not an easy task to me since I am new to CS. > > > > > > > > > > > > > Yeah, this is where it gets interesting. A common trick I've seen is > to use > > > > hostnames for a lot of the connection configuration, and have a few > hard- > > > > coded patterns in there (e.g. for groups, load-balancers). But that > only gets > > > > you so far, and then you hit a wall (or spin up a different > orchestrator). > > > > > > > > Using requirements/capabilities and typed relationships gives a much > more an > > > > elegant solution. (Not necessarily TOSCA, but these concepts are well > > > > developed there!) > > > > > > > > In any case let's make sure the use cases include interesting > situations like > > > > this, and we can compare approaches. This absolutely DOES need to be > in > > > > phase 1 I think. > > > > > > > > > 5) From a normal user perspective, I would really love to see a GUI > > > > > tool developed around this to allow user to visually create/edit a > > > > > multi-tier app blueprint instead of using a TextEditor. > > > > > > > > > > > > > Nice to hear. Me too. The description, API, and backend come first, > with an > > > > initial set of features, but I'd love to see the GUI in phase 2. > > > > > > > > > Thanks > > > > > -min > > > > > > > > > > > > > Keep it coming please. > > > > > > > > --Alex > > >
