PaaS Standards: Standardize On What?

Introduction

Standardization is a natural process in any technological evolution and it helps enterprises in terms of quality control, repeatability, interoperability, etc.. As we move into the cloud based world, with large scale automation, standardization becomes even more important. Typically, open source makes standardization much easier. However, there is a strong belief in the industry that an open source PaaS offering automatically makes the platform a standard for the industry. I want to take on this belief system in this blog post and put forward arguments about what I think as the right way to standardize in the PaaS context.

PaaS Standards

Standardization is very important in PaaS because there is a misconception in the industry that PaaS is a way to ensure vendor lock-in. If we have to remove this misunderstanding, it is important for us in the industry to understand the real value of PaaS standards and move forward in a direction that helps avoid vendor lock-in. It is very important for the industry to focus on the right standards for PaaS.

Misconceptions about PaaS Standards

As I said in the previous paragraph, the main goal of PaaS standardization should be to alleviate any concerns about vendor lock-in. This can be done by making portability of applications seamless across platforms offered by different vendors. However, there is some perception in the industry that if the platform software is released under an open source license, it becomes a standard automatically. This line of thinking is valid in most cases but it doesn’t apply to layers of the cloud stack like PaaS because of the perception that the risk of vendor lock-in is high. It is important for the standardization process to look beyond source code and towards seamless application portability.

Source code availability might empower the end user to take advantage of the platform beyond the vendor control to a certain extent but the user is still dependent on the vendor for some of the features and functionality. The availability of source code doesn’t automatically guarantee support for any language, data store, application server, etc.. The end user is still dependent on the platform vendor for such support or incur high cost for finding right resources. The cost becomes even more visible when support for proprietary runtime is needed inside a platform. PaaS offerings with an open architecture definitely helps in this regard but what is needed, along with the open source push, are a set of standards that will make application portability across platforms seamless to end users.

Let me make it clear that I am not arguing for focus on application portability over open source. Open source is key part of the standardization process but I am arguing that application portability from one platform to another should also be an important factor in the standardization process. Open source alone doesn’t guarantee application portability.

How can we achieve this?

In the case of Platform as a Service, standardization process should focus on two aspects: * Portability of “application dependencies” * Portability of entire applications

Let us briefly consider these two aspects of PaaS that are critical to avoid vendor lock-in.

Application Dependency Portability

An application depends on the language runtime, frameworks, data stores, third party services, etc.. As a developer, if I want to move from one PaaS offering to another, I would want to take all these dependencies with me so that I can deploy the application on the newer PaaS without any drastic changes. There may still be some need to change the application architecture or code to meet the requirements of the new platform but it will be minimal if there is a way to port the “application dependencies” easily to the new platform.

Heroku’s Buildpacks and OpenShift’s Cartridges are very good examples for packaging the application dependencies. Heroku’s Buildpacks are an excellent model for porting application runtimes and frameworks. It was built for the hosted PaaS and can be a very good standard for such services. However, it can’t be easily extended to private PaaS deployments.

OpenShift’s Cartridges format is much more versatile than Buildpacks when we consider both hosted and private PaaS deployments. I am not arguing that Buildpacks are not suitable for private PaaS deployments in the enterprise but rather pointing out that Cartridges offer a much more versatile format to meet their needs.

Another such packaging format is WSO2 Stratos Cartridge architecture and it is part of WSO2 Stratos which was donated to Apache Software Foundation by the parent company.

Clearly, Cartridges and Buildpacks are ideal candidates for standardization when it comes to porting application dependencies. When PaaS providers standardize on Cartridges and/or Buildpacks, developers can work on different PaaS environments in a more seamless manner.

Application Portability

The other aspect of portability in the PaaS context is to move the entire application including its dependencies. This will require almost no change to the application as it is moved from one platform to another. Even though it is much easier said than done, seamless application portability is the ultimate enterprise cloud nirvana. One way to do it is use the containerization model. Simple application containers which packages the application and dependencies can be ported across multiple platform with ease. As most of the PaaS offerings use containers in one form or another (RHEL based containers by OpenShift and LXC based containers by other platforms), application containers are a good candidate for standardization. These containers help end users move their applications seamlessly from one platform to another without any form of vendor lock-in.

In this regard, Red Hat’s partnership with Docker is significant. Docker is a lightweight Linux container which abstracts away all the complexity and makes it very easy to port applications across different platform. Some form of standardization process around containers will break any vendor lock-in and set the applications free.

Conclusion

Any talk of standardizing on any particular platform, even if it is open source, doesn’t help the end users in any significant way. Even though open source has strategic advantages over proprietary platforms, it is not enough to avoid vendor lock-in. Any standardization process should instead focus on portability of application dependencies or entire applications. Cartridges and Buildpacks are ideal candidates for the former and Containers are suitable for the latter.

Krish,

You should also mention the standardization of the PaaS management interface being done in OASIS with the CAMP standard (https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=camp) - with RedHat being one of the initial submitters of the specification.

-- mark