PaaS isn't just for developers

Most of the attention focused on Platform-as-a-Service, PaaS, is on its impact on developers. That's understandable. After all, developers are the ones "consuming" PaaS in order to create applications. In fact, as I've written about previously, Eric Knipp of Gartner goes so far as to call today "a golden age of enterprise application development"—in no small part, because of PaaS. Developer productivity is incredibly important, given that businesses large and small depend on information technology more than even. And, while much of that IT can and should come from pre-packaged software and services, plenty needs to be customized and adapted for a given business, industry, and customer set.

As, my Red Hat colleague Joe Fernandes discussed in a recent podcast:

For developers, Platform‑as‑a‑Service is all about bringing greater agility and giving them a greater degree of self‑service, really removing IT as the bottleneck to getting things done. In public PaaS services like OpenShift, developers can come and instantly begin deploying applications. They can choose from a variety of languages and frameworks and other services like databases and so forth. And they don't need to wait for systems to be provisioned and software to be configured. The platform is all there waiting for them, so they can be productive much more quickly. And really, what that means is that they can focus on what matters most to them, which is really their application code. They can iterate on their designs and really see the applications up and running without having to worry about how to manage what's running underneath.

But, as Joe also discussed, PaaS isn't just for developers. As we start to inject Platform-as-a-Service into enterprise development environments—often in the form of an on-premise product such as OpenShift Enterprise--it helps system administrators and system architects too. 

Consider first the IT operations teams, the "admins" in the vernacular. They're tasked with supporting developers. They're the ones who have historically had the deal with the help desk tickets filed to request new infrastructure for a project. They're also the ones who get bombarded with increasingly irate questions about why the new server hasn't been installed and provisioned yet. Of course, virtualization and virtualization management has helped to some degree but they've generally reduced the internal friction of the process, rather than fundamentally changed it.

A PaaS on the other hand, allows admins to focus up-front on basic policies (such as whether to use a public hosted service or to deploy in-house) and to work with developers on defining which standardized environments they need. At that point, self-service and automation (under policy) can largely take over. The "machinery" can scale the apps, deliver new development instances, isolate workloads, and spin down unused resources—all without much ongoing involvement by the admins.

Of course, if it's an on-premise environment, they'll still need to manage the underlying infrastructure but that's the price on having more direct control and visibility than with a public shared service. An IT operations team has to manage this infrastructure efficiently and securely. PaaS can help with that too.  For example, OpenShift goes beyond server virtualization by introducing the concept of multi‑tenancy within a virtual machine using a combination of performance and security features built into Red Hat Enterprise Linux. 

As for enterprise architects, they're are trying to marry the IT infrastructure, IT operations, and application development methodologies to the needs of the business. So they have to understand where the business is going and how IT is going  to architect their infrastructure, their applications, and their processes to address those needs. This in the face of tremendous growth in demand from the business for new services, new back-end applications, new mobile applications, new web services and more. It falls on enterprise architects to help figure all this out.

One way PaaS helps is that it lets them standardize the developer work flows, that is the process that IT needs to go through every time that a developer starts on a new project. Get them provisioned with the infrastructure they need, with the software they need, so that they can start either developing or doing testing or performance testing, or even deploying those applications all the way through to production. The result is not only faster application development but less fragile and error-prone application architectures—attributes that are especially important as we move toward more modular and loosely couple software. 

As Joe put it to me:

You're never going to eliminate the role of the IT operations team in an enterprise context. What you need to do is figure out how the operations team can work more effectively with the development side of the house to meet the needs of the business. To me, it's not dev or ops. It's really both. The developers aren't going to take over the job that the IT operations team does any less than the IT operations team is going to be able to build and deploy their own applications and so forth.

The question is, how do both sides work more effectively together? How do they reduce friction and really help accelerate time to market? Because, ultimately, that's all the business cares about. Business cares about when they can get their new service and how quickly they can start leveraging that, whether it's an internal or external application that they're looking for, and it's incumbent on IT organizations, operations team, as well as developers, to help figure that out. That's really what we're trying to do with Platform‑as‑a‑Service: drive that process forward.