Technical Dive into Cloud Native Application Platforms

Premise: The markets and ecosystems around Structured and Unstructured application platforms are rapidly evolving. IT organizations have many choices and one architecture will not fit every company. Wikibon looks at leading platforms and the alignment of customer needs with platform capabilities.

[In this series of research on Cloud Native Application Platforms, we will explore the Market, Technology, Operations and Organizations that enable next generation applications. Cloud Native applications are the modern, modular approach to building applications that are focused on web-scale, mobile-first, and real-time data.]

Part I of the research – “Cloud Native Application Platforms – Structured and Unstructured”

Part III of the research – “Evolving Organizational Dynamics of Cloud Native Applications”

Unlike IaaS and SaaS, which are relative well defined architectural and consumption models, PaaS is a set of platform architectures that are rapidly evolving and changing. On one end of the spectrum are structured platforms that are a defined set of services for both applications and operations teams. On the other end are a loosely coupled set of tools that can be brought together in various ways to address scalable application deployment challenges. The existing skills and operational models of an IT organization will often dictate which platform is the best fit for deploying existing applications, as well as modern Cloud Native applications.

In this technical research, Wikibon looked at a number of different offerings. The criteria for inclusion were:

• The platform must be generally available to the public, either as a commercial product or open source project.
• The platform can be consumed (installed or on-demand service) on a public cloud or operated within a customer’s data center. The research did not include any platforms that operate only as a SaaS service in a public cloud.

Wikibon included the following platforms in this research (alphabetical order).

• Apcera Continuum
• Apprenda
• CoreOS Tectonic [1]
• Docker (Docker, Machine, Compose, Swarm, Notary)
• HashiCorp Atlas [2]
• Pivotal Cloud Foundry [3]
• Red Hat Openshift Enterprise v3 [4]

[1] CoreOS products/tools can also be acquired independently, instead of within the Tectonic platform.

[2] HashiCorp products/tools can also be acquired independently, instead of within the Atlas platform.

[3] Cloud Foundry is an open source foundation and a set of open source projects. We selected Pivotal Cloud Foundry as a reference platform for this community. Other implementations of Cloud Foundry may have some variances in features. Evaluations and conclusions from Pivotal Cloud Foundry do not necessarily apply to other implementations of Cloud Foundry (e.g. IBM Bluemix, HP Helion (via ActiveState Stackato), etc.).

[4] Red Hat offers three version of OpenShift – [a] OpenShift Online (Public Cloud PaaS), [b] OpenShift Enterprise (Private PaaS) and [c] OpenShift Origin (Community PaaS).

Cloud Native Platforms – Critical Evaluation Criteria

Understanding Cloud Native platforms can be a complex evaluation process. Not all platforms are optimized for the same types of applications or scale, and not all platforms are targeting the same sets of customer environments. Wikibon looked at five key areas during this research:

1. How would an application developer engage with the platform? What is the process for either code or applications to get onboarded to the platform?
2. How would the operations team engage with the platform? How does the operations team gain visibility into the platform, and what tools are available to assist them in maintaining platform stability?
3. How are applications staged and deployed into the system? Application workflows and lifecycles can be complicated, so how are applications staged into the various cycles of these processes?
4. How are new services added into the platform? Examples: Service Discovery, New Databases or Data Services, additional Cloud services, etc.
5. How is Logging and Monitoring managed within the platform, or from external services? Are these capabilities built into the platform or are 3rd-party tools expected to be used.

In addition to those five core areas, Wikibon highlighted unique capabilities for each platform around aspects of identity-management, policy-management, and security.

 

Platforms Makes it Easier to Deploy; Platforms Are Enabling Hybrid Cloud

Wikibon has written before that the current iterations of Hybrid Cloud lacks maturity because the concept has been attacking the problem from the wrong layer in the stack – the infrastructure layer. The modern application platforms, often called Platform-as-a-Service (PaaS),  have evolved to architect application portability and multi-cloud environments differently.

