For this to work, many argue that we need Devs to go back to Dev and IT Ops to step up to CloudOps. Don't fall for the assumption that your existing IT staff will simply embrace the cloud and slip right into managing these functions so your Devs can go back to coding. While DevOps is positioned to be the saving grace for the developer and operations teams' relationships, let's remember where DevOps came from and what we really want out of it. 

The origin of the term DevOps comes from the early days of IaaS cloud computing and was a kinder term for what was a polarizing statement of disruption. I've been researching and predicting this evolution since 2008, which I documented in my Forrester report, Is Cloud Computing Ready for the Enterprise. That's when several enterprise developers started bypassing their IT departments and used their credit cards to deploy new workloads to the public cloud. Paying for the cloud services with a personal credit card only to expense the bill was easier than trying to get IT and procurement to sign up for the cloud service (especially if you felt they would object). Because everything was so accessible, these automated services enabled the developers to deliver workloads with NoOps.

This movement led to the creation of a new set of development tools that empowered these developers and also threatened the IT Ops department. The vendors and developers in this space then started to embrace the softer and more politically correct term: DevOps. 

Shortly after, we started to see a definitional shift from not needing Ops to a marriage reluctant re-cooperation between Dev and Ops in the cloud era. But the tools and best practices remained centered around developer empowerment, driving agility, self service and autonomy, with IT Ops teams encouraged to embrace the new toolsets, take on the new "CloudOps" roles and give developers what they (and businesses) want -- that's greater agility and continuous improvement.

In the current state, these leveraged tools and cloud services still require the developer to understand configurations and deployment more than they should and be involved in steps of the deployment that detract them from their core objective, like writing cool new experiences that drive the business forward. 

Is this really necessary to deliver better experiences and higher productivity? Will this ever truly empower all your developers? No. What is needed and is starting to emerge among the leading cloud platforms are a series of tools that empower everyone who codes by letting them focus purely on coding. 

It's more psychology than technology. Consider that person who loves sushi. It's completely counterintuitive for them to think about actually making the sushi or even buying the fish -- they just like eating it. That's the psychology here. For a lot of the people who love sushi, if they had to learn how to butcher the fish, cook the rice properly and assemble the rolls, they would ask you to just hand them the sushi, please...

 

That's the same mentality that we're talking about here. A developer wants their application to accomplish certain things and to run all the time. They don't want to have to figure out which virtual machine has the right CPU and memory count to run the code or to figure out how to recover when an infrastructure resource beneath the application fails. And frankly, those who know this the best aren't the developer or even the IT department, but rather the public cloud platforms. 

Am I just making an argument that stage two of cloud computing will be about PaaS? No, because the reason PaaS hasn't dominated is that many implementations to date have been too restrictive. They've been tied to a single SaaS app, limited to a single programming language or app server model, or lacking the flexibility to leverage the vast array of cloud services offered in the market today.

The challenge with these services is that while you're empowering your developer, in more cases than not, you're making a proprietary service decision for your company. This means that any apps built on the Force.com platform are tied to Salesforce and can only run on that platform -- the same holds for most of the PaaS offerings in the market today.

Having to write code for a specific platform is very limiting. You can end up with a specialized staff. Your developers have to learn multiple languages or how certain paths work to be valuable, and if you switch them to another platform, they have to go through that learning process all over again. A call that works for one platform won't work on another, and every time you change your platform, your developers need to retool their skill sets.

If we want to achieve true developer empowerment in this next generation of cloud, we have to encourage more coders to be productive with their existing skills. We can do this by letting them program with the languages they want to use -- and are most appropriate to the type of app they are building -- giving them reliable and consistent access to as broad a set of services as possible, and doing this in such a way that leverages open source and open standards. You want their processes to be painless and intuitive to encourage productivity and be applicable across the needs and services that your business operates and leverage where your customers are when they want you there.

The major cloud platforms support pretty much any programming language you want to use, and they have a vast set of services. The differences today are that most of the interfaces to these services have a common communication model and tend to use a RESTful API to connect your code to the service. 

Imagine though if your developers had access to a vast library of APIs for your services and third-party services that let them build whatever they wanted by plugging into those APIs. Then, when they're finished writing the code, they can push the "Deploy" button and everything just works. Even better, what if they didn't have to worry at all about configuration, availability, which VM is right, backups or anything else that has to do with IT operations?

 

If they decide they want to pick up that code and switch platforms to improve performance or because of a broader business decision, all they have to do is remap the APIs. If I built a workflow application that calls Workday, Microsoft Office 365 and the GE Predix Industrial IoT service, as long as there are REST APIs for everything, it doesn't matter if I run my application on top of Azure or OpenStack. We're finally beginning to see this in the second era of cloud platforms through tools like Microsoft Flow, Azure Functions and third party tools like C3DNA.

 

Now's the time for you, the reader, to expect services that are open source or leverage open source code and standards, and to empower every developer in your organization at their skill set, whether that's DevOps, Dev, scripter or business enabler (via no-code tools like Microsoft PowerApps and others). If you're not getting this, push back and ask for it.