cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Heneveld <>
Subject Re: [DISCUSS] PaaS Enablement: Composite Application Blueprints (#576)
Date Thu, 10 Jan 2013 00:39:02 GMT

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) 

> 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.


View raw message