• All modern platforms now abstract the underlying infrastructure in a way that allows applications to run consistently across multiple clouds, whether the platforms deploy directly via containers or leverage containers as the underlying infrastructure
• Today’s platforms now possess knowledge of multiple cloud environments (AWS, Azure, GCE, vSphere, OpenStack, etc.) in a way that they are able to directly deploy applications with knowledge about the unique capabilities of each cloud. This allows the platforms to build the application environment specific to a cloud, without the application having cloud-specific awareness or the operations teams worrying about translation or interoperability issues.

 

The Rapidly Changing World of Platform Architectures

All of the platforms that Wikibon researched are five years old or less. Within that five year period, the market has seen significant shifts in the popularity and acceptance of open-source software, open-source communities (or foundations), the use of containers, and evolving container orchestration frameworks. The pace of change is so fast that we’re now seeing some platforms release their 2nd and 3rd generation architectures, often times completely rewriting significant elements to align to market demands or shifts in community sentiment. Many platforms are adopting the Go programming language for their internal systems. Other platforms are making significant changes to adapt to evolving container formats (e.g. OCI, Docker, rkt) or evolving orchestration and scheduling frameworks (e.g. Kubernetes and Apache Mesos).

Not every platform that Wikibon researched was commercialized based on open-source software projects, although every one of them uses popular open-source projects within the platform. In some cases, the entire platform can also be acquired or consumed as a set of open-source projects (e.g. HashiCorp’s tools; CoreOS tools) . In other cases, elements of the platforms are modular and those pieces are actively supported as open-source projects (e.g. Apcera NATS.io or Cloud Foundry BOSH or Lattice.cf projects). Wikibon is not focused on the extent of open-source software present in each platform, rather the focus is on the developer and operator experience. IT organizations can make an individual decision about how important open-source software is in their selection of a platform that meets their requirements and aligns to their internal skills.

At VMworld 2015, there was discussion about how today’s IT organizations were reacting to this pace of change and how they could evolve their organizations and skills to be better prepared to adapt to the upcoming changes.

 

 

Structured and Unstructured Platforms

In Part I of this research, we showed two architectural diagrams. In the Unstructured Platforms diagram, we highlighted the functional areas as well as the alignment of popular projects and technologies for each area. Wikibon did this because the projects for many of those areas could change rapidly over the next few years.

In looking at this architectural diagrams, it is critical for any company looking to invest in Cloud Native Application platforms to remember that application packaging, application staging, application delivery and application lifecycle management are a complex set of processes. The choice of whether to build all of these elements into a platform (unstructured), or acquire a more defined platform (structured) will be one of the most critical decisions made over the next 2-3 years. It will defined not only the types of applications that will be built to help the business, but how the organization is structured to deliver those Cloud Native applications.

In the Structured Platforms diagram, we highlighted the Developer and End-User view of the platforms, with many elements of the Unstructured Platforms down lower in the stack. This highlighted that many of those functional areas exist in those platform, but may not be visible except to Operations teams.

There is a term that is often used in platform discussions – “opinionated“. While technologists rarely lack strong opinions on how something should be built, this term is used to describe how much of the platform elements are included within any given platform. The more opinionated a platform is, the less the operator or end-user is expected to build in order for the platform to be functional and operational. Sometimes the term opinionated is used to specify how much choice is given to the elements used within a platform. Other times, the term opinionated is used as a way to describe the “undifferentiated heavy lifting” that is software functionality built into the platform and the end-user does not have to worry about maintaining. In either case, end-users must decide if they want their platform to have more of the architectural elements natively integrated within their platform, or they wish to have more choices about what elements can be added or swapped-out at a later time. In general, the structured platforms tend to be more opinionated, and hence include more integrated elements of a platform architecture included in their base technology packages.

 

Aligning The Organization and The Platform

Unlike hardware platforms for networking or storage where there might only be a few points of significant architectural variance between vendors (e.g. centralized vs. distributed processing), there are many different views on how platforms should be architected for application deployments. The industry views this as a spectrum of “levels of opinionation”, where some platforms are more opinionated than others. The level of opinionation highlights how much of the technology stack is defined by the platform vs. how much is defined or built by the end-user. As highlighted in this research, the structured platforms tends to have higher levels of opinionation.

The first key element is how a customer’s IT organization or business is organized. This research determined that different architectures can be a better fit for different companies, depending on how they build and deploy software. For example, companies in regulated industries or with a highly dispersed workforce are going to have different expectations for application delivery than a smaller company or one that is making frequent changes to a publicly visible application.

