Welcome to a double feature blog entry for Part 3. I’ve gotten a lot of feedback for Part 1 and Part 2 of this series. Because of the number of emails, comments, Tweets and other messages, there is an apparent need to add more context to PaaS, the NoOps/AppOps/DevOps thought, and how Cloud Foundry is stepping up to make this future happen.
Double Featurette, Part One: Context, Answers, and Thoughts on PaaS + OSS Cloud Foundry
DevOps Triumvirate … or Why the Operating System is Becoming Irrelevant & Polyglot Coders are in Charge
At the same time, as software is being built there is a growing effort to make existing and legacy application systems easier to deploy, mitigate risks of use, and reduce time to market. This effort has turned WordPress, SugarCRM, ERP software, vertical scale based RDBMS like Oracle & SQL servers, along with many other solutions, into the ultimate ‘easy button’ deployments. The industry is blowing away the nonsense of having a ‘specialist contractor’ come in and spend a month or two (or four to six months at some enterprises) at tremendous cost just to deploy some prepackaged software. Again, this is another movement where the focus is the application, and the operating system again is all but irrelevant.
The third movement is systems and network administrators who have sought out automation, testing, and agile processes similar to the software development practices. This group of admins, operations, and more have been heralded for automating, scripting, and building pieces to remove much of the infrastructure nightmare. The leaders, with their amazing products, services, and knowledge are OpsCode and Puppet. These efforts are where the operating system is truly important, yet the ability to make it irrelevant starts here.
Bridging the Movements: Enter DevOps or NoOps or AppOps, Yeah!
What all of us have now generally titled from this triumvirate of movements is the promise, the capability, the future of tech, becomes some form of DevOps. There has been some debate around the prospect of NoOps or AppOps, but suffice it to say traditional IT styled and traditional hosting environments are going to start falling before the DevOps/NoOps/AppOps efforts and capabilities. There’s just no reason to extend the cost, CapEx and resources for 99% of businesses. Focus on competencies, not on button poking and knob twiddling. The summary statement of the NoOps/AppOps/DevOps discussion landed around a statement from Adrian Cockcroft (@adrianco) of Netflix (if you haven’t heard or checked out Adrian’s work, do it, he’s done some awesome work).
All of these movements have revolved around fixing traditional IT problems, enabling cloud computing technologies, and have resulted in a focus in and around PaaS. Platform as a Service is leading the shift within all of these movements to the focal point of core competencies and value from business to government to non-profit organizations!
However, The Complexities Remain…
Even with all of these advances, improvements and changes there are still complex systems. These exist for both horribly bad reasons and (sometimes) logical reasons. Either way, they exist and need dealt with. Improvement of these complex systems is almost always done through abstraction of the complexity and simplification of the creation or deployment of these systems.
There is work to be done if your enterprise uses ESB (enterprise service bus), ERP (enterprise resource planning), accounting, queueing, workflow, BPM (business process management), SDLC software (software development life cycle), ALM (application life cycle management), enterprise identity management, SSO (single sign on), or the other numerous systems. PaaS is beginning to and extending support around all of these things – however there is the battle. Where does one simplify these systems to implement? PaaS always simplifies and improves management of systems, it however doesn’t fix your business processes that dictated the complexities of the systems in the first place.
These systems are coming to PaaS. I’ll be sure to bring you up to speed as they come to market. For now, know that there is extensive work being done and these features and capabilities are on their way. In the meantime, get your organization ready to clean the house of applications!
Last Note and A Partial Retraction
In the first part of the series, I stated that Windows Azure could also host Cloud Foundry. This is absolutely true. However, Windows Azure currently does not support an SLA on VMs (virtual machines) that aren’t default Windows Servers. This is a problem for most VMs, as they are currently offered as a beta service. (I keep losing track of this fact, I apologize.) Once you start using VMs in Windows Azure with Cloud Foundry, you’re basically on your own for troubleshooting and support. I’m sure as VMs become a core product things will improve, but for now you may want to skip that route and stick to AWS, Rackspace, VMware, and other solutions that currently work, are actively tested against, and see production usage.
The last question that had popped up a few times was, “Why would I use Cloud Foundry instead of Heroku, EngineYard, AppHardbor, or X PaaS Service Provider?” If you’re using one of those services, you probably would not want or need to use Cloud Foundry. However, Cloud Foundry provides some distinctive advantages over using a completely prepackaged PaaS solution. You can control the installation, the services, the code base, the amount of lock-in (choosing X framework stack and X infrastructure is a huge advantage), and a host of other issues and concerns. Also with Cloud Foundry a team can basically submit patches or get things changed where as with a set PaaS, you have no control over the actual executing environment code.
Keep reading, the next featurette is coming in just a couple days!