I’ve been in the bay area, CA for a couple of weeks now (excluding my cheeky jaunt to vegas!) and even though i’m now on vacation, it’s been the perfect place to watch the OpenStack Havana Drama unfold; Mostly stemming from this catalyst;
Well (for me, anyway) especially this bit;
Too many times we see our customers exploring OpenShift or Cloud Foundry for a while, and then electing instead to use a combination of Heat for orchestration, Trove for the database, LBaaS for elasticity, then glue it all together with scripts and Python code and have a native and supported solution for provisioning their apps.
Hell no! Was my initial reaction, and while there has been a definite retraction from the tone of the whole post… I still think a hell no is where I stand on this.
And i’ll tell you why, but firstly;
- I like Openstack, as an IaaS. I like it’s modularity for networking and the innovation taking place to provide a rock-solid IaaS layer.
- It was a much needed alternative to VMWare for a lot of people and it’s growth into stability is something i’ve enjoyed watching (competition is never a bad thing right! 😉 ).
That said, here’s why I’ll take my PaaS served right now, with a sprinkling of CloudFoundry;
- People tying things together themselves with chunks of internally-written scripts/python (i’d argue even puppet/chef as we strive for more portability across public/private boundaries) is exactly the kind of production environment we want to move away from as an industry;
- Siloed to that particular company (or more likely, project/team.)
- Often badly maintained due to knowledge attrition.
.. and into the future;
- Defined, separated layers with nothing connecting them but an externally facing API was, in my mind, the very POINT of IaaS/PaaS/XaaS and their clear boundaries.
- These boundaries allow for portability.
- Between private IaaS providers and the PaaS/SaaS stack.
- Between public/private cloud-burt style scenarios.
- For complex HA setups requiring active/active service across multiple, underlying provider technologies.
- think ‘defence in depth’ for IaaS.
- This may sound far fetched, but actually is and has already been used to back SLA’s and protect against downtime without requiring different tooling in each location.
- I just don’t see how a 1:1 mapping of PaaS and IaaS inside OpenStack is a good thing for people trying to consume the cloud in a flexible and ‘unlocked’ mannor.
It could easily be argued that if we are only talking about private and not public IaaS consumption, i’d have less points to make above; Sure, but I guess it depends on if you really believe the future will be thousands of per-enterprise, siloed, private IaaS/PaaS installations, each with their own specifics.
As an aside, another concern I have with Openstack in general right now is the providers implementing OpenStack. Yes there is an OpenStack API, but it’s amazing how many variations on this there are (maybe i’ll do the maths some day);
- API versions
- Custom additions (i’m looking at you, Rackspace!)
- Full vs. Custom implementation of all/some OpenStack components.
Translate this to the future idea of PaaS and IaaS being offered within OpenStack, and i see conflicting requirements;
From an IaaS I’d want;
- Easy to move between/consume IaaS providers.
- Not all IaaS providers necessarily need the same API, but it would be nice if it was one per ‘type’ to make libraries/wrappers/Fog etc easier.
From a PaaS i’d want;
- Ease of use for Developers
- Abstracted service integration
- IaaS / PaaS providers may not be my best option for certain data storage
- I don’t want to be constrained to the development speed of a monolithic (P+I)aaS stack to test out new Key-Value-Store-X
- Above all, PORTABILITY
This seems directly against the above for IaaS…
Ie, I don’t mind having to abstract my PaaS installation/management from multiple IaaS API’s so that I can support multiple clouds,(Especially if my PaaS management/installation system can handle that for me!); however i DON’T want lots of potential differences in the presentation in my PaaS API causing issues for the ‘ease of use, just care about your code’ aspect for developers.
I’m not sure where this post stopped becoming a nice short piece and more of a ramble, but i’ll take this as a good place to stop. PaaS vendors are not going anywhere imho and marketing-through-bold-statements on the web is very much still alive 😉