Riding The Coattails Of Google Kubernetes And AWS Lambda

There are individuals and companies that create whole new technologies for their own consumption and that sometimes open source them for others to help steer their development and fix their bugs. And then there are still other companies that polish these tools, giving them some enterprise fit and finish, and thereby make it possible for others to deploy a particular technology without having to have PhDs, who are not available anyway, on staff.

From the enterprise perspective, the Apache web server and related Tomcat application server needed its Big Blue, the Linux operating system needed its Red Hat, and the Hadoop data analytics platform needed its Cloudera before it was really possible for all but the largest and most savvy organizations to put them into their datacenters. So it is with every new technology, and therefore so it is with the Kubernetes container management system from Google and the Lambda serverless application platform from Amazon Web Services.

There are many different ways to consume Kubernetes, which was inspired by the Borg container and cluster management system inside of Google, including using the container service based on Kubernetes that runs on the Cloud Platform public cloud created by Google to take on AWS and Microsoft Azure, as well as various private cloud implementations of Kubernetes including CoreOS Tectonic, the Kubernetes layer atop the Mesos cluster scheduler, Red Hat OpenShift, and the Murano overlay for Mirantis OpenStack. Platform9, an early commercializer of OpenStack that provides that cloud controller as a software service for both public and private infrastructure, has thrown its hat into the Kubernetes ring with its Managed Kubernetes, a companion Kubernetes service that is not dependent on its OpenStack implementation but which is sold as a service like Platform9’s OpenStack management service.

If VMware was able to start from scratch to create a new revenue stream and business model and a new platform stack, it might have created something like Platform9. And that stands to reason, since many of Platform9’s founders hail from the server virtualization juggernaut. Oddly enough, the Platform9 Managed OpenStack looks less like the next-generation Photon container platform from VMware and more like the vSphere Integrated OpenStack, which mashes up the ESXi hypervisor with an OpenStack controller. With the recently announced Platform9 Managed Kubernetes, the upstart software platform provider is taking on VMware’s Photon container platform for automating Docker containers with its own implementation of the Kubernetes platform, run as a service and not sold as a separate licensed program.

The Managed Kubernetes service went into beta testing in June 2016, and is now generally available. It is a “pure play” Kubernetes stack that is built from open source code and that is run on bare metal Linux servers as well as Linux-based VMs on public or private clouds. It is not Kubernetes running atop OpenStack, which Platform9 already sells, and there is no dependency between the two Platform9 services. These physical or virtual Linux servers have a Platform9 agent installed, and the Kubernetes service running at Platform9 manages them remotely, and the interesting bit is that the Platform9 Managed Kubernetes allows for a mix of public and private and bare metal and virtual servers to have containers thrown at them and managed as a giant pool of capacity. None of the captive Kubernetes services being offered by the big public clouds can do this – or they have not decided to do this as yet. The combination of Azure on the cloud and Azure Stack in the datacenter from Microsoft gets close for virtual infrastructure, and in theory Microsoft could put the same container service on them; you can do the same with VMware virtualization across AWS and private clouds, and you can sort of do it with private Kubernetes and Google Cloud Platform. But none of the abstractions are the same across the different sets of infrastructure. With Platform9, anything that runs Linux can be managed as OpenStack resources using one service or Kubernetes with Docker containers with the other service.

The interesting thing is that Platform9 is not mixing the two. Some people argue that Kubernetes should be atop a controller, such as Mesos or OpenStack, and others say that OpenStack should just be another containerized application running atop Kubernetes. Some say make yourself happy and do it either way.

“We debated that when Managed Kubernetes was about to go beta last year,” Madhura Maskasky, co-founder and vice president of products at Platform9, tells The Next Platform. “One of our internal discussions was around what the deployment model should be, and OpenStack Magnum does let you apply orchestration frameworks like Kubernetes to OpenStack. But we realized that there are a significant set of customers that are just interested in Kubernetes, and they want to deploy it on bare metal servers for performance reasons. So it did not make sense to complicate the stack by making OpenStack a requirement in these scenarios, and we did not see OpenStack adding a lot of value there.”

If customers do deploy the OpenStack and Kubernetes services, they have a single pane of glass and set of management APIs from Platform9 to control freak them both as well as a unified multi-tenancy mechanism. Customers could deploy their own containerized OpenStack on top of the Managed Kubernetes service, and conversely, they could run Kubernetes as an application layer in virtual machines under the guidance of the Managed OpenStack service – but Platform9 is not supporting this yet. (An OpenStack cluster looks like any other public cloud provider based that Platform9 supports as far as Kubernetes is concerned.)

The Managed Kubernetes service and the Managed OpenStack services are licensed on a per-socket basis on physical servers, with an annual fee of $1,500 per socket for either service. On virtualized infrastructure, Platform9 charges $150 per virtual CPU (vCPU) exposed by the hypervisor; this implies that the average processor in an X86 socket has ten threads, which it probably doesn’t in reality. It looks like those running on the cloudy infrastructure are paying a higher price, given that a socket can have 12, 16, 18, 20, 22, or 24 cores these days, and soon 28 cores, and with HyperThreading on, double those to get a reckoning of vCPUs after you take out a core or two for managing the underlying hypervisor. All of the major Linux distros and a few of the minor ones are supported by Platform9 for either the OpenStack or Kubernetes services.

