Telekube Offers Remotely-Managed ‘Private SaaS’ Kubernetes
Software-as-a-service doesn’t work for everybody, an issue that Gravitational takes on with its managed Kubernetes service Telekube.
Local data laws in many parts of the world prevent companies there from using SaaS software that runs on Google, AWS or other public clouds. The same holds true for some highly regulated industries within the United States.
Telekube is designed to allow software vendors to sell to these companies. It enables them to continuously deploy and manage their software on infrastructure that they do not control, such as customers’ private clouds, anywhere in the world, explained Gravitational CEO Ev Kontsevoy.
His first company, the email service Mailgun, was acquired by Rackspace in 2012. While working several years for Rackspace afterward, he saw the recurring problems customers encountered: They liked the low cost and hired management of software services, but either wanted to retain control over their data in the United States or local laws elsewhere in the world required that data remain within their own countries.
Apps Should Follow the Data
“While we were at Rackspace, we saw companies selling their software on Amazon, but they wanted to sell their software to Rackspace customers. But customers would say, ‘We want your software here because our data is on Rackspace.’ There was this constant push and pull that’s very common in the world of SaaS. Applications need to follow data, not the other way around,” Kontsevoy said.
Gravitational initially focused on delivering software in the cloud and on-premises from a single code base. It began by offering what it calls private SaaS for enterprise private clouds and making possible remote continuous deployment across multiple infrastructure vendors.
Kubernetes proved key to the effort to make applications portable.
Kubernetes provides a standardization layer that enables moving a typical application’s dozens of microservices, half a dozen databases and multiple monitoring and logging tools from one environment to another, he said.
“We take our customers’ applications, put them on top of Kubernetes — and it’s very good at running legacy software — then we use our own Kubernetes tooling to move them like a railroad car,” he said. “It doesn’t have to be AWS-specific or bare metal-specific. If it runs Linux, it automatically runs on Kubernetes. If it runs on Kubernetes, we can make your application continuously deployable into any third-party cloud.”
That means third-party resellers, such as system integrators, can resell and manage applications internationally, where latency and local data-retention laws had prevented sales of U.S.-based SaaS products. Other Kubernetes service providers focus on internal use, while Telekube allows vendors to manage software in customers’ data centers, Kontsevoy said.
They can pair with a hosting provider in Europe, say, or set up specific environments for those customers. Kubernetes scheduling allows the customer to increase utilization of the infrastructure they already have, allowing them to reduce their infrastructure footprint and save money, too.
Kubernetes On Autopilot
Telekube is a thin layer running on top of a Linux operating system and below Kubernetes. This layer is managing Kubernetes configuration, keeps Kubernetes healthy by continuously monitoring it, provides infrastructure-specific extensions and cluster-level snapshots and easy version upgrades.
“We call it ‘Kubernetes on autopilot’ because it removes nearly all operational overhead of running Kubernetes clusters,” John Bishop, head of marketing at Gravitational.
Telekube doesn’t do anything to Kubernetes itself. The tools prepare third-party infrastructure for reliable Kubernetes deployment, Kontsevoy said.
Its demo video explains that a file called an “application manifest” stored in a YAML file in the resources folder is the only TeleKube-specific file. It contains the definitions for pods and services and the hardware requirements of the application and the infrastructure options such as AWS, Azure or bare-metal servers. The rest is standard Kubernetes.
https://youtu.be/ZY0QuVPCP6M
Running a “Telebuild” command creates a self-contained tarball that is all you need to run a multi-tiered application in a variety of environments. The tarball includes Docker images, Kubernetes resources, and a graphical installer that customers can use to install in their own private cloud or bare-metal servers.
The second component of Telekube is SSH infrastructure, which allows Telekube users to reliably connect to behind-the-firewall environments and enforces cluster-specific infrastructure access rights, such as restricting SSH access to a specific Kubernetes cluster and even perhaps only to a database server.
This SSH layer of Telekube has been open sourced as Teleport under an Apache license. Teleport integrates with customer identity management tools and automatically configures kubectl and SSH jump-hosts for accessing remote clusters.
https://youtu.be/bprRpX-4R_0
“Today, when vendors sell to third parties, they basically throw it over the fence and hope it works,” Kontsevoy said. “We allow you to create Kubernetes clusters on the other side of the fence and connect it …[for] continuous deployment, continuous updates and customer support.”
