Platform as a Service (PaaS) is a delivery of a computing platform over the web. PaaS enables agility, and provides a low cost alternative to buying and managing complex software and/or hardware. InfoQ had a chance to conduct a virtual panel to explore the world of PaaS, the different flavors that it comes in, its relevance in the enterprise and get a taste of things to come in the PaaS vendor marketplace and ecosystem.
The participants:
- Issac Roth - “PaaS Master”, Red Hat
- Mark Little - Dr Mark Little is Engineering Director, Red Hat
- Paul Fremantle - CTO, WSO2
- Chris Haddad - VP, Technology Evangelism, WSO2
- Stuart Charlton - Former CTO for Elastra Corporation, and Enterprise Architect for BEA Systems
InfoQ: There are a number of vendors offering their platforms as a service (PaaS)? And the offerings range from hosting platform, database platform all the way to domain specific platforms? What in your opinion defines a PaaS?
Issac Roth: [The fact] that you put code in and get a service out. If you have to put binaries or an OS in (such as with IaaS) then it isn't PaaS. Similarly if you just put in data and can't put in code, it's not PaaS.
Mark Little: Well as its name implies, PaaS is an offering that delivers a solution/platform to developers/deployers as a service. The user doesn't need to worry about the usual issues of buying infrastructure or even configuring the platform, though the last aspect is often something that is variable across vendors and implementations, e.g., some provide solutions that are extremely configurable.
Paul Fremantle: A PaaS is an environment that virtualizes application constructs as a cloud service: instead of provisioning VMs, a PaaS allows developers and operations teams to self-service provision and manage applications - typically web apps. A well designed PaaS also provisions and manages the other aspects developers and operations need to build scalable apps: databases, integrations, queues, log targets, process flows, and even portals. A key aspect of PaaS is to abstract away from underlying infrastructure - just as a well-designed IaaS tries to abstract away from real machines. Hence a PaaS should monitor, meter, bill, scale, and run independently of a specific IaaS and also should provide a view to developers that is independent of the infrastructure layer. For example, not how many machines am I running, but am I meeting my SLA?
Chris Haddad: Development and operation teams use a Platform as a Service offering to design, build, and deliver customized applications or information services. At a minimum, PaaS offerings differ from traditional application platforms by shielding teams from direct ownership, management, and complexity. To maximize business benefit, PaaS offerings should significantly exhibit essential Cloud characteristics:
- On-demand self-service
- Broad network access
- Resource pooling
- Rapid elasticity
- Measured service
PaaS offerings will vary from cloud washed to cloud native. While cloud washed solutions will deliver familiar architecture and programming models, they will offer modest Cloud characteristic advancements and deliver only incremental improvement in a team’s ability to meet user demand, rapidly deliver new capabilities, reduce time to market, and lower cost. To determine whether a PaaS is cloud washed or cloud native, teams must fully evaluate platform capabilities, attributes, and topology.
Cloud washed offerings are optimized for traditional, static single-tenant deployment. Cloud washed offerings exhibit elastic scale by provisioning (or de-provisioning) entire physical machines or virtual images, and manual effort is often required to synchronize application platform session state with hardware infrastructure changes.
Cloud native solutions are natively multi-tenant, elastic, dynamically wired, fine- grained, and incrementally testable. The entire application platform stack should support multi-tenancy. Multi-tenancy enables teams to customize applications and services per consumer by changing run-time configuration settings instead of provisioning new instances. As user demand grows and shrinks, an elastic and distributed platform will right-size application resources based on utilization, quality of service, and cost optimization policies. When resources are added, subtracted, or moved, the automated service management components dynamically re-wire resource connections. To further increase business agility, the PaaS environment must enable rapid release iterations and incremental solution testing.
Stuart Charlton: My tongue-in-cheek definition of PaaS is "scalability without skill, availability without avarice". A PaaS is a hosted software platform that drastically simplifies the effort required on the part of developers and/or architects to develop and deploy scalable, highly available software, paid for for on a subscription or metered basis. It provides less developer visibility and control into the lower layers of the software stack in return for higher productivity in scale, availability, deployment, and configuration.
InfoQ: Where do you think the industry is going in terms of PaaS product offerings? What interesting developments are you seeing in this space?
Issac Roth: Clearly broader offerings are happening. Almost everybody is expanding what they offer due to developer demand for diversity. I think we'll see continued broadening and also the integration of more pieces of automation. For example, Red Hat recently launched IDE integrations and an integrated dependency resolution and build service for OpenShift. I expect this trend to continue to more tooling.
Mark Little: For the past 40 years we have seen the industry evolve middle-ware to solve problems defined by wave after wave. Whether it's bespoke distributed systems, Web Services, distributed objects, or Java EE, the core components within these middle-ware standards and solutions are the same: transactions, security, persistence, etc. Unless you are only interested in building relatively simple applications, you quickly need some or all of these capabilities. PaaS is no different, and we are now seeing a movement towards Enterprise PaaS.
Paul Fremantle: I see a couple of strong themes. The first is to provide a strong set of services that go beyond just AppServer/app-hosting into a wider set of enterprise capabilities. We’ve seen this with PaaS vendors adding queueing- and database-as-a-service to the core services they offer to move up the stack. I think we will see much more though - I expect the major PaaS providers to have a wide set of core services including eventing/notification, cloud-scale log and activity monitoring, map/reduce, process management, billing and metering and more.
The second theme is that I see PaaS’es moving back into the development space and helping support continuous integration, automated test and general software development life-cycle (SDLC). I think this is a major win for customers: for example I talk to large banks who take a long time just to get a developer laptop up to speed, let alone sort out a common code repository, build and test for a new project."
Stuart Charlton: The biggest strength of PaaS offerings - their innovative and boundary-busting nature - is also the biggest drawback. Many to date have been highly proprietary and do not directly leverage legacy skill sets or may have trouble integrating with legacy software (e.g. support for SQL, Java EE, etc.) The trend lately is a gradual shift to providing more interoperable solutions SQL-oriented access to PaaS data stores, and opening up the platforms for broader use of traditional languages or frameworks such as those available with the Java platform.
Another important trend is the ability to host PaaS inside a private cloud, as many enterprises aren't yet ready to trust the shrink-wrap agreement nature of many public clouds, nor are they ready to completely give up visibility and control over lower software layers to a new PaaS software stack.
InfoQ: Increasingly we're seeing vendors offer services like Heroku. Continuous delivery is becoming the mantra. How do you see this playing out?
Issac Roth: Continuous delivery is a more efficient model for everyone. The vendors have a faster pace and a lower cost to deliver, the users of these services get better features faster and at lower cost. That said, delivering a continuous service with reliability and up-time and security is a tall order - it's easy to stand up a service but a _lot_ harder to stand behind one. Many services will need to be re-architected as they go commercial and scale up to support many enterprise users, and many business processes and whole businesses will need to be re-architected too. Early leaders will fall completely out of the picture and players that are not currently present will have important advantages due to the shift from technology integration to providing a service.
Mark Little: It will increase because it is what developers take for granted today in non-Cloud/traditional environments. If Cloud is to succeed, it has to be able to duplicate those situations and go beyond them.
Paul Fremantle: I see the next big shift in PaaS is exactly that - to support much more integrated build, CI and test. That is a very big focus for us at WSO2 and we’ve been working on projects with customers where we use the business process server and ESB to automate deployment into the PaaS together with orchestration across the code repository, project management and governance registry. These features are definitely a big win for PaaS because they help automate the governance of code quality and code deployment. The result is an easier time for developers at the same time as better governance.
Chris Haddad: Continuous delivery is only a part of the total DevOps equation. DevOps can implement self-service configuration, automated provisioning, policy configuration, process automation practices, incremental testing, continuous integration, and continuous delivery. DevOps creates an environment fostering beneficial collaboration between development and operations team members.
As teams adopt PaaS and DevOps, they have an opportunity to raise infrastructure abstraction. Dev Ops tooling integrated with PaaS will shield developers from hardware infrastructure concerns and expose business entities. By integrating DevOps tooling with on-demand resource instances, teams can reduce time to market and increase agility.
Stuart Charlton: I believe there's a strong desire to reduce the lead times to change in enterprises, and that PaaS will be the ultimate solution for those that prioritize the lowest effort of change over other attributes (stability, control, visibility, safety, security, etc.).
That said, enterprises largely aren't ready for continuous delivery as both their delivery processes based on offshore development teams using waterfall methods and operational process based on ITIL are woefully bureaucratic and out of date compared to the potential out there.
InfoQ: One of the reasons for slow adoption cloud services in the enterprise is security and governance. Is this just perception or are there concrete techniques vendors are using to address these concerns?
Issac Roth: In addition to the technology and process, which is slowly being put in place, enterprises need to see trusted vendors with whom they have an ongoing relationship. To build trust there needs to be more consequence than, "we'll give you back last month's hosting fees."
Mark Little: Many of today's cloud implementations are insecure and unreliable. You only have to look around over the past year or more and there have been times when we've seen outage after outage from one or more Cloud vendor, or security breach after security breach. For developers who are doing proof of concept applications, these are probably not so important. But for real world applications, cloud must evolve to provide at least the same kinds of guarantees that we take for granted from existing middle-ware systems, and have done so for decades. At the start of the Cloud hype cycle we heard vendors suggesting that we needed to ignore that past decades of middle-ware development and turn to this new (wild) frontier, where new solutions to problems had to be developed. That is simply not true. We need to learn from what has gone before and leverage it as much as possible. There are good reasons that enterprise middle-ware implementations have evolved the way they have and Cloud does not negate that; in fact it makes those solutions even more relevant.
Paul Fremantle: I actually think that private cloud on the whole has much stronger security and governance than many existing models. When I talk to customers about the wide variety of systems, dependencies and code that they have running in production it often scares me how little governance there is in reality for large enterprise IT. I see enterprises that are putting in private cloud addressing this from day one. I’m not saying there isn’t a lot of further work to do in this area - and its a huge focus for me right now. But I do think that the concerns have led enterprises to do the right thing and the result is that as an industry we are making huge strides in this area very quickly.
Chris Haddad: Governance is a difficult practice, which defines policies, parameters, and processes. Automated governance is required to efficiently scale services across numerous consumers and providers while effectively monetizing, maintaining, and securing assets and consumer-provider interactions. Concrete techniques to address governance concerns include publishing a service catalogue offering tiered levels of service, streamlining access and approval, and automating governance processes.
Scaling a Cloud environment while right-sizing available capacity is non-trivial, and the infrastructure must support demand management and capacity management activities. When organizations move beyond their first Cloud service release, automated lifecycle management becomes a predominant concern. To effectively manage the service lifecycle, the infrastructure must report on service versions, subscribed consumers, and usage trends. In the run-time environment, an infrastructure authority component must allocate resources across multiple cloud zones.
Vendors are also working to connect software development life cycle tooling with the run-time environment, extending run-time governance infrastructure to support multiple tenancies and dynamic discovery, and improving service level agreement policy definitions and run-time enforcement.
Stuart Charlton: Governing cloud providers is not rocket science. It is a finer grained relationship than traditional strategic IT outsourcing: ""out-tasking"" would be more accurate. It is much more ""shrink wrap"" in nature in legal and financial terms. But it fundamentally is still outsourcing a portion of your IT supply chain, something most shops should be familiar with.
From a security perspective, the two key areas are trust and data categorization. An enterprise is not likely to pick just any cloud provider off a brokerage, they are likely to partner with a small number of strategic partners they can trust from a data privacy and overall security perspective. Ultimately this is no different than trusting another outsourcing vendor with your core information assets - something that most enterprises already do at scale. With a trusted cloud partner, enterprises can potentially customize agreements, provide feedback, and ultimately just gain comfort in terms of the overall road-map and stability of that vendor.
Secondly, enterprises need to categorize their data to understand the what data is the highest sensitivity in terms of privacy and confidentiality, vs. data that is of the lowest sensitivity, and use that as input to prioritize the systems they migrate to the cloud. While the cloud industry is moving quickly, legal and audit departments are still struggling with foundational questions. For example, how does one forensically image a disk drive in the cloud, and would a virtual drive image still be admissible in court? What happens if an employee at a cloud provider has connections to an adversarial group, and gains access to privileged data? Who is liable, the cloud provider, or the customer? What checks and practices does the cloud provider have against this scenario occurring?
InfoQ: In your opinion, are vendors trying to be a one-stop shop for all the platform needs? or do you see a model where aggregation of best of breed services becomes possible as a result of standards?
Issac Roth: The standards aren't there yet and the technologies are evolving too quickly to standardize today. This could happen in the future when the platform gets better defined. Because it isn't possible in the near future to aggregate best of breed through standards, end-to-end integrations are going to be the short term story. Being a one-stop shop with everything integrated is the only way the vendors (such as us) can provide a supportable platform, which is something that developers want and will want more and more as production apps mature on PaaS.
Mark Little: There will never be any such things as THE PaaS solution that fits all developer needs. Therefore I believe it will be extremely unlikely that a single vendor will ever be able to cater for all developers in the Cloud. We'll see solutions that are aimed at specific segments of the developer community and some vendors will be able to cover several of these segments. Standards will play an important role here too, because they will break down the vendor lock-in that we see a lot today.
Paul Fremantle: While I expect people will try to aggregate best of breed PaaS environments, I see this as being very very hard today. For example, there is no uniformity in how to deal with development vs. staging vs. production environments. So anyone trying to manage an application that spans PaaSes is going to have a very hard time with that aspect today. The result is that today the best approach is to find a PaaS that offers the set of services that you need - for example application deployment, queuing and notification, integration and robust data services would be a strong basis for many companies. This is a major reason why WSO2 has pushed to build a single complete platform.
Chris Haddad: Mix and match aggregation practices are currently immature and stitching together multiple platform services requires substantial manual integration effort. To fully aggregate best of breed services, standards must specify resource and scalability limits, resource discovery, tenant partitioning, session management, service levels, authorization, access entitlements, and identity. While specifications (i.e. OpenStack, XACML, SAML2, OVF, VMAN) are emerging, interoperability across Infrastructure as a Service and Platform as a Service offerings in a hybrid environment is challenging. A complete, unified platform decreases integration cost, reduces solution complexity, and enables uniformly applying policy and process.
Stuart Charlton: I believe most vendors are vying to be a one-stop shop. The industry is moving at a faster pace than customers, and few customers are willing or able to participate in standards bodies. Standards wind up being a ""gathering of the losers"", or smaller vendors that wish to stand up to the larger and likely more proprietary vendors. Thus in my opinion, standards are unlikely to be successful in this area -- there will be a plethora, as there has been in the IaaS space, to minimal effect -- but it is likely that none of the important vendors will feel the need to support them.
I also think PaaS is much too complicated and early in its product life-cycle for standards bodies to be codifying and dictating lessons. More likely, open source releases of popular PaaS solutions will be the way that interoperability can be achieved over time.
Conclusion
As infrastructure services mature the platform services that are built on top of IaaS solutions will mature as well. Solutions available today range from Horizontal PaaS solutions like Amazon Web Services to niche Vertical PaaS players like SalesForce.com. The granularity of these platforms vary, so do the delivery models and deployment architectures. Vendors are constantly trying to distinguish themselves by their offerings and having any form of quorum for standardization can be increasingly challenging. PaaS is still in the emergent half of the maturity curve, and adoption in the enterprise will begin to see some uptick momentum.
About the panelists
 |
