In 2009, the U.S. National Institute of Standards and Technology (NIST) published a draft definition of cloud computing. The NIST definition, created for government agencies buying cloud services, simplified cloud computing into three types of services:
- IaaS (Infrastructure as a Service), where vendors offer on-demand compute, network, and storage;
- PaaS (Platform as a Service), where vendors provide application development frameworks and deployment tools; and
- SaaS (Software as a Service) where vendors deliver entire applications.
While IaaS and SaaS are well understood and widely adopted, PaaS has lagged behind. However, I expect a massive surge in platform services in the next few years, due to the flexibility and control provided by application containers and services that can be built around them. More on this later.
Why PaaS adoption has lagged
Technology changes at a blistering space, and software architects understand that change is inevitable. Assumptions and requirements will change. Users evolve, and usage patterns change. Business goals and market needs change. What may be considered the best solution to a problem, will become outdated. Architecting systems for the long term means creating modular systems, where system components can be adapted over time without impacting the entire system.
The NIST definition helped move forward our collective understanding of cloud computing. However, the cloud offerings and related technologies have evolved significantly since its publication, especially in the platform space.
“The popular wisdom that cloud computing comes in three flavors — software-as-a-service (SaaS), infrastructure-as-a-service (IaaS), and platform-as-a-service (PaaS) — no longer describes reality.” — The Forrester Wave™: Enterprise Public Cloud Platforms, Q4 2014
Initial PaaS solutions, like Heroku, were designed for 3-tiered Web applications. The platform provided choices for databases, front-end Web services, and other common services required to deploy and operate web applications. With PaaS, developers could now simply focused on their application tier.
The early platform solutions attempted to shield developers from the complexities of cloud infrastructure by fully abstracting and managing the underlying resources. The solutions provided ways to declare and ingest application code, and after building and staging, would run the code in custom containers on a pool of virtual machines managed by the platform. For example, Cloud Foundry deploys code in a Linux container called Warden (recently renamed to Garden).
While the PaaS vendors set out to solve important problems, initial implementations addressed these by limiting choices for developers and operators. Standardization has its merits, but the lack of control and visibility with the initial platform solutions can quickly become a limitation.
Infrastructure services and software services like databases and messaging continue to evolve rapidly making it difficult for any structured platform solution to remain relevant. Application architectures have also evolved, from the monolithic tiered applications that early PaaS solutions were designed for to microservices style architectures where an application is composed of several independent but cooperating services. Microservices require different backing services, like service registration and discovery, which the PaaS solutions built for 3-tier applications do not offer.
What’s changed?
Most PaaS solutions use containers to define an application unit, and to isolate and manage application runtimes. However, in a traditional PaaS the application containers are kept hidden from users and controlled by the platform. A PaaS vendor called dotCloud recognized that user interest in their container technology was outpacing interest for their platform offering. In 2013, dotCloud released that container technology as Docker, abandoned their PaaS product, and became Docker, Inc.
Moving the application container out of the platform vendor’s control, and into the hands of the users, was a brilliant move. The application container could now be used as a portable unit of application delivery and operations. Enterprises devops teams are now no longer locked into a single platform.
Container Services
Enterprise devops teams should be able to choose the best language, services, and technology for their applications. To enable this, it makes sense to separate platform services that manage the application life cycle, from the services that are used from within the application, for data management, security, and other common application functions.
The platform layer can now be decomposed into two separate but cooperating layers:
- Container services to manage application lifecycles on any infrastructure;
- Shared services (e.g. databases, messaging systems, etc.) selected by the enterprise DevOps teams.
Enterprises can now compose their own application platforms by selecting best of breed services for each layer. The portability and flexibility enabled by allowing users to control their application containers, also makes it easier for enterprises to leverage multiple cloud providers.
With the container services approach, there are no limitations or restrictions on development languages, tools, and services. Enterprises can now use open tools to package their application code into portable container images which are executed by the container services layer. This is essential for enabling Microservices style application architectures which are conducive to empowering small autonomous devops teams.
Application devops teams can choose their own shared services and standardize where it makes sense. The shared services may be run on the same container service, or in some cases may be entirely consumed as SaaS. A decision to change a language, or service for an application, does not impact the overall platform or other applications on that platform.
IT administrators now have full visibility and control of infrastructure services. The container services layer can help automate provisioning of infrastructure resources by integrating with infrastructure services, and without adding additional abstractions on the infrastructure layer. This allows enterprises to choose any cloud provider and leverage best practices for security and infrastructure management.
Container services are a game changer for application platforms. They enable all the benefits of a traditional PaaS, but without any compromises. Enterprise teams can now choose one or more cloud providers, select a container technology, select best-in-class container services and shared services, to compose their own platforms.
In my experience with customers at Nirmata, containerizing existing applications and adopting a container services approach and has led to significant improved efficiencies and developer productivity gains — which translates to immediate cost savings and increased innovation for the businesses. It’s a great time to be developing!
Jim Bugwadia
Founder at Nirmata
This article was originally posted at InfoWorld contributor network.
For more updates and news follow us at: 
Sorry, the comment form is closed at this time.