http://successfulworkplace.com/2013/04/27/cloud-makes-anyone-and-everyone-a-robber-baron/

The idea that the web will follow the path of previous technology breakthroughs is very interesting. I’ve watched at least thirty years of technology move through cycles of contextual and composable and why should we think we’re done now?

http:www.enterpriseweb.com – composable and contextual

Happy to discuss.
Dave

I’m not sure I get this article. The listing of 4GL players is just odd – not sure how Heroku can be compared with MS Access. Sounds like an old C or binary programmer puffing their chest about these new fangled languages that don’t require you to manage memory – so you can’t possibly be a REAL developer! ;)

1. Components must be elementary enough to not matter to my application
2. Components must be flexible enough so I don’t have to modify them
3. Connections must be trivially simple

Today’s crop of PaaS has a number of challenges in that regard. First, they are in the business to provide other people’s “contexts”, so to speak: JEE, PHP, MySQL, MongoDB, etc. But even beyond that, composability is limited by a number of factors, such as the specific versions of languages/frameworks/middleware/etc. on offer (“sorry, we don’t yet support PHP 5.4″), architectural restrictions (“must have at least one app container”), development and operational processes supported, and, of course, by rather minimal support for business requirements.

Amazon, being off-premise, certainly has its own set of challenges and isn’t quite as trivial to wire up as Unix pipes in a shell, but it dwarfs PaaS offerings when it comes to being flexible and elementary. True, there is value in being contextual as there is in being composable. But the question is: can a composable system minimize the added value of a contextual system? And, if yes, how close is Amazon to getting there?

I believe the law as written has one fundamental flaw though that makes it fall apart; cost. People don’t “want what they want” as the law proscribes, but rather, they live with what they can afford. Cost is the ultimate driver in determining the set of features that a business user will implement.

For most 4GL style PaaS, the actual numbers are closer to 60% visual tools, 39% coding required, and 1% simply can’t do.

The art of a successful code-less PaaS is to get to closer 99% visual tools, 1% coding or can’t do.

The key thing here is that the visual tools cut deployment times and cost so much (let’s say 90%), that the business user will always want to forego the small percentage of things they can’t have for whatever reason.

And this is then is the fundamental misnomer of Dietzler’s Law: Do you want 95% at a 90% time and cost reduction, or 100% for 100% of the price? Are you willing to forego 5% of your wish list for a 90% reduction in cost?

PaaS customers are emphatically saying “yes”.

The ultimate measure IMO is 1)How fast can you deploy a given or desired application blue-print, the second measure is to measure the degree of diversity i.e. how many kind of application blue-prints can you support into your platform.

You’ll find that CloudFoundry and other opensource platform comes pretty high on that list but would still require changes to the core codebase to introduce new stacks.

This is where it would makes most sense to marry the concepts from DevOps into the PaaS world. By that i mean that the ability to compose the application stack and define new blue-print would be a first class citizen feature in the platform and not a hack.

A DSL that would enable to define and extend the application stack leads to a higher degree of composability by the measures that i outlined above.

As Krishnan pointed out new generation PaaS framework such as Cloudify and Brooklyn fits into that second category. For more details on this approach see one of my recent posts: Putting DevOps and PaaS together: http://natishalom.typepad.com/nati_shaloms_blog/2012/08/putting-devops-and-paas-together-with-cloudify.html

My desire is a world not of developer centric architectures but a join of data and user centric architectures, where usability, usefulness, trust and collaboration are the watch words.

Simply put; I want my Apps to use my data, not their data.

The current world of Apps does some clever things but I find my self having to mold / recreate / copy / re-enter my data to meet the various Apps needs.

On the surface it looks like a composable approach will make the delivery of my user/data centric world easier to deliver. (I suspect as in all life a hybrid approach will be the most effective) The problem is that making the world I want will be harder for the developer than maintaining their Developer Centric view. It will take thinking architecture from the data and users perspective, rather than an architecture perspective. Architects in the real world get that subtle point, the relatively immature world of Systems Architecture has yet to grok the point.

My desire is that Apple gets it’s mojo back and takes us to the next level of Useability and Usefullness. Frankly I don’t mind if a new start up called Pear makes the shift. I will very quickly become a Pear bigot! Because at the end of the day I want Systems and Systems Architectures to make MY WORLD easier, I don’t mind if that is going to mean some hard work for the developers.

I believe the developers will get more reward and wealth from doing some hard work, if a 3 year old can develop “Compostable” programs they will be just that : Throw Away!

(Methinks that Will Shuman appears to have grok’d it!)