The second key element is the technical skills within the IT organization or business. Building modern, distributed applications is complicated. Operating a scalable, automated cloud platform is complicated. While neither of these statement is questioned within the industry, the ability for companies to master these skills is driving business-level differentiation across every industry. These are areas where companies are making significant efforts to either re-train their existing staff, or hire new skills into their organizations. This research highlights that different platforms can be a better fit than others depending on the existing skills within an organization, or an organization’s ability to hire critical skills.

The third key element is the existing applications within a customer’s portfolio. While Cloud Native applications and greenfield environments make for excellent “unicorn” case-studies, the bulk of the market still has varying amounts of legacy IT that must be considered. This reality has shifted the Platform discussion from one of diverse “polyglot” frameworks of modern languages to one that has to make serious considerations for Microsoft .NET and Java, the core languages within many Enterprise IT organizations. This doesn’t mean that modern languages and frameworks are not driving new innovation, but the polyglot language discussion appears to have shifted from a central design characteristic to one that is being addressed through direct containerization or other sandboxing mechanisms within the platforms. This research highlights how platforms are addressing both Cloud Native frameworks and existing frameworks.

The fourth key element is the granularity of policy management. Every platform, whether it’s structured or unstructured, can deploy and scale an application in ways that are fairly simple for development teams. But in order to move platforms into production for end-users, they need to be able to provide levels of granularity that are better than “Red” (stop) or “Green” (go). This is where policy creation, policy management and policy enforcement play critical roles for any platform. IT organizations must consider how policy management can impede their ability to innovate, as well as how well policy management will align to their organizational model.

The fifth key element is the customer’s willingness to work with open source projects and communities. While all of the platforms in this research as commercially supported by the vendors, some place a greater emphasis on interactions with open source communities. For some IT organizations, they are only concerned with documented features and APIs. For other IT organizations, they are evolving their skills to be more comfortable with the flexibility of open-source. If necessary, it is important for IT organizations to understand the level of awareness they will need to have with open-source communities to best leverage their platform choice.

Before looking at the individual platforms, we had the opportunity at VMworld 2015 to talk to some of the vendors that are creating these platforms during a panel discussion on Cloud Native Applications.

Reviewing the Leading Cloud Native Platforms

The following seven Cloud Native platforms were selected for this research based on market awareness, financial investment levels and strength of community involvement.

 

Apcera Hybrid Cloud OS 

Category: Structured Platform

Platform Homepage – http://www.apcera.com/continuum/

Vendor Strength: Highly-secure, policy-based platform that simplifies the deployment of Cloud Native applications across multiple cloud platforms.

Some platforms have been built within the last two years and have been able to start from a technology base that builds upon popular open-source projects, such as Docker and Kubernetes. Other platforms have been re-architected or re-written over time to address learnings that have been gained through operational experience. When Apcera CEO/Founder Derek Collison left the Cloud Foundry project in 2012, he wrote “PaaS is Not Enough“, summarizing his thoughts about what was needed within a modern application platform that abstracted resources between developers and operators. The result is the Apcera Continuum HCOS platform.

Apcera Continuum is designed to provide the platform with highly granular control over the functional areas between developers and operators. Policy-management is at the core of the platform. The granular control begins with multiple ways to authenticate users on the system (LDAP, Basic, Crowd, Google OAuth). The platform allows both custom applications and “apps-from-package”, which means that developers can either pre-bundle their code or the platform can determine dependencies and bindings based on platform-level policies.

Application staging is managed by a system of “Stagers”, which determine the required dependencies and services needed for a given application. Stagers can can be used to deploy to any portion of a workflow (development, test, production) and multiple-stagers can be combined to test broader aspects of an application (e.g. integrate with GitHub, SaaS apps, various tools, etc.). The Stagers support a wide variety of application languages and frameworks for Cloud Native applications.

The platforms does not provide native Microsoft .NET support at this time, although efforts to add support for the “Mono” project (cross-platform, open-source .NET framework) are on the roadmap. The platform can pull code from a Docker repository, but does not currently support staging applications directly from Dockerfiles.

