Open Stack

Monty Taylor wrote:
> I'm actually less interested in this as a generic PaaS on top of
> Heat/OpenStack. That might be because I don't see DBaaS as a PaaS thing
> at all, and also because I don't really want to go down that rathole at
> the moment.
> 
> Databases are clearly something that people need for applications, and
> that are hard to administer properly. PaaS solutions are a thing that
> while useful to a set of people, does seem like a scope creep to me for
> the project, and one where a general framework provided by us seems
> premature.

I'd agree with that. Even if databases are way higher in the OSI stack,
I see databases as a basic infrastructure building block in the same way
as load balancers. In my view there would be three types of IaaS/PaaS users:

1. Pure players that only consume extremely raw (some would say "core")
resources: VMs, block storage, basic networking -- and build everything
else themselves on top of that

2. Application builders which benefit from using building blocks for
almost-always-used functions: DNS, load balancing, databases, message
queues...

3. One-stop deployers who just push a repo and the PaaS platform handles
deployment/scaling and the details of their infrastructure for them --
Google AppEngine or Heroku style consumers

(1) is clear IaaS, (3) is clear PaaS. (2) is somewhere in between. Let's
call it IaaS++. You still care about the details of your infrastructure
and which raw resources you consume, but you enjoy a number of
higher-level services. You could build those services yourself on top of
"core IaaS" services, but that's a pain to setup and maintain, so you
enjoy the convenience of IaaS++ services.

You could argue that the only things in "core IaaS" are VMs, block
storage and raw networking, since you can build everything else on top
of that. You could argue that object storage is actually part of IaaS++.

At this point, I think considering IaaS++ projects as part of the
OpenStack integrated release is completely valid, since we already
started to enter that space. I would certainly be more hesitant with
projects that belong in (3).

Regards,

-- 
Thierry Carrez (ttx)