More on Removing the OS Barrier with PaaS

The content of this article was originally written by Adron Hall on the New Relic blog.

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

Polyglot Coders
We know that the polygot inception is happening. However, many of us (myself included) are extremely knowledgeable in a specific platform area. To meet this challenge, we need to update our skills and position ourselves accordingly. I’m continuing in C#/.NET (MVC primarily), but I’m quickly branching into other realms, working to enhance my capabilities in the JavaScript/Node.js, Ruby on Rails/Sinatra, and other stacks. To summarize though, “I can’t become more polyglot fast enough!” The desire and need to become polyglot, extend my skills as a developer, and to encourage and enable other developers to do the same comes from several major movements within the tech industry.

DevOps Triumvirate … or Why the Operating System is Becoming Irrelevant & Polyglot Coders are in Charge
A huge movement has started around CI (continuous integration) and CD (continuous deployment) for building clean and effective process to create lean, sometimes iterative, powerful software development processes. With HTML5, JavaScript, Objective C for iOS Dev, C# & .NET, Ruby on Rails, Java with Android, other tools, and more all paving the way to new capabilities we’ve introduced even more complexities. With all these new complexities and capabilities, the operating system is slowly becoming more irrelevant by the day. To remove the complexities and further increase operating system irrelevancy, CI and CD come to the rescue. Efforts continue to bring the application and end product to the forefront of focus.

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!