The platform can be deployed to multiple cloud environments (AWS, vSphere, OpenStack, Softlayer, Azure, Google Compute Engine and bare-metal). Application visibility is centrally managed through Continuum, and can be expanded to a Hybrid Cloud architecture by deploying Instance Managers to individual cloud platforms.

Apcera Continuum is designed as a multi-tenant platform, with clear expectations of distributed teams. Functionality such as Semantic Pipelines, which acts as a proxy for Database services to prevent rogue operators, highlight that the platform is architected with strict security controls in place. Additional functionality is in place to hide network addressing from outside exposure.

While the Apcera platform does not have an open-source version, the team behind the platform does have considerable experience and expertise in building distributed systems. It is a platform that some companies may find as overly burdened by granular policies and control, but for those companies that require a strong focus on security and compliance, it meets many of the criteria for an Enterprise Cloud Native platform.

 

Apprenda Platform 

Category: Structured Platform

Platform Homepage – http://apprenda.com/platform/

Vendor Strength: Enterprise-focused platform, designed to help transition Enterprise customers with both Microsoft .NET and Java applications portfolios to a more efficient application deployment architecture. 

Apprenda Platform was designed with a focus on today’s Enterprise applications, not necessarily with a distinct focus on Cloud Native applications. The platform architecture was created with a goal of taking existing Enterprise applications, running on-premises, and bringing a PaaS-like experience to both the Development and Operations team. This direction led to the early focus on Microsoft .NET and Java applications, the most common frameworks for existing Enterprise customers.

For many years, Apprenda Platform held the distinction of being the on-premises PaaS that only managed Microsoft .NET applications, as well as the only PaaS that natively supported the management of Microsoft .NET applications. Over time Apprenda added support for Java applications and frameworks. The Apprenda platform is a 2nd generation PaaS that is approaching the goal of polyglot support in a different manner than it did with .NET and Java support. Instead of adding specific operations logic for each language or framework, it is allowing developers to package their applications in Docker containers and natively consume the PaaS resources via pushed Dockerfiles. Apprenda does have a relationship with Microsoft Azure that allows the Apprenda platform to be deployed as a Hybrid Cloud application within Azure, but that functionality was not covered by this research.

As a structured platform, Apprenda focuses much of the platform capabilities on delivering granular policies to the Operations team. These policies align to application onboarding and workflow, as well as monitoring, compliance and security. This policy-based approach aligns to the target audience, which are Enterprise companies that have an existing application portfolio and are focused on evolving to a platform-centric delivery model. This approach allows deployment, security and compliance policies to be centrally defined and administered, while allowing development teams to remain focused on pushing applications onto the scalable platform.

In moving towards a DevOps model, one of the challenges is building trust between Development and Operations team, who had previously been siloed from each other. While PaaS platforms simplify deployment of applications, the abstraction of resources can make troubleshooting more complicated. Apprenda platform attempts to reduce this friction by allowing both Development and Operations teams to have consistent visibility to platform operations (logging, metrics, etc). This is designed to give both sets of teams visibility into application problems, from the same perspective.

Like Apcera, Apprenda does not offer an open-source version of their platform. They do offer API integration into the platform for 3rd-party services, and the move to support Dockerfiles as an input will simplify how developers interact with modern application frameworks.

 

CoreOS Tectonic 

Category: Unstructured Platform

Platform Homepage – https://tectonic.com/

Vendor Strength: Building and managing secure, open-source, container-centric infrastructure for Cloud Native application deployments. 

Over the past 18 months, CoreOS has evolved from a company that was focused on delivering a secure version of Linux that was optimized for containers, to a company that is building a more vertically-integrated stack that is focused on delivering a broader framework to run Cloud Native applications. In April 2015, CoreOS announced the commercial launch of Tectonic, an integrated solution that is made up of several open-source projects (both from CoreOS and their ecosystem).

As a company, CoreOS is targeting the platform at emerging companies and business groups that are focused on building modern, scalable applications. They are not focused on legacy applications and legacy integration within the Tectonic platform.

As depicted in the Tectonic Architecture diagram, CoreOS is bringing together CoreOS Linux, multiple container formats and runtimes, a set of container orchestration frameworks (CoreOS etcd, CoreOS flannel and Kubernetes), and a management UI for the solution.