As Vice President of Technology Evangelism at WSO2, Chris Haddad raises visibility, awareness, and knowledge of the Carbon and Stratos platforms. Chris works closely with developers, architects, or C-level executives to increase WSO2 technology adoption, improve the middleware platform, and maximize customer value. Previously, Chris led research team at Burton Group and Gartner advising Fortune 500 enterprise organizations and technology infrastructure vendors on adoption strategies, architecture, product selection, governance, and organizational alignment. The team advanced best practices in Platform as a Service, Cloud Application Architecture Patterns, Service Oriented Architecture, and application middleware.
|
 |
Dr. Mark Little serves as the senior director engineering, middleware engineering at Red Hat. Prior to taking over this role in 2008, Little served as the SOA technical development manager and director of standards. Additionally, Mark was a distinguished engineer and chief architect and co-founder at Arjuna Technologies, a spin-off from HP. He has worked in the area of reliable distributed systems since the mid-80's with a PhD in fault-tolerant distributed systems, replication, and transactions. Mark and his family reside in Newcastle, UK.
|
 |
Co-founder and currently CTO, Paul Fremantle spearheads WSO2’s overall product strategy. His previous role at WSO2 was vice president of technical sales where he led the development of the groundbreaking WSO2 Enterprise Service Bus. Paul has published many articles, both on the Web and in traditional forms, and has spoken at numerous industry conferences, including ApacheCon, Colorado Software Summit, XML Europe, Software Architecture, and others. Paul has published two books: Building Web Services in Java, 2nd Edition, and The XML Files.
|
 |
Stuart Charlton is the Director of Infrastructure & Operations and Chief eChannel Architect at Canadian Pacific, leading the delivery of their cloud and web technology initiatives. Previously he was the CTO for Elastra, and an Enterprise Architect at BEA Systems. Stuart specializes in the areas of large-scale systems architecture, RESTful web architecture, and lean & agile approaches to business processes and product development. For over 14 years, Stuart has been a consultant and mentor for dozens of organizations in the United States, Canada, and Japan, and has written for several leading industry publications.
|
 |
Issac Roth is Red Hat’s PaaS (Platform-as-a-Service) Master, whipping the clouds into shape to create the best experience for developers who build on open source and leading Red Hat’s hosted online services strategy. He was previously co-founder and CEO of Makara, which launched the the first PaaS to run Java EE applications and was aquired by Red Hat in 2010. Previously recognized as an innovative leader in the APM space, Issac was a pivotal member of the team that built Wily Technology and, after being acquired by CA, Inc in 2006, built CA’s end-to-end application management business. He is thrilled to be back at the open source leader after having started his software career as the first technical support engineer at ACC Corp (Red Hat’s original name) in Bob Young’s living room.
|