Kubernetes, the open source container orchestration tool, has become the defacto choice for enterprises looking to scale their applications with production-grade containerization. According to a recent Datadog survey, its adoption rate has gone up by 10% in 2018.

Kubernetes is now distributed with Docker and available on the major public cloud platforms including AWS, Azure, and GCP And if you want to tinker with the source directly you can find instruction on Github here. Kubernetes is one of the top ten repositories being used on Github today and the community is exploding.

Why Kubernetes?

Google has been using Kubernetes in production for 15 years. This time-honored proof of working in Google’s web-scale environments makes is a solid fit for enterprise adoption. Over the years it has had the care and feeding of some of the top developers at Google. Choosing to be open source was brilliant. Now adopted across competing cloud providers, Kubernetes is sometimes referred to as K8s (K with eight letters and then “s”). The open source project is now hosted by the Cloud Native Computing Foundation (CNCF) and available here. As more enterprises adopt K8s, it has become  the currency for migrating, managing, and scaling containerization across the hybrid cloud landscape.

Containers and Kubernetes

Containers can be deployed and run just about anywhere without any orchestration from Kubernetes or other orchestration tools. Containers enable developers to modularize the functionality of extremely complex application architectures as microservices with dedicated roles that support digital business for the enterprise. You can essentially start and stop containerized services independently and manually. Orchestrating them with automation requires a little more sophistication.  

Kubernetes does the orchestration and management of containers so that they can be used in a production environment with the proper set of controls. You can essentially describe the desired state of how you want the containers to run and where and what to do if something goes wrong. Kubernetes then does all the work to make sure that this desired state is always kept up and running.

Kubernetes in production includes monitoring, networking, and load balancing so that when demand increases, the application architecture developed with containers scales and meets the demand. Kubernetes also provides a way to update to container versions in a continuous delivery model and rollback to a previous state when necessary.

For a quick summary overview, check out this video.

For a more detailed rundown, go here: What is Kubernetes?

CloudBolt and Kubernetes

CloudBolt supports Kubernetes orchestration for enterprises in the following ways:

Several years ago, a lot of enterprises moved some of the heavy lifting of managing their business critical applications from data centers to software-as-a-service (SaaS) solutions, such as Salesforce and Microsoft 365. These applications are hosted in massive cloud environments and enterprises pay for subscriptions essentially by headcount.

Salesforce and Office 365 specifically require a pretty complex application architecture that runs with various components that would be a nightmare to manage locally in a data center by any of today’s IT standards. Another disrupter is ServiceNow, a SaaS solution that has displaced on-prem IT ticketing systems for many organizations. In general with modernization, the idea of a SaaS solution that reduces the IT footprint of capital expenditures (CapEx) to operating expenses (OpEx) is very appealing to most enterprises.  

SaaS vs On-Prem

In many cases, IT departments turned to SaaS because the on-premises solution required hardware, installation, and maintenance. Typically, for an enterprise application you would have some sort of “engine” that was the main application, and then you would have to install one or more database servers, a web server, load balancing, or high availability with redundancy.  

To add to the complexity, you had to do the upgrades yourself and, depending on the solution, you could have licensing and third-party applications with separate licensing of its own. It was no joke..

With a SaaS alternative, all of that goes away. The updates and maintenance often is left up to the service provider. Although you don’t have control of the environment, many of these SaaS providers simply provide a service level agreement (SLA) that mitigates any fear of downtime. With on-prem, you got the classic “war room” of finger pointing for why something did not go right with an upgrade or your database exceeds capacity without warning. With SaaS, however, you can rely on (or blame) someone else.

A Hosted VM—The Best of Both Worlds

For the purpose of this comparison, we’re considering a hosted VM as a solution that includes all of the complexity of the application in a single virtualized appliance. In this case, you do not have to configure or install the different components on separate operating systems. Rather, you provision a designated VM with the capacity to run the virtual appliance as a single unit. You can even provision the VM in a private or public cloud environment that you are paying for as a service. In this case, you pay for part of the running environment as an operating expense and the rest is paid for based on the cost of the appliance.

If the vendor of the appliance software can bill you on a subscription basis, then Voila! You have the best of both worlds. You’ll be spending on an as-needed basis only when you’re running the solution and paying for a subscription based on the value you receive. There’s no heavy lifting of configuring a complex application environment and you control where you host the solution. Instead of being subject to the SaaS provider’s ability to be secure and guarantee service levels, you control all of it with a hosted VM. You can even customize your environment a lot easier than you can with most SaaS applications.

Are there drawbacks? It’s hard to think of much, other than the fact that you have to provision and install the VM somewhere. If your solution is an enterprise hybrid cloud platform like CloudBolt, the users and administrators are very comfortable with installing what is called an open virtual appliance (OVA) that includes all the files necessary to run the application. Other vendors might suggest that it’s easier to provide a free subscription with a SaaS solution.