The platform follows a unstructured or semi-structured model, where individual tools are brought together to build a system. The system aligns to a DevOps model where there is little distinction (if any) between Development and Operations teams. Application staging and on-boarding is done through external Continuous Integration / Continuous Deployment (CI/CD) tools, and resource scheduling and monitoring is managed through Kubernetes. CoreOS tools such as ‘flannel’ and ‘etcd’ are tightly integrated with Kubernetes to deliver network routing and service discovery.

CoreOS highlighted the “Prometheus” monitoring platform as their recommendation for Tectonic at this time. They expect additional forms of monitoring to evolve within the Kubernetes framework over time.

Policy management is evolving in the Tectonic platform, primarily through extensions to Kubernetes. For example, multi-tenancy is managed through Kubernetes “namespaces”, and staging controls are managed through “labels”, which can guide Canary or Blue/Green deployment models. Along with the ability to separate the platform into distinct tools, the limited policy control embedded within the platform is why Wikibon identifies Structured vs. Unstructured Platforms.

 

Docker, Inc.

Category: Unstructured Platform

Platform Homepage – http://www.docker.com

Vendor Strength: An open platform for distributed applications for developers and sysadmins.

Docker emerged in 2013 as the container runtime that was previously used within the dotCloud PaaS platform. It established a new Linux container format (runtime, filesystem) as well as radically simplifying the creation and deployment of containers.  Docker, Inc commercializes some of the open-source projects created under the Docker umbrella, as well as being the largest contributor to most projects. Docker has expanded from the container runtime to now include projects for creating, packaging, securing, networking and clustering containers (Machine, Compose, Notary, Networking, Swarm). Docker also provides both a public and Enterprise repository to manage Docker containers – Docker Hub and Docker Enterprise Registry / Docker Trusted Registry. Support for Docker containers on Windows Server and Microsoft Azure platforms is currently in beta and early release-candidates from Microsoft.

Docker does not provide their tools as an integrated offering, similar to CoreOS Tectonic or HashiCorp Atlas. Rather they distribute them as a set of loosely integrated tools that are “batteries included, but removable“, an architecture exposed by Docker Founder/CTO Solomon Hykes, meaning that elements could be replaced by alternative tools from 3rd-party groups within the Docker ecosystem.

In larger environments, customers are beginning to look at container orchestration technologies such as Kubernetes or Apache Mesos to manage large-scale environments that require dynamic application characteristics.

While Docker tools are evolving to add pieces to a more vertical stack that begins to looks like a structured platform, it is primarily focused on helping developers package and deploy applications in a simplified manner. Docker expects their ecosystem to provide more advanced operational tools; an area that will need to mature and adapt to the unique nature of container-centric environments.

Docker has developed an enormous community of users and contributors, but the framework is still lacking a comprehensive policy management framework that will be required in large, complex organizations. They announced “Project Orca” (video) at DockerCon 2015, but this is still in the experimental/planning stages and a roadmap date has not yet been announced.

 

HashiCorp Atlas 

Category: Unstructured Platform

Platform Homepage – https://atlas.hashicorp.com/

Vendor Strength: Building tools and frameworks for building immutable infrastructure to enable DevOps teams and Cloud Native applications. Powering the software-managed datacenter. 

Similar to CoreOS, HashiCorp began several year ago with only a single tool (Vagrant). Over the past 18-24 months, HashiCorp has expanded the breadth of tools (Packer, Terraform, Consul, Vault) and are now evolving to offer a vertical solution called HashiCorp Atlas. While the tools can be individually consumed or deployed, Atlas brings them all together to create a system that aligns to the workflow pipeline for Cloud Native applications.

HashiCorp Atlas is a “workflow opinionated” system as opposed to a “technology opinionated” system. This means that the collection of tools is designed to be aligned to DevOps style workflows. It also means that the platform is agnostic to the underlying infrastructure (Cloud, VM, Container) or type of cloud (AWS, GCE, vSphere, OpenStack). The system of tools is aligned to technology-centric IT organizations and business groups that already have a DevOps culture of embracing automation and configuration management tools.

