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
