@CloudExpo Authors: Zakia Bouachraoui, Pat Romanski, Elizabeth White, Yeshim Deniz, Liz McMillan

Related Topics: @CloudExpo, IBM Cloud, Containers Expo Blog, Agile Computing

@CloudExpo: Blog Post

How Pushy Should PaaS Be?

Should PaaS solutions aggressively push commoditization of the application stack?

I cannot help but chuckle when I hear someone say, write, or tweet that because of cloud computing operating systems are fast becoming a commodity. The only thing I can say is that they apparently do not talk to the same users that I do. I can accurately use the word ‘entrenched' to describe the commitment to an operating system type that I observe among many enterprises out there. Whether or not you can attribute the commitment to organizational skill or organizational culture is really beside the point. Bottom line: Many users will only leverage a very specific operating system.

Why am I talking about operating systems and the relative lack of commoditization? Because I believe this is interesting to consider in the context of the growing wave of PaaS solutions we see in the market. Many PaaS solutions are going to attempt to commoditize a chunk of application environments that goes beyond just the operating system. In fact, in a number of cases this attempt at commoditization will be more than just a side effect of the PaaS deployment model. Quite a few PaaS providers will actively seek to commoditize larger chunks of the stack, since this allows them to attract customers based on the operational experience they provide and not based on the supporting infrastructure over which they may have limited control.

Given the larger commoditization movement I think we will see in PaaS, and given the fact that many users are not ready for even basic levels of commoditization, this begs the question: How pushy should PaaS be? What I mean to flesh out with the question is the degree to which PaaS solutions should force commoditization. In other words, should PaaS providers be passive or active in their goal for commoditization?

First, it probably helps to clarify what I mean by active and passive in this case. I would consider PaaS solutions active in the push for commoditization if they presented a completely application-centric view of the world. Users provided their application, set some application policies, and then hit the big easy button. From there, the PaaS solution handles all aspects of deployment including the selection of the application stack (from the OS through the containers), the deployment of the stack, the configuration of the stack, and finally the deployment of the application. The user has absolutely no view into the configuration of the underlying application stack, and they have no way to influence the configuration. In this sense, the PaaS solution is telling the user ‘Hey, I know what's best for this. Sit back and put your feet up.' That amounts to a commoditization of the application stack in question whether it is a servlet stack, PHP stack, JEE stack, etc.

On the other side of the coin is the PaaS solution that is passive in its approach to commoditization. The solution provides a glimpse (or more) into the selection and configuration of the application stack. In this model, the application is still the centerpiece, but with a somewhat diluted focus. Users can influence the selection of the application stack in some manner and even tweak the underlying configuration. The PaaS solution does not force commoditization of the application stack, even though it may be encouraging it.

Of course, one would certainly measure activeness versus passiveness on a continuum. That is to say, you would probably not describe a PaaS solution as simply passive or active, but rather you would describe its degree of activeness or passiveness.

The interesting point to consider here is on what end of the spectrum should PaaS solutions orient themselves? Should they lean more toward the active end or the passive end?

Opinions definitely vary in this regard, and to some degree, it depends on whether you view cloud as primarily evolutionary or primarily revolutionary. I happen to view many aspects of cloud as an evolution and integration of existing technological concepts into a more meaningful whole. Couple that view with the resistance to basic levels of commoditization I see every day from users, and I tend to believe that PaaS solutions will make more hay by leaning slightly toward the passive end of the spectrum -- at least early on in the movement. PaaS providers need to consider the kinds of stack customization capabilities that users expect, and carefully design this into their solution.

This is certainly not an easy task, and it can be a slippery slope. If PaaS solutions begin to expose, or force, configuration capabilities on users, they can dilute some of the value they look to provide with quick and easy application deployments. As with anything, there is a happy medium, and it is probably tough to find. However, PaaS solutions that severely limit the influence of users on the underlying application stack may struggle to attract a significant user base.

That's my view on the struggle between passive and active commoditization in the PaaS market. What is yours? I'm particularly interested to hear from those that think that PaaS solutions should primarily lean toward active commoditization. In any case, you can find me on Twitter: @damrhein.

More Stories By Dustin Amrhein

Dustin Amrhein joined IBM as a member of the development team for WebSphere Application Server. While in that position, he worked on the development of Web services infrastructure and Web services programming models. In his current role, Dustin is a technical specialist for cloud, mobile, and data grid technology in IBM's WebSphere portfolio. He blogs at http://dustinamrhein.ulitzer.com. You can follow him on Twitter at http://twitter.com/damrhein.

CloudEXPO Stories
The deluge of IoT sensor data collected from connected devices and the powerful AI required to make that data actionable are giving rise to a hybrid ecosystem in which cloud, on-prem and edge processes become interweaved. Attendees will learn how emerging composable infrastructure solutions deliver the adaptive architecture needed to manage this new data reality. Machine learning algorithms can better anticipate data storms and automate resources to support surges, including fully scalable GPU-centric compute for the most data-intensive applications. Hyperconverged systems already in place can be revitalized with vendor-agnostic, PCIe-deployed, disaggregated approach to composable, maximizing the value of previous investments.
When applications are hosted on servers, they produce immense quantities of logging data. Quality engineers should verify that apps are producing log data that is existent, correct, consumable, and complete. Otherwise, apps in production are not easily monitored, have issues that are difficult to detect, and cannot be corrected quickly. Tom Chavez presents the four steps that quality engineers should include in every test plan for apps that produce log output or other machine data. Learn the steps so your team's apps not only function but also can be monitored and understood from their machine data when running in production.
A valuable conference experience generates new contacts, sales leads, potential strategic partners and potential investors; helps gather competitive intelligence and even provides inspiration for new products and services. Conference Guru works with conference organizers to pass great deals to great conferences, helping you discover new conferences and increase your return on investment.
Poor data quality and analytics drive down business value. In fact, Gartner estimated that the average financial impact of poor data quality on organizations is $9.7 million per year. But bad data is much more than a cost center. By eroding trust in information, analytics and the business decisions based on these, it is a serious impediment to digital transformation.
Containers and Kubernetes allow for code portability across on-premise VMs, bare metal, or multiple cloud provider environments. Yet, despite this portability promise, developers may include configuration and application definitions that constrain or even eliminate application portability. In this session we'll describe best practices for "configuration as code" in a Kubernetes environment. We will demonstrate how a properly constructed containerized app can be deployed to both Amazon and Azure using the Kublr platform, and how Kubernetes objects, such as persistent volumes, ingress rules, and services, can be used to abstract from the infrastructure.