Supergiant Blog

Product releases, new features, announcements, and tutorials.

Deploy a MongoDB Replica Set with Docker and Supergiant

Posted by Ben Hundley on July 19, 2016

Despite a number of annoying challenges, it is totally possible to run distributed databases at scale with Docker containers. This tutorial will show you how to deploy a MongoDB replica set in 5 steps using Docker containers, Kubernetes, and Supergiant.

NOTE: This tutorial was depricated when Components were removed in version 0.11.x. This tutorial is valid for Supergiant version =< 0.10.x.

About the Tools

Docker is much-loved for bundling applications with dependencies into containers. I’m going to assume you already have knowledge of Docker, or you wouldn’t be reading this tutorial. We’re going to use the official MongoDB container already on DockerHub.

Kubernetes solves many container orchestration challenges for us, including networking (for clustering) and external storage (for state and data persistence). However, the sequence of Kubernetes commands needed to deploy a clustered application with storage is far from straightforward. We’ll use Supergiant to solve these problems.

Supergiant solves Kubernetes complications by allowing pre-packaged and re-deployable application topologies. Or, in more specific terms, Supergiant lets you use Components, which are somewhat similar to a microservice. Components represent an almost-uniform set of Instances of software (e.g., Elasticsearch, MongoDB, your web application, etc.). They roll up all the various Kubernetes and cloud operations needed to deploy a complex topology into a compact entity that is easy to manage. If you don’t already have Supergiant running on AWS, you can do this pretty quickly from the Install Supergiant page.

So let’s get down to business. This tutorial will use the Supergiant’s API directly with cURL for clarity on all the configuration and inputs, and we’ll have a running replica set in just 5 steps.

Step 1: Create an App

An App allows you to group your components. For example, you might have an app named “my-site-production”, where one of the components is “my-mongodb”.

curl -XPOST $API_HOST/v0/apps -d '{
 "name": "test"

Step 2: Create an Entrypoint

An Entrypoint represents a cloud load balancer (such as an ELB on AWS). When you create components that expose network ports, you can optionally allow external access by assigning them to entrypoints, which then gives the component a publicly-reachable address. This will allow us to communicate with MongoDB from anywhere outside of the Kubernetes cluster.

Note: we’ll do this for our tutorial, but if you don’t need external access, it is smarter to leave communication on the private network by just using the private address without an entrypoint.

curl -XPOST $API_HOST/v0/entrypoints -d '{
 "domain": “"

Step 3: Create a Component

The component contains only 2 attributes: name and custom_deploy_script. Custom Deploy Scripts allow components to extend the standard Supergiant deployment flow. The deploy script used here is supergiant/deploy-mongodb, which configures a replica set based on the component information.