The Managed OpenStack service went generally available in early 2015, and Platform9 has had two rounds of funding bringing in a total of $14.5 million from Redpoint Ventures and Menlo Ventures to get the company rolling and moving faster. Platform9 has 46 employees now and 50 customers as 2016 came to a close, four times what it had when the year began. The customer mix is across every industry and company size, and the one thing they all have in common is that they are wrestling with complexity and they are sick of it. Most of these customers, says Maskasky, have a significant number of virtual machines and have medium to high churn rates for those VMs as application pop in and out of existence or are upgraded. Splunk, Cadence Design, BlueCross BlueShield and some very big Fortune 500 companies that do not want to be named publicly are some of Platform9’s marquee customers.

On OpenStack, there has been a barrier to doing multi-cloud implementations because virtual machine image formats are different from cloud to cloud. And containers – or more precisely, Docker containers, present a single runtime abstraction layer for applications on any public cloud. OpenStack tends to be used in private clouds, but with Kubernetes, the intent from the early customers is to use this service to go multi-cloud, says Maskasky. This is exactly what Google wanted when it open sourced Kubernetes, and it wants for customers to use their own Kubernetes distro internally and its Container Engine service on Cloud Platform on the public cloud. Its other option was to let Docker, the software company, eat the container world like Hadoop ate data analytics and Spark ate in-memory processing. At this point, all of the 20 beta testers for the Managed Kubernetes service have said that want to run infrastructure internally plus use at least one public cloud.

The other container management systems, like Docker Swarm, or the cluster managers, like Mesos equipped with Kubernetes on top, could also be offered as a managed service by Platform9. But don’t hold your breath.

“The research and development team had several debates on this,” says Maskasky. “We believe at this point, for multiple reasons, that Kubernetes is going to be the winner in the container orchestration tools war. When we evaluate a framework, we look at product maturity, enterprise adoption, and community strength. And in all of these areas, Kubernetes significantly outshines the other two main competitors, Mesos and Docker Swarm. Mesos has been very successful but in the niche area of big data, but has not really extended beyond that. Kubernetes was designed to be a true general purpose container orchestration platform. A new version of Kubernetes comes out every three or four months, and a tremendous amount of new capability comes out then. The community is moving at a fantastic pace, and the amount of built-in support that Kubernetes offers for automating lots of day-to-day operations that developers are used to doing manually is high. And, as a startup, you have to focus. So we don’t think we will be adding a Managed Mesos or Managed Docker Swarm service at this time, but you never say never.”

Breaking Down Lambda With Fission

Imagine a world where applications are just algorithms executing on datasets, and all of the underlying infrastructure and middleware to make it all work is abstracted away. This is precisely what AWS has envisioned and has implemented with its Lambda “serverless” platform cloud and related data services like Kinesis and Redshift. (We discussed this at length last year in First, Kill All The Servers.)

But there is a problem with Lambda, and it is the dreaded, old vendor lock in.

“AWS really started the serverless movement with Lambda, and today it is probably the most popular function as a service platform out there today,” says Maskasky. “But one of the issues is that it locks you down even tighter into the AWS ecosystem. Lambda is only as powerful as the number and type of triggers that it supports, and all of these are from within the AWS ecosystem. So we heard from some of our developers that some of our customers want to consume Kafka events in Lambda, but AWS only offers Kinesis. Fission is designed to be the de facto open source alternative to Lambda.”

Maskasky says that the Fission project will start out by supporting microservices running inside of Docker containers controlled by Kubernetes, but it will be built out to deliver a full suite of functions. The good news is that the containers underlying Fission will be abstracted at a higher level, making it even easier to consume make use of Kubernetes.

The difference with Fission is that it will not be limited to the Platform9 implementation of Kubernetes, but will be available on OpenShift, Tectonic, and other platforms that support Kubernetes container orchestration.

Fission is just an open source project for now, and there is no fixed time to commercialize it and sell it as another Platform9 service, but it should be ready by the end of this year. A lot depends on what the Fission community wants and how they contribute. The point is that Fission will be a Lambda clone and be able to take on AWS on its own home iron and using its own services and also be able to span multiple clouds as well as private clouds. And it will be a better, more abstracted kind of platform cloud.

“The platform cloud movement was started because it was thought that developers should focus on code only and all of the infrastructure should be abstracted away,” explains Maskasky. “We think that the combination of microservices and function as a service is an even more powerful way of delivering PaaS, and that this is going to evolve into the next generation of PaaS. Right now, Lambda is restricted to a small set of code that is triggered by some event, but we think that with Fission we want to evolve this to be the de facto platform that developers use.”

When your product has platform in the name, it is a natural thing to want. (Wink.)

Sign up to our Newsletter

Featuring highlights, analysis, and stories from the week directly from us to your inbox with nothing in between.
Subscribe now

Be the first to comment

Leave a Reply

Your email address will not be published.


This site uses Akismet to reduce spam. Learn how your comment data is processed.