Alternatives to Kubernetes logo

Alternatives to Kubernetes

Docker Swarm, Nomad, OpenStack, Rancher, and Docker Compose are the most popular alternatives and competitors to Kubernetes.
9.4K
7.9K
+ 1
539

What is Kubernetes and what are its top alternatives?

Kubernetes is an open source orchestration system for Docker containers. It handles scheduling onto nodes in a compute cluster and actively manages workloads to ensure that their state matches the users declared intentions.
Kubernetes is a tool in the Container Tools category of a tech stack.
Kubernetes is an open source tool with 62.7K GitHub stars and 22.2K GitHub forks. Here’s a link to Kubernetes's open source repository on GitHub

Kubernetes alternatives & related posts

related Docker Swarm posts

Yshay Yaacobi
Yshay Yaacobi
Software Engineer · | 29 upvotes · 529.6K views
atSolutoSoluto
Docker Swarm
Docker Swarm
.NET
.NET
F#
F#
C#
C#
JavaScript
JavaScript
TypeScript
TypeScript
Go
Go
Visual Studio Code
Visual Studio Code
Kubernetes
Kubernetes

Our first experience with .NET core was when we developed our OSS feature management platform - Tweek (https://github.com/soluto/tweek). We wanted to create a solution that is able to run anywhere (super important for OSS), has excellent performance characteristics and can fit in a multi-container architecture. We decided to implement our rule engine processor in F# , our main service was implemented in C# and other components were built using JavaScript / TypeScript and Go.

Visual Studio Code worked really well for us as well, it worked well with all our polyglot services and the .Net core integration had great cross-platform developer experience (to be fair, F# was a bit trickier) - actually, each of our team members used a different OS (Ubuntu, macos, windows). Our production deployment ran for a time on Docker Swarm until we've decided to adopt Kubernetes with almost seamless migration process.

After our positive experience of running .Net core workloads in containers and developing Tweek's .Net services on non-windows machines, C# had gained back some of its popularity (originally lost to Node.js), and other teams have been using it for developing microservices, k8s sidecars (like https://github.com/Soluto/airbag), cli tools, serverless functions and other projects...

See more
Nomad logo

Nomad

90
94
3
90
94
+ 1
3
A cluster manager and scheduler
Nomad logo
Nomad
VS
Kubernetes logo
Kubernetes

related Nomad posts

Robert Zuber
Robert Zuber
CTO at CircleCI · | 6 upvotes · 59K views
atCircleCICircleCI
Docker
Docker
Kubernetes
Kubernetes
Nomad
Nomad
Helm
Helm

Our backend consists of two major pools of machines. One pool hosts the systems that run our site, manage jobs, and send notifications. These services are deployed within Docker containers orchestrated in Kubernetes. Due to Kubernetes’ ecosystem and toolchain, it was an obvious choice for our fairly statically-defined processes: the rate of change of job types or how many we may need in our internal stack is relatively low.

The other pool of machines is for running our users’ jobs. Because we cannot dynamically predict demand, what types of jobs our users need to have run, nor the resources required for each of those jobs, we found that Nomad excelled over Kubernetes in this area.

We’re also using Helm to make it easier to deploy new services into Kubernetes. We create a chart (i.e. package) for each service. This lets us easily roll back new software and gives us an audit trail of what was installed or upgraded.

See more
OpenStack logo

OpenStack

409
394
91
409
394
+ 1
91
Open source software for building private and public clouds
OpenStack logo
OpenStack
VS
Kubernetes logo
Kubernetes

related Docker Compose posts

Docker
Docker
Docker Compose
Docker Compose
Jenkins
Jenkins
Kubernetes
Kubernetes
Amazon EC2
Amazon EC2
Heroku
Heroku
FeathersJS
FeathersJS
Node.js
Node.js
ExpressJS
ExpressJS
PostgreSQL
PostgreSQL
React
React
Redux
Redux
Semantic UI React
Semantic UI React
AVA
AVA
ESLint
ESLint
nginx
nginx
GitHub
GitHub
#Containerized
#Containers
#Backend
#Stack
#Frontend

Recently I have been working on an open source stack to help people consolidate their personal health data in a single database so that AI and analytics apps can be run against it to find personalized treatments. We chose to go with a #containerized approach leveraging Docker #containers with a local development environment setup with Docker Compose and nginx for container routing. For the production environment we chose to pull code from GitHub and build/push images using Jenkins and using Kubernetes to deploy to Amazon EC2.

We also implemented a dashboard app to handle user authentication/authorization, as well as a custom SSO server that runs on Heroku which allows experts to easily visit more than one instance without having to login repeatedly. The #Backend was implemented using my favorite #Stack which consists of FeathersJS on top of Node.js and ExpressJS with PostgreSQL as the main database. The #Frontend was implemented using React, Redux.js, Semantic UI React and the FeathersJS client. Though testing was light on this project, we chose to use AVA as well as ESLint to keep the codebase clean and consistent.

See more
Zach Holman
Zach Holman
at Zach Holman · | 14 upvotes · 93.5K views
Home Assistant
Home Assistant
Docker
Docker
Docker Compose
Docker Compose

I've been recently getting really into home automation- you know, making my house Smart™, which basically means half the time my lights don't turn on and the other half of the time apparently my kitchen faucet needs a static IP address.

But it's been a blast! It's a fun way to write code for yourself, outside of work, to have an impact in the real world. It's a nice way of falling in love with a different side of programming again.

I've used Apple's HomeKit for awhile, since we're pretty all-in in Apple devices at home, but the rough edges have been grating at me more and more. HomeKit is so opaque- you can't see what's wrong, why a device is unresponsive, and most importantly: the compatibility isn't there. HomeKit has a limited selection of — more expensive — accessories, and as you go beyond just simple LED lights, you want a bit more power. Also, we're programmers, dammit, gimme all the things.

Anyway, I've switched to Home Assistant the last few months, and I'm kicking myself I didn't make the switch earlier. As a programmer, it's great: you get the most capability than pretty much any other smart home platform (integrations have been written for most devices and technologies out there today), it's easier to debug, and when you want to go bigger than just simple lights on/off, HA has some really powerful stuff behind it.

I use Home Assistant in conjunction with Docker and Docker Compose; since the config is extracted out, upgrades are usually as easy as a pull of the latest version. I've just started digging into writing integrations for a lesser-used device that I have at home, and HA makes it pretty straightforward to just magically add it to the home network.

It plays well with others, too- we require a VPN connection in to the home network to access our Home Assistant install, and HA has a few tricks to help with that (ignoring the VPN route if you're on a local network, etc). Nice client support for iOS and Android, too.

Anyway, big fan of Home Assistant if you want to go beyond simple home automations and setup. Wish I would have done it a lot earlier. Also, big fan of jumping into all this if you have the time and interest to do so- it's been tickling a different part of my code brain than I've had access to in awhile, and that's been fun in and of itself.

See more
DC/OS logo

DC/OS

91
109
12
91
109
+ 1
12
The Datacenter Operating System. The easiest way to run microservices, big data, and containers in production.
DC/OS logo
DC/OS
VS
Kubernetes logo
Kubernetes
Apache Mesos logo

Apache Mesos

226
251
30
226
251
+ 1
30
Develop and run resource-efficient distributed systems
Apache Mesos logo
Apache Mesos
VS
Kubernetes logo
Kubernetes

related Apache Mesos posts

StackShare Editors
StackShare Editors
| 1 upvotes · 97.5K views
atUber TechnologiesUber Technologies
Apache Mesos
Apache Mesos
Docker
Docker
Apache Aurora
Apache Aurora

Docker containers on Mesos run their microservices with consistent configurations at scale, along with Aurora for long-running services and cron jobs.

See more

related Docker posts

Tim Nolet
Tim Nolet
Founder, Engineer & Dishwasher at Checkly · | 20 upvotes · 415.8K views
atChecklyHQChecklyHQ
Heroku
Heroku
Docker
Docker
GitHub
GitHub
Node.js
Node.js
hapi
hapi
Vue.js
Vue.js
AWS Lambda
AWS Lambda
Amazon S3
Amazon S3
PostgreSQL
PostgreSQL
Knex.js
Knex.js
vuex
vuex

Heroku Docker GitHub Node.js hapi Vue.js AWS Lambda Amazon S3 PostgreSQL Knex.js Checkly is a fairly young company and we're still working hard to find the correct mix of product features, price and audience.

We are focussed on tech B2B, but I always wanted to serve solo developers too. So I decided to make a $7 plan.

Why $7? Simply put, it seems to be a sweet spot for tech companies: Heroku, Docker, Github, Appoptics (Librato) all offer $7 plans. They must have done a ton of research into this, so why not piggy back that and try it out.

Enough biz talk, onto tech. The challenges were:

  • Slice of a portion of the functionality so a $7 plan is still profitable. We call this the "plan limits"
  • Update API and back end services to handle and enforce plan limits.
  • Update the UI to kindly state plan limits are in effect on some part of the UI.
  • Update the pricing page to reflect all changes.
  • Keep the actual processing backend, storage and API's as untouched as possible.

In essence, we went from strictly volume based pricing to value based pricing. Here come the technical steps & decisions we made to get there.

  1. We updated our PostgreSQL schema so plans now have an array of "features". These are string constants that represent feature toggles.
  2. The Vue.js frontend reads these from the vuex store on login.
  3. Based on these values, the UI has simple v-if statements to either just show the feature or show a friendly "please upgrade" button.
  4. The hapi API has a hook on each relevant API endpoint that checks whether a user's plan has the feature enabled, or not.

Side note: We offer 10 SMS messages per month on the developer plan. However, we were not actually counting how many people were sending. We had to update our alerting daemon (that runs on Heroku and triggers SMS messages via AWS SNS) to actually bump a counter.

What we build is basically feature-toggling based on plan features. It is very extensible for future additions. Our scheduling and storage backend that actually runs users' monitoring requests (AWS Lambda) and stores the results (S3 and Postgres) has no knowledge of all of this and remained unchanged.

Hope this helps anyone building out their SaaS and is in a similar situation.

See more
Tymoteusz Paul
Tymoteusz Paul
Devops guy at X20X Development LTD · | 17 upvotes · 638.3K views
Vagrant
Vagrant
VirtualBox
VirtualBox
Ansible
Ansible
Elasticsearch
Elasticsearch
Kibana
Kibana
Logstash
Logstash
TeamCity
TeamCity
Jenkins
Jenkins
Slack
Slack
Apache Maven
Apache Maven
Vault
Vault
Git
Git
Docker
Docker
CircleCI
CircleCI
LXC
LXC
Amazon EC2
Amazon EC2

Often enough I have to explain my way of going about setting up a CI/CD pipeline with multiple deployment platforms. Since I am a bit tired of yapping the same every single time, I've decided to write it up and share with the world this way, and send people to read it instead ;). I will explain it on "live-example" of how the Rome got built, basing that current methodology exists only of readme.md and wishes of good luck (as it usually is ;)).

It always starts with an app, whatever it may be and reading the readmes available while Vagrant and VirtualBox is installing and updating. Following that is the first hurdle to go over - convert all the instruction/scripts into Ansible playbook(s), and only stopping when doing a clear vagrant up or vagrant reload we will have a fully working environment. As our Vagrant environment is now functional, it's time to break it! This is the moment to look for how things can be done better (too rigid/too lose versioning? Sloppy environment setup?) and replace them with the right way to do stuff, one that won't bite us in the backside. This is the point, and the best opportunity, to upcycle the existing way of doing dev environment to produce a proper, production-grade product.

I should probably digress here for a moment and explain why. I firmly believe that the way you deploy production is the same way you should deploy develop, shy of few debugging-friendly setting. This way you avoid the discrepancy between how production work vs how development works, which almost always causes major pains in the back of the neck, and with use of proper tools should mean no more work for the developers. That's why we start with Vagrant as developer boxes should be as easy as vagrant up, but the meat of our product lies in Ansible which will do meat of the work and can be applied to almost anything: AWS, bare metal, docker, LXC, in open net, behind vpn - you name it.

We must also give proper consideration to monitoring and logging hoovering at this point. My generic answer here is to grab Elasticsearch, Kibana, and Logstash. While for different use cases there may be better solutions, this one is well battle-tested, performs reasonably and is very easy to scale both vertically (within some limits) and horizontally. Logstash rules are easy to write and are well supported in maintenance through Ansible, which as I've mentioned earlier, are at the very core of things, and creating triggers/reports and alerts based on Elastic and Kibana is generally a breeze, including some quite complex aggregations.

If we are happy with the state of the Ansible it's time to move on and put all those roles and playbooks to work. Namely, we need something to manage our CI/CD pipelines. For me, the choice is obvious: TeamCity. It's modern, robust and unlike most of the light-weight alternatives, it's transparent. What I mean by that is that it doesn't tell you how to do things, doesn't limit your ways to deploy, or test, or package for that matter. Instead, it provides a developer-friendly and rich playground for your pipelines. You can do most the same with Jenkins, but it has a quite dated look and feel to it, while also missing some key