curl -XPOST $API_HOST/v0/apps/test/components -d '{
 "name": "mongo",
 "custom_deploy_script": {
   "image": "supergiant/deploy-mongodb:latest",
   "command": [

Step 4: Create a Release

A Release holds all the configuration for a component. You can think of it like a commit to a git repo. Creating new releases allows you to adjust configuration, and deploy changes when needed.

curl -XPOST $API_HOST/v0/apps/test/components/mongo/releases -d '{
 "instance_count": 3,
 "volumes": [
     "name": "mongo-data",
     "type": "gp2",
     "size": 10
 "containers": [
     "image": "mongo",
     "command": [
     "cpu": {
       "min": 0,
       "max": 0.25
     "ram": {
       "min": "256Mi",
       "max": "1Gi"
     "mounts": [
         "volume": "mongo-data",
         "path": "/data/db"
     "ports": [
         "protocol": "TCP",
         "number": 27017,
         "public": true,
         "per_instance": true,
         "entrypoint_domain": ""

Since the release is the real meat of the matter, I’ve highlighted the parts that can be adjusted without altering the actual topology. First, there’s the volumes section, in which the name, size, and type of EBS (hard drive) can be edited. Then, cpu and ram, both of which control the allotted min/max (or reserve/limit) range for each instance of the component. The mounts section corresponds to volumes, so make sure that the volume value matches the name used for the drive.

Step 5: Deploy

This will deploy the Component as outlined by the Release.

curl -XPOST $API_HOST/v0/apps/test/components/mongo/deploy

When the deploy finishes, you can retrieve the assigned address of each Instance of the component like so:


curl $API_HOST/v0/apps/test/components/mongo/releases/current/instances/0


 "id": "0",
 "base_name": "mongo-0",
 "name": "mongo-020160715200942",
 "status": "STARTED",
 "cpu": {
   "usage": 7,
   "limit": 250
 "ram": {
   "usage": 36270080,
   "limit": 1073741824
 "addresses": {
   "external": [
       "port": "27017",
       "address": ""
   "internal": [
       "port": "27017",
       "address": "mongo-0-public.test.svc.cluster.local:27017"

Using the external address of the first instance (highlighted above), we can connect to the MongoDB shell remotely (from your local computer for instance) like so:


Your output upon connecting should look like this (the important part being the prompt, rs0:PRIMARY>, confirming the replica set is configured):

MongoDB shell version: 2.4.10
connecting to:

Note:  if you’re looking to deploy larger, sharded MongoDB clusters, you could use the following layout:

  • Component for each shard (optionally as a replica set), just as defined above. Runs the mongod process (see command section of the container definition).

  • Component for the config server replica set. Runs mongod with the --configsvr option.

  • Component for the routing layer. Runs mongos.

View Deploy a Sharded Cluster in the MongoDB manual for an overview of the setup.

And there you have it -- a MongoDB replica set running as containers, with data stored reliably on detachable external drives.

This setup can be resized at any time (CPU, RAM, or disk; volumes can be resized), by creating a new release that defines the new resource allocations you want. Supergiant will then gently rebuild each container upon deploy.

Keep reading

Why Join the Cloud Native Computing Foundation

Posted by Mark Brandon on June 20, 2016

Why Qbox joined and why you should consider it, too

As announced today by the Linux Foundation, Qbox has joined the Cloud Native Computing Foundation. The CNCF is a collaborative project of the non-profit Linux Foundation that brings together market participants in the containerization space to formulate and promote standards.  

Seeded in 2015 when Google contributed the Kubernetes project, CNCF now includes dozens of companies across the globe. By working together, the participants hope to drive the business value of Cloud Native applications like Kubernetes, Prometheus, Docker, Rocket, and the Open Container Initiative and to work toward a more hardware-agnostic future.

Qbox decided to join because our Supergiant project is based on Kubernetes, the most prominent project of the CNCF. Supergiant seeks to extend the benefits of containerization to stateful distributed apps. We created it to manage our Hosted Elasticsearch business, achieving eye-popping performance improvements while cutting our AWS bills in half

However, it can just as easily be extended to other NoSQL technologies like Couchbase, Redis, and MongoDB. (Speaking of MongoDB, if you’re attending MongoDB World (#MDBW2016) next week in New York City, come visit the Supergiant Core Team at Booth #22… you may also use the sponsor code “Supergiant20” to get 20% off your registration.)

By joining with CNCF and The Linux Foundation, we’ll be in a position to learn about best practices in this skyrocketing space, participate in events, network with other inter-operable companies in the space, and possibly contribute or otherwise influence the roadmap of these groundbreaking projects. Without organizations like these, technologies might go back to the bad old days when for-profit corporations would spend years in a standardization tug of war. Competing agendas pulled new technologies in directions that were not always mutually beneficial, hampering adoption and holding the future back. Recall the operating system wars of the 1990’s, which started with half a dozen or more proprietary server OS’s. Today, Linux is the undisputed champ in the enterprise.

Of course, managing these non-profit projects that are built around freely downloadable software is expensive. Companies that make or use these technologies should consider giving back by joining the CNCF, contributing code, or sponsoring CNCF and LF events. Just as with movies and music, if the creatives making the art never get paid, we’ll have less of it.

Keep reading

Supergiant Shows DB Containerization at MongoDB World

Posted by Adam Vanderbush on June 17, 2016

Supergiant will join other NoSQL experts at MongoDB World in New York to introduce their new open-source container orchestration system on June 28 and 29. MongoDB World is a leading technology conference that focuses on database best practices and networking with peers and industry professionals. Supergiant is the first production-grade container orchestration system that makes it easy to manage auto-scaling, clustered, stateful datastores.

Supergiant began in 2015 when the team at needed a production-ready, scalable solution for their Hosted Elasticsearch Service. After massive initial internal success, it was refined to easily launch and manage any containerized application. Supergiant solves many huge problems for developers who want to use scalable, distributed databases in a containerized environment.

Come visit us and get some swag

Supergiant Lego Characters

Built on top of Kubernetes, Supergiant exposes many underlying key features and makes them easy to use as top-layer abstractions. A Supergiant installation can be up and running in minutes, and users can take advantage of automated server management/capacity control, auto-scaling, shareable load balancers, volume management, extensible deployments, and resource monitoring through an effortless user interface.

Want a shirt? We have hundreds.

Supergiant T-Shirts

Supergiant uses a packing algorithm that typically results in 25% lower compute-hour resources. It also enhances predictability, enabling customers with fluctuating resource needs to more fully leverage forward pricing such as AWS Reserved Instances.

Supergiant is available on Github. It is free to download and usable under an Apache 2 license. It currently works with Amazon Web Services. Google Cloud, Rackspace, and Openstack are next on the roadmap. Supergiant is a member and contributor to The Linux Foundation and the Cloud Native Computing Foundation.

Keep reading

How to Calculate Kubernetes Cost Savings

Posted by Mike Johnston on June 9, 2016

In this series, we have covered a handful of important business topics that can be tackled with container management and Kubernetes. We’ve talked about how a business can save money. We’ve answered why your architecture is important to the bottom line. And we’ve covered how Kubernetes and Supergiant can make the transition to containerized application infrastructure much easier.

Today I want to show you how to calculate the real cost savings of a switch to Kubernetes.

We will add up the real numbers that a well-configured cluster can produce. We will use Amazon Web Services in our examples, but these figures would look similar across many cloud providers. You should also get a good idea of the type of on-premise hardware savings you can expect.

I will cover the cost of running your applications on bare metal, vs. virtual machines, and vs. Kubernetes. When Kbernetes is implemented well, its infrastructure and support savings will arm your business with the means to lower prices, improve support, and give better performance to your customers.

Enter our hero!

Let’s set up a fictional scenario. Luh Elephant, Inc. is a small company that uses AWS to provide on-demand PostgreSQL database instances for customers. Since they offer full instances, the customers are very happy with the database performance they receive. However, full instances get expensive, and the price gets passed along, so customers have begun to gripe about prices.

Enter the competition!

Several competitors have also begun to offer postgres on demand but at much lower prices. Luh Elephant, Inc. suspects the use of containers, virtual machines, or some magic, but they have also noticed their competitors’ horrible performance. Luh Elephant wants to make a change to compete.

Alas, many customers are beginning to choose these cheaper alternatives, so here is the rub: how will our heroes offer competitive pricing and still meet or exceed their own current performance standards? Can they really lower prices and maintain the experience and performance their customers love and deserve?

We can answer this. With math!

First, let's take a look at the infrastructure currently used to run Luh Elephant, Inc. They currently have 300 customers, and the top 100 customers are on pricey 3-server clusters. All servers for this example will be 4-core servers. In reality, the customer pool would be more diverse, but for simplicity’s sake, this will do.

This is the current hardware monthly spend of Luh Elephant, Inc. assuming AWS m4.xlarge class on-demand instances.

CustomersServersTotal Cost
200 (1 server clusters)200$34,894
100 (3 server clusters)300$52,341

Pricing data:

But what about Reserved Instance pricing?

RIs are a natural first step to lower spending, so let’s try that calculation first.

Academically, RIs get “1 year, partial upfront” pricing on all instances, and Luh Elephant could reduce their costs 41% to about $51,110 per month. However, reality has thrown our heroes a curveball: due to the unpredictable nature of their business, they cannot predict and reserve all needed instances for the next year.

Simply switching to a RI strategy hasn’t lowered costs enough. Getting the full amount of savings has not actually come to fruition, and in some cases, the competition’s pricing is still 50% lower. Even with a perfectly executed reserved instance scheme, the math is tight.

So, what other options do we have to reduce costs?

What has been plaguing Luh Elephant this whole time is a common problem to many organizations: one major application per server. This gets especially infuriating from a cost standpoint when servers sit underutilized or (gasp!) idle most of the time. Cramming more applications onto a server to get more value will cause all kinds of performance and noisy neighbor problems without some clever management in place. 

We need to better utilize the hardware we pay for and, by proxy, the energy footprint of our businesses.

Enter the Options

Option 1: On-premise virtual machines

This is a highly viable option for a business, so I’ll elaborate. Over time, on-premise hardware could be the best way to offer compute power on the cheap; however, it comes with a few formidable barriers. Running hardware on premise brings costs for the hardware, costs to house the hardware, and costs for good, well-paid engineers to manage the hardware. If these roadblocks don’t present an issue, on-premise is by far the best way to go. 

Exact figures for the savings of on-premise solutions are hard to provide because the savings depend entirely on execution. From experience we expect Luh Elephant could reduce infrastructure costs down to around $20,000 per month. But keep in mind this does not count additional engineer salaries, and this does not account for upfront capital outlay. Initial expenditures would be high because new hardware would require upfront purchase.

For our fledgling company, Option 1 will not work -- at least not for several years. They don’t have the capital to spend upfront, and they have only 10 employees (who were hard to acquire in the first place). Finding more good talent could take months, and that is not an option in their competitive market.

Option 2: Use a cluster management tool

Hardware cluster management tools (like Mesos, et al.) are great tools to be sure, but they don’t solve the “I want to use my hardware more efficiently” problem. They help reduce the knowledge required to effectively run production applications at scale, but scaling is handled manually. Further, these systems don’t lower your hardware spend -- and they can even increase it.

Nevertheless, fret not, dear reader. Another option still exists over the horizon.

Option 3: Containerization with Kubernetes

This is the perfect option for our heroes! In our first article on saving money with Kubernetes, you can get a good look into the type of resource management Kubernetes offers. Kubernetes ticks all the right boxes for a cash-strapped company that is trying to rule their market. And it does it all without sacrificing performance or user experience. 

Another possible option would be to use a non-Kubernetes-based container manager. This might save a little in cost, but Kubernetes is currently the only current container manager that has the ability to allocate resource dynamically and to do it well.

So what does a Kubernetes solution translate to in cold hard cash?

Let’s break it down. We know from the previous article that in Kubernetes you could conservatively set up a resource scheme to allow you to pack 50% more resource consumption onto your hardware -- and even this is adjustable. Every organization can find a ratio that best fits its applications and a desirable savings profile. 50-80% is a good place to start for most stateful applications. 

CustomersApplicationsServers (minions)Old CostKubernetes Cost
200 (1 server clusters)200100$34,894$17,447
100 (3 server clusters)300150$52,341$26,171

Hey-Hey!! Now we’re talkin'! That’s a nice savings. And now the server counts are much more predictable. We can really get better usage from our Reserved Instances: $25,605 (41% up to about 60% for 3-year).

With these types of savings, Luh Elephant, Inc. would have no problems drastically reducing prices to be even lower than their competition AND keeping the same performance!

A nice side benefit of this infrastructure model is that Luh Elephant, Inc. can now use even larger instances if it chooses. Using larger instances in the same AWS instance class would have very little impact on server costs but would get their customers access to high-dollar cloud features that come with larger instances such as crazy high network throughput, higher storage speeds, and burstability. The larger instances can provide more space if one or a few customers temporarily burst over their usage limits. All of this gains this startup more checks in their website advantages checkbox thingy then any of Luh Elephant's competitors can provide.

Where has Supergiant come into play?

Kubernetes can be daunting at times, so Supergiant runs on top of Kubernetes and ensures that things are easier to configure for engineering and support teams. It doesn't obscure Kubernetes in any way -- it simply brings deep Kubernetes features to the surface and makes them easy to manage.

Supergiant’s packing algorithm also augments Kubernetes' built-in resource allocation by automatically handling instance provisioning and allocation for you. If you are running large instances for your cluster, it does not make sense to start another large server for just one customer. The packing algorithm will automatically choose the correct servers that meet the specific needs of your environment.

We hope you have enjoyed this article. Check us out at, visit the Supergiant subreddit, or chat with us about Supergiant in the comments or in our shiny Slack channel. Contribute your thoughts, code, or issues at the Supergiant Github.

Further Reading

Keep reading

Kubernetes Series: Understanding Why Container Architecture is Important to the Future of Your Business

Posted by Mike Johnston on June 2, 2016

In the previous article in this series, I gushed over how much money a business can save with Kubernetes using Supergiant. In this article I want to dive deeper into container strategies and give you a look at the business end of container architecture so you learn how to achieve this savings.

Containers are an awesome tool, but success with containers is directly related to an engineer’s or a business leader’s ability to understand them and use them correctly.

The most progressive organizations have already used containers to reduce costs dramatically and improve their infrastructure performance. The container space has matured at a prodigious rate, and many organizations, like Netflix and Spotify, have already invested and reaped the benefits of a containerized infrastructure.

It is important to be aware that your competition could be developing or using a containerization strategy. If you find yourself wondering how your competition appears to have such nimble technical ability, it’s a good bet they already are.

The key to using containers effectively, is having a great container management system. As stated in our previous article, we believe the best solution today is Kubernetes. Kubernetes is very stable at this point. It’s also production ready. 

If you have not read our previous article, I encourage you to glance over the resource allocation features of Kubernetes and Supergiant because I will only be covering architectural concerns in this article.

I’ve picked my container management system. Now what?

In this article, I am going to summarize different types of containers and how to organize them in Kubernetes. 

Resource allocation is only 50% of the money saving formula. The other 50% comes from knowledge of how to architect your applications in containers properly.

Container Architecture Types

First, let’s go over what a good container looks like. I will list containerized application architectural types from most to least desirable. There is no direct right or wrong here. Some applications simply do not allow you to use the more desirable container architectures, but we can try.

The Scratch Container (The Holy Grail)

This is the most desirable type of container. This container is based on a “scratch” environment, which means that the container by default has no access to SSH, environment, or any higher-level operating system functions. It simply contains a super small linux kernel.

This option is the most desirable because it is fast. Blazing fast. These containers are also usually no larger than a couple of megabytes. This translates to applications that are very nimble that can boot quickly to cope with demand.

The downside of this container type is that since the scratch image is very basic, it contains none of the usual higher-level components expected in an operating system. If your application requires SSL certs, etc., you must ensure the dependencies you need are packed with the app.

With some creativity, it is possible to get a complicated application written in a non-compiled language to play well with scratch containers.

I like to use the original Kubernetes dashboard as a prime example. This container is a NodeJS application that uses a very simple Golang web server. The Golang web server allows the NodeJS application to be run in a scratch environment, even though NodeJS is not typically able to run in such a minimal environment.

Here is a quick diagram of what this container looks like. You can see here that we are able to run our whole application in one very fast scratch container:

The “Container OS” Container Tthe Next-Best Thing)

These types of containers are a great option if you can’t get your application running in a scratch environment.

It’s important to remember that a container should ideally do just one thing well: run a database, a web server, etc. When running single applications like this, we have no need for many of the default higher-level operating system functions that can steal CPU and RAM we would otherwise like devoted to our application.

Unlike scratch containers, most of these container images provide a package management tool that allows you to install dependencies. A great example of one of these operating systems is Alpine OS.

These containers also have the virtue of being very small -- usually 5-8 megabytes in size. However, dependencies can make these container sizes balloon quickly when they are not kept in check. After installing a typical NodeJS or Rails environment, it is not uncommon to see your container size balloon to 50 or 100 megabytes or more, and this can severely impact container performance.

Let’s use our dashboard example from the scratch container to see how it would look in this type. Remember, we only run one application per container, but we can use Docker container linking to link them together into one object. Things get a bit more complicated, but our applications is still fairly fast:

The “Full OS” Container (The Least Desirable)

The Full Operating System container is similar to the Container OS container, but it has all of the features you expect of a full OS -- access to SSH, init, multiple shells, etc. These come at a steep cost to performance.

An example of one of these operating systems would be Ubuntu, or Red Hat server. These types of containers can range from 300-800 megabytes in size. When your container management system deploys this container hundreds or thousands of times a day/week, you can see how the data transfer size can get cumbersome.

The good news is major operating system providers are aware of these issues, and many are releasing smaller and more compact container-specific versions. These new versions can range from 50-200 megabytes in size, and it appears they are making them smaller and smaller as the container space matures.

I am not going to include a diagram here because it would look the same as the Alpine diagram above. The only exception is that this type of container is the least performant of the bunch. 

Put It to Work

So now you know a few container types you want to have in your architecture, but how should you organize your containers so Kubernetes can make the most of them?

Let’s lay out a web application that requires a database to run:

Okay… don’t run away screaming just yet. I promise I will break this down for you.

Let's follow the user's path through this containerized Web Application on Kubernetes. I will explain what everything does as we step through each part.

  • Load Balancer/Kube Proxy: This is the entrypoint to the Kubernetes cluster, and I like to add a little more network security here in a Load Balancer configured to work with the Kube Proxy. The Kube Proxy’s job is to route traffic from the outside to the correct containers inside.
  • Namespace: A Kubernetes Namespace logically groups resources. You create these Namespaces to share services or manage resources within the Namespace.
  • Web App Service and Database Service: A service is what you would have if a load balancer, a network switch, and a router all had a baby. It can be configured to do a lot of things with traffic, but its basic purpose is to route traffic from IP address or DNS to the containerized Apps that do the work. In this example, the “Web App Service” routes traffic to each of the “Web App” containers, using a metadata tag called “website” (or whatever works for you). All your users see is a single, speedy “website,” but behind the scenes there could be multiple instances of the app container crunching on problems.
  • Replication Controller: A replication controller has a pretty simple function: it works as an autoscaler for your containers. It contains a blueprint of what a replica should look like, so when a containerized app is in trouble, the Replication Controller will simply spin up what it needs to keep a service running.
  • Pods: Pods are groups of containers that may be “linked” together, like in our earlier Alpine OS diagram. If your container is not linked, it will just be in a Pod all by itself. No need to get too far into the weeds here. In this example, our “Web App” is technically a Pod.

Inside this arrangement of services, each service sees the other as a network resource. This allows each service to see the other as a service, and, well, its services all the way down.

What do I do now, with my new degree in container architecture?

Now that I have made your eyes bleed for a few minutes, with your new honorary degree in container architecture, let's get down to why this setup and others like it are so great.

This web app isn’t just a few programs running on a few big, expensive boxes. Instead, it’s spread over smaller, clustered servers that do the same job, but they have the ability to spin down and cost far less when not needed.

And in the event there is a failed physical server, or a failed Pod, Kubernetes immediately replicates or moves that Pod to another physical server.

The Replication Controller always ensures the Pod is running, and if your containers are engineered with the methodology I describe here, you can expect this process to be very quick. In most cases, nobody but the logs will even notice when an issue occurs.

So what would this application look like in Supergiant?

I have to say, the above is a lot to absorb. Just in case some of it isn’t sticking, I have good news.

One of Supergiant’s jobs is to abstract Services, Replication Controllers, and Pods away into a single object called a Component. We simply felt that abstracting this into a simple concept would be more welcome than repeating complicated configurations for Kubernetes applications.

For users who still like dealing with like that sort of thing (we get it -- really), we have not obscured the guts at all. The nitty-gritty features are all still there and can also be incorporated/tweaked within Supergiant Components to suit your needs.  

However, our hope is that this abstraction will help clear up those bleeding eyes a bit.

This is the same Web Application as above except this is how it looks to Supergiant users:

Now let's follow the user's path through this containerized Application on Supergiant:

  • Entrypoint: An Entrypoint wraps up the Load Balancer and Kube Proxy settings into one configurable object, and Supergiant sets this up for you. It is important to note here that Kubernetes currently does not allow multiple services to share an external load balancer. A load balancer for every service can get expensive, so we made Entrypoints “sharable” between components and apps, and it is far less complicated than trying to figure out how to configure the Kube Proxy and Load Balancer to play well together.
  • Application: This is the same as a Kubernetes Namespace, but we felt Application better conveys the purpose of the Namespace, and it’s easier to think of structures in the Supergiant API this way.
  • Component: This is the coolest part! A Component is a service, replication controller, and pods all wrapped up into one object.

Most of the time, you will find that configuration of Kubernetes services in relation to replication controllers and pods can be complicated or repetitive. The Supergiant API puts all configuration into one simple config. This can then be exported, imported, saved away, or shared with other Supergiant users. And since the Component contains everything you need for a running application, the person you share your Component with does not really need to know anything about your application or how it works. 

One of Supergiant’s goals is to lower the entry-level knowledge required by businesses wanting to use Kubernetes, and for those who have the knowledge, to make things fast and simple to configure.

Supergiant gives you the tools to switch to a containerization strategy in no time, so you can start saving your business money.

This was a dense article.

I am trying to walk the line of exposing why Kubernetes container management is such a win to business readers while explaining some technical aspects that show why, so if you have any questions about what you have read here today, I encourage you to comment below and hit us up on our Slack, Twitter, or our subreddit.

For more information on Supergiant visit us at, and we welcome your contributions on GitHub.

Keep reading

Top Reasons Businesses Should Move to Kubernetes Now

Posted by Mike Johnston on May 26, 2016

If you haven’t been able to find your way out of the datacenter lately, you may not have noticed that the container management market is exploding.

Until the last couple of years, containers were a cool concept, but running them at scale and running them in a way that is actually as performant as bare metal (or even VM) was not really possible. Shared service companies that ventured into multi-tenant infrastructures based on Docker provided horrible performance to their customers. The solutions they used were hand-rolled, and, unless you had the sheer capital and a dev army to make something good, most solutions were pretty poor. Managing inter-container networking, persistent storage, and autoscale (along with many other standard infrastructure features) in an automated way just wasn’t in the cards.

One organization with the capacity to produce a really good container management platform was Google, with their Borg container management system. In 2014 the Google gods chose to release this system to the open source wild under the Kubernetes project.

In this article I will go deeper into why Kubernetes is such a game changer in the container space, and in this series I will continually take you down the rabbit hole into Kubernetes features that you may not know about or that may totally blow your mind.

As the title suggests, this particular article  is targeted to both maximum businessers and DevOps engineers who seek the overhead and performance benefits of a containerized infrastructure.

This series will guide you through how to use Kubernetes in your business and how it makes financial sense. I will link to technical documents throughout the series, but it does not make sense for me to go into too much technical detail when most of technical information is readily available through your friendly Google search bar.

I will try to break concepts down in a understandable way, and if you or your team would like to dive deeper into the business case or technical details of any of my articles, I encourage you to hit us up in the comments, visit our Supergiant subreddit, or join our Supergiant Slack channel.


The first concept I want to cover is containers. From a high level I have noticed a lot of confusion about what containers actually are, and this has led to some misconceptions about how they should be used and whether they are right for your infrastructure.

Let’s get something out of the way right now: Containers are not virtual machines.

Containers, at their heart, are a way to fence an application off from other areas or applications on your servers. Applications inside a container have direct access to your underlying server hardware without the overhead of virtualization. They also have the benefit of being portable and self-contained, which means all the time and money investment spent configuring servers with dependencies, support libraries, etc. is a thing of the past for the most part.

With containers, all of your hardware can receive the same configuration, and the containers are self-contained apps on top of a pile of computer power.

I will go into making great containers later in the series, but you can see really quickly that containers allow you to standardize your infrastructure across the board, lowering engineering costs.

What does this mean for my technology team?

Developers no longer need to be at odds with engineers. A developer can create, test, and build an app all in a container. Then they simply hand the container over to the engineering staff or container management platform. The engineer or container management service just needs to know what network and storage requirements the container(s) need. They really don’t need much knowledge about the container’s function -- just that it runs. This allows increased speed to market, and it lowers engineering costs by bypassing the server-level engineering normally needed to launch applications.

In general, containers allow your team to work better together and to iterate/develop faster.

So what does Kubernetes bring to the table?

Now that you plan to run your applications in a container-based infrastructure, how do you herd the cats? A large infrastructure could have hundreds if not thousands of applications, and they all need networking, storage, and alerting/management. These features must be automated. There has been a flood of new container management platforms in the last couple of years. Some are good; some are horrible. After much review, trial, and error at scale, we think the best solution available right now is Kubernetes.

Some solutions are really good at networking, while others are really good at managing persistent storage -- but we feel Kubernetes is the only one with the “whole package.”

Kubernetes clusters can automatically handle networking, storage, autoscaling, logs, alerting, etc. for all your containers. It has been our experience that Kubernetes clusters are extremely low maintenance. Once they are set up and properly configured, you can expect your applications to run with extremely low downtime, great performance, and with a greatly reduced need for support intervention. Once we began to deploy our services on Kubernetes, our support team saw a dramatic decrease in support issues, and they were able to better allocate their time to an even higher relationship standard with our customers. I think we can agree that is where we would like our support teams to be able to focus their efforts.

Another unsung hero that Kubernetes brings to the table is its compute management scheme.

I am not kidding when I say this: Kubernetes can significantly reduce your hardware costs by better utilizing the hardware you are paying for. We have seen 40%-50% reductions in our hardware costs by utilizing the Kubernetes resource scheme, and it does this without impacting application performance or customer experience at all. We even noticed an improvement to our overall application performance across the board. Read more about this below.

Improvements to Kubernetes

After all my gushing above, it may seem like there isn’t anything left to improve, but there is. We call it Supergiant.

What does Supergiant do differently than Kubernetes, and why wouldn’t I just use Kubernetes?

The nice thing about Supergiant is, you can just use Kubernetes. We don’t modify Kubernetes in any way. We feel that would be sacrilege, so the Supergiant open-source CLI can be used to deploy and manage Kubernetes clusters even if you have no intention of using Supergiant at all.

When we built Supergiant, our goal was to add value by focusing on performance and ease of management, so we built an easy-to-use UI and we abstracted more complicated features into easy-to-understand forms: installation, persistent storage, load balancing, and hardware (read: cost) autoscaling.

Installing Kubernetes on your own hardware can be a tough hurdle for a lot of teams, so we made it easy to install. I won’t go into more detail here, but you can use the CLI, or you can get started faster with our installer script that runs through a handful of CLI actions. Our installer script may be accessed from the Install Supergiant page on our site.

Supergiant gives you tools to manage persistent storage that allow you to migrate data, change hard drive size, type, etc. on the fly. We focused on performance and ease of management for stateful containers, like databases, and we made them accessible to users and organizations who don’t have 6 months of lead time to learn a new management platform.

Supergiant also augments Kubernetes hardware management by squeezing even better utilization out of existing hardware and by autoscaling hardware where and when it is needed.

In essence, we wanted to bring our internal tools that we wrote to make Kubernetes work well with our hosted Elasticsearch infrastructure.

Once we created it, we wanted to make these tools available free forever to anyone who wants to get the same benefits we did.

Thanks for your time. Check us out at, Twitter, Reddit, slack, and Github!

Further Reading

You can read more Supergiant case studies and examples in these articles:

Keep reading