HashiCorp Atlas is a system that’s designed for companies or business groups where technology is a first-level concern. It will be adopted by companies that are focused on developing Cloud Native applications, and are already embracing high levels of automation and configuration-management.  It expects that customers are comfortable with GitHub and are interested in deploying and scaling resources across multiple cloud environments.

HashiCorp has a large and loyal open-source community which uses and supports their tools. Wikibon expects that this loyalty will move from using individual HashiCorp tools to embracing larger parts of the Atlas system over time.

 

Pivotal Cloud Foundry 

Category: Structured Platform

Platform Homepage – http://pivotal.io/platform

Vendor Strength: Creator / Leading-Contributor of the Cloud Foundry technology. Governs application lifecycles with a modern IT platform that accelerates software development without compromising operations.

Cloud Foundry began as a project at VMware. When Pivotal was spun out of VMware and EMC, the Cloud Foundry code was donated to the Cloud Foundry Foundation as a fully open-source project, with independent governance within the Linux Foundation. Pivotal Cloud Foundry is the commercial version of Cloud Foundry, delivered as software for on-premises usage, distributed by Pivotal. Pivotal also provides the platform via public clouds as an on-demand service, known as Pivotal Web Services.

Pivotal Cloud Foundry is a platform designed primarily to run Cloud Native Applications, although it has the ability to integrate with existing customer applications through specific “build packs” or “service brokers”. The platform allows developers to either push application directly to the platform via CLI (“cf push”), use the native web client (Pivotal Apps Manager) or integrate deployments with standard CI/CD tools. Support for also deploying directly from Docker containers is expected in Fall 2015. Developers are directly able to adjust the scaling requirement of deployed applications. Staging of application is managed via an isolation concept called “spaces”, where development teams can manage buildpacks and the pipeline of application deployments. Blue/Green deployment option are available to manage new updates and releases.

For customers writing applications in Java, Pivotal Cloud Foundry embeds commercial versions of the Spring Boot and Spring Cloud frameworks and design patterns. These frameworks include some of the design patterns from the NetFlixOSS team. The inclusion of the Spring frameworks helps to simplify operations for microservices-based applications. Wikibon considers the inclusion of the Spring frameworks within the Pivotal Cloud Foundry platform as a PaaS+ capability, as it moves beyond just native language support for developers, but simplifies how operators will onboard and operate the applications as they live on the Pivotal Cloud Foundry platform. While no specific technology delivers DevOps, this is an example where the embedded technology will remove friction between Dev and Ops, ultimately simplifying how new or existing applications are delivered to the business.

Operational teams can access the platform via CLI tools or through the Operations Manager marketplace. Logging and Monitoring tools integrated into the platform, and logs can be integrated with 3rd-party platforms (e.g. Splunk). Operations teams have access to a granular set of policy management tools to define how teams are organized, where applications are deployed, how resources are allocated, and which cloud platforms that Pivotal Cloud Foundry will run on top of.

Pivotal has a unique model that allows them to take the operational tools and experience that are originally built for the Pivotal Web Services (public cloud) platform and embed them into the on-premises Pivotal Cloud Foundry platform over time, allowing customers to leverage the Pivotal operational expertise. This is an important factor when end-users consider the learning curve required to build and operate a private Platform-as-a-Service. One example of this is the Application Performance Manager tool, which provides a granular-level of application visibility, similar to 3rd-party tools such as NewRelic.

Support for native Microsoft .NET frameworks and applications s currently in beta and will come in a Fall 2015 release, through the Pivotal and Microsoft contributions to the Cloud Foundry Foundation. This extension will be important to the Cloud Foundry ecosystem as .NET is a critical framework for many large Enterprise customers, and it will additionally unlock access to Microsoft Azure based services in the public cloud.

 

Red Hat OpenShift Enterprise v3 

Category: Semi-Structured / Unstructured Platform

Platform Homepage – https://enterprise.openshift.com/

Vendor Strength – Market-Leading open-source solution provider and top contributor to many open-source projects focus on Cloud Native applications.

