Recent Tweets
join our mailing list
* indicates required

About Ambleside

Ambleside Logic is led by Aaron Rosenbaum. Father of 3, Programming since 7, DevOps since 11 (hacking RSTS), exIngres, exCTP, exCohera. Sold two companies to Oracle, one to HP. Research + Strategy for NoSQL/BigData ecosystem implementors, vendors and investors.

« User Experience Guidelines for shared dashboards (less is more) | Main | Faster BI time-to-value in 2012 »
Thursday
Jul072011

PaaS for Enterprise - make it simpler and it will happen

 

There are some common notions that PaaS is stalled at the enterprise because of enterprise readiness, lock-in, security and integration.  I think each of these is true to a certain extent but I think mostly it’s still too damn hard to make sense of how everything fits together.

Departmental App growth leads all enterprise adoption and developer productivity has led every single transition.  IMS to RDBMS? Report writing productivity.  3GL’s to RAD tools? Business logic encapsulation and GUI productivity.  And I’ll claim that mid-tier Unix never really would have taken off at all without RAD and RDBMS. Many concerns melt away if there is enough money to be made off the app.  But you can’t get to value quickly if the business domain experts have trouble making stuff work at all.

Each generation of Enterprise Technology to achieve widespread adoption has done so because of dramatically easier development vs. the previous generation.  I built failover routines into X.25 networks.  It was a PITA - TCP/IP took care of it for me.  Rich GUI apps did exist before Gupta and PowerBuilder - but coding a gui in C was also a PITA. These tools freed up developers to focus on business value further up the stack rather than plumbing. Which in turn made possible development time cycles that were unheard of before.

A typical departmental app for an F1000 company might cost $1.5M.  Not having to spend $500K on hw helps a lot but we still have to do business requirements, training, docs in that budget also.  Your going to put a dev team of maybe 5-6 for a year - maybe - within that budget.  Is one of them a cloud architect? Or a tools master? If you do have a cloud architect, that person is also the data architect and team lead.  And the tools master? Probably the guy no one trusts to code.  
You’ve got legacy code you have to refactor or encapsulate, API’s to code to existing apps, performance tests to write, status meetings, etc.  

Fast forward 20 years and now LAMP has made developers lives easier.  Rails too. But even the best of the Cloud frameworks - CloudFoundry and Eucalyptus come to mind - are still to focused on Ops.  At least they enable choice for the developers but it’s up to the developer, not the framework or tool, to ensure success. The burden of analysis and knowledge is too high on the typical business development team.  

What do we need to make this EASY?

Truly automatic instance deployment and tear down
Make it happen, the right way, without me worrying about it at all.  AppForce (SF.COM) and AppEngine (Google) are here.  Heroku and Jenkins/Hudson maybe, but one still has to do too much thinking about this. Why does a developer need become a sys admin to make things scale?

Distributed Data without a religious war
Data consistency requirements aren’t necessarily known at the time of application architecture and there are cases that often emerge where the consistency varies based on business rule not data field (inventory, stock pricing are two examples that come to mind.) Having the flexibility and tools to understand data aging, identify bottlenecks and make tradeoffs just isn’t there today.  Hadapt and Clustrix both have some interesting approaches here. Others are just building things in a very soft manner but if the app actually involves the real world, sometimes real concurrency is actually needed. People are deploying NoSQL often because it’s open and they feel like it can scale, not because the app is suited to that particular data store or because they really understand the concurrancy requirements. Why do they have to?

Scalable code for mere mortals
 
While it’s possible to build a scalable system in Java or C, it requires a bit of care to avoid the pitfalls.  Does that mean we all need to code in Erlang or Haskell? No.  But the platforms need better/easier frameworks to implement what we need. Maybe more clojure and less node.js...still, again, it’s all too esoteric for the typical enterprise business programmer. Why can’t the systems enforce atomicity and statelessness? The logic pieces are seldom that complex.

 
Current Status/Predictions
 
The technology providers who make life easier for  developers will win. But it’s too hard to implement the cool public-cloud PaaS products inside the enterprise for trust and security reasons.  So, Eucalyptus/AppScale and CloudFoundry  and other inside the firewall cloud platforms need  to succeed.  But also, we need better frameworks on top of the cloud platform.  Springs? AppEngine? JRuby? I think it’ll need to be something that has optimization for both front-end instance scaling and back-end query optimization and routing.  MySQL clusters are going to be good enough for a whole lot of tasks...Maybe it’s as simple as Hudson/MySQL? Or will the MySQL team integrate part of NoSQL inside their stack like Hadapt?  (Or maybe Mickos will just build out a data layer into Eucalyptus...it’s not like the guy doesn’t know data...) Whatever happens, the crowds around Apache and VMware seem pretty safe right now.  Where are Oracle and MSFT? Who knows....IBM and HP made the transition from mini to Unix but plenty of other large companies didn’t.  But no one had as much cash as these guys have now.....Just please, please make it easier....

 

 

 

PrintView Printer Friendly Version

Reader Comments

There are no comments for this journal entry. To create a new comment, use the form below.
Member Account Required
You must have a member account on this website in order to post comments. Log in to your account to enable posting.