Red Hat OpenShift Enterprise v3 is a 2nd generation platform that made a significant architectural shift between v2 and v3. Like many early PaaS platforms, earlier versions of OpenShift contained platform-specific implementations of resources management tools. This was necessary because tools and frameworks like Docker and Kubernetes did not exist in the marketplace. Maintaining homegrown software has advantages and disadvantages – more control over the architecture, but less leverage of engineering resources vs. open-source communities. With OpenShift Enterprise v3, Red Hat completely rewrote the platform and made an architectural decision to be more aligned to their corporate strengths in open-source contributions, making Docker and Kubernetes core elements of the architecture. Instead of continuing with proprietary software, Red Hat decided that it could leverage greater outputs for OpenShift by making significant contributions to both of those open-source projects.

Red Hat OpenShift Enterprise v3 is fundamentally a set of UIs (Web Console or CLI) that link Git, Red Hat Linux OS and tools, Docker and Kubernetes. Developers interact with the platform through existing tools that work with Git (Git, Enterprise GitHub or public GitHub) and through the integrated Docker Hub within the OpenShift platform. The platform contains “Source-to-Image” (S2I) logic which transforms developer’s source code into running Docker containers, leveraging they Docker layered image format that is standard within the Openshift platform..

The operations teams work directly with either Docker or Kubernetes CLIs to manage the underlying platform for scalability and health. Policy management is done in several places within the platform, with the primary focus areas of user-authentication for “Jobs”, management of the internal Docker Registry artifacts

Red Hat OpenShift can also be acquired or consumed through the Red Hat OpenShift Online platform, or via OpenShift Origin as purely open source software.

Summary of Cloud Native Platforms

The original premise of this research is that Cloud Native platforms can simplify and accelerate a company’s ability to bring business-differentiating applications to market. This research highlights that there are a number of platforms that have made significant process in delivering technology that can assist companies down that journey. But the diversity in the platforms is fairly significant in many areas. IT organizations will need to look at how critical multi-language support, policy-management, integrated operational tooling and open-source frameworks are to solving their business challenges.

The following table summarizes the alignment of each platform to Wikibon’s key characteristics for Cloud Native platforms. While there will always be unique customer situations, it is Wikibon’s opinion that certain platforms are better aligned (architecturally) to certain types of IT organizations or application portfolios. There is not a single platform that is a perfect fit for all situations. It is a matter of finding the best fit for the size and complexity of the organization, the company’s application portfolio, the skills of the Development and Operations teams, and how comfortable the team is with open-source technologies.

Ideal Customer Organization: This category looks at the customer type that the platform is best aligned. “Enterprise; SP; Gov’t; Multi-Tenant” are large customers with a broad mix of applications and higher security and compliance requirements. “Highly Technical; Products” are smaller engineering teams or companies where the technology is their core product.

Required Technical Skills: This category identifies the core skills needed to operate the platform as well as have interaction with the application development teams. “Modern Linux Developers” = understanding of common Linux SysAdmin tools and operations. “DevOps” = currently organized as an integrated Dev + Ops team, with high levels of automation and config-management, as well as employing CI/CD principles for application development.

Existing Application Portfolio: This category identifies the application types and patterns that each platform is optimized to support. “Web-Scale Cloud Native Apps” = 12factor, container-centric, microservices-based applications using modern languages and frameworks. “Enterprise Cloud Native Apps” or “Cloud Native Applications” = 12factor, container-centric, microservices-based applications that are inclusive of Java frameworks.

Integrated Policy Management: This category identifies the level of policy-management capabilities are embedded within the platform vs. requiring external 3rd-party tools. “Advanced” = multiple levels of policy across multiple functions within the platform. “Medium” = policy is available in 2 or more areas of the platform. “Low” = granular policy is not native in the platform and is expected from 3rd-party tools.

Open Source Interactions: This category highlights the level of interaction an customer needs to have with open-source communities to manage features, roadmaps or support. It also highlights where elements of the platform are available individually via open-source communities.

Action Item: Every start-up and Enterprise IT organization will need to embrace Cloud Native applications as a business differentiator within the next 12-24 months. Having the right platform as the foundation of that development is a critical IT decision. But choosing the right platform can be complicated. Using the five key decision-criteria outlined in this research to align business needs with technical needs will help ensure that the business make the right decision and accelerates their transition to differentiating their business.