Unless you’ve been on the moon for the past couple of years, you’ve heard about containers. Or you’ve heard about Docker, Kubernetes, Mesos, or any one of a number of projects that has sprung up around the idea of managing a container ecosystem. While some will dismiss containers as a transient fad or simply a superset of BSD jails or chroot implementations, containers are having a huge impact on the way we do business and create applications.
That doesn’t mean that containers are easy. In fact, far from it. Even if you decide on a platform like Docker to manage your container resources you still have a lot of other decisions to make. Do you go with Docker Swarm as your underlying scheduling system? Do you look at something like Kubernetes instead? Kubernetes is slowly winning the community over with their wide adoption. 64% of developers have embraced Kubernetes as their orchestration system of choice. But Kubernetes is hard. In fact, the most popular online course for learning it is Kelsey Hightower’s Kubernetes The Hard Way. So how can one make an orchestrator like Kubernetes work the way you want it to work?
I Really Want To Direct
Luckily for us, there’s a group of smart developers that are tackling this problem head on. Nirmata, which means architect or director, is a startup that is building an orchestration layer to sit on top of Kubernetes and other scheduling systems and help you build what you want to do with containers instead of spending all your time trying to configure them.
If this sounds pointless think again. One of the biggest problems I hear from DevOps people is that they don’t want to think too much about the infrastructure. When they want a port provisioned for a server or they want a new network brought online they don’t want to spend precious time figuring out which commands enable trunking on the switchport. They just want to hit a button or type some simple commands and have the system do all the work in the background.
Now, extend this metaphor into the cloud world. If you’re a developer that spends most of your time building a webhost or turning up services that rely on a container infrastructure you don’t want to monkey around with the infrastructure. You want to build your code templates, deploy them, and let the system do all the heavy lifting. While you can eventually get a container system to that point with a lot of tinkering you are essentially wasting a lot of your time building something that you’ll never touch again. And that’s assuming you know enough about schedulers and orchestrators to make it happen in the first place.
Nirmata is changing this by building a layer the runs on top of everything to make it all transparent. Instead of focusing on tuning your containers and ensuring they are torn down when they aren’t needed, Nirmata serves as the interface for building everything on the front end. You create a template for your application type and drag it into a workspace. Then you build your app and let Nirmata take care of ordering Kubernetes or your scheduler of choice around in the background.
Nirmata also gives you the flexibility to make your app in your own private cloud with OpenStack or vSphere or move it to a public cloud provider like Amazon or Microsoft. Since the orchestrator is equally at home in both, it’s very easy to create an app locally for testing, find all the bugs, and then move it into AWS or Azure for full deployment. That means you don’t have to worry about learning a new language when you move from vCenter to your AWS dashboard. Nirmata takes care of the rest.
The only downside that I can see to using Nirmata instead of learning Kubernetes itself is the reliance that you grow to have on the orchestration platform instead of the tool. While that does sound like a bit of lock-in on the surface you have to realize that every choice you make is a form of lock-in at some level. If you were a huge fan of Docker Swarm last year you’ve probably built all of your applications using Swarm’s peculiar way of doing things. Now that Docker uses Kubernetes, are you going to uproot everything and go down that road? Or will you stick with Swarm? Likewise, if you use Nirmata for all your needs, are you going to just pull up stakes and leave when something doesn’t go the way you like? Odds are good the answer is “no”. You’re going to work through your challenges and come out on the other side stronger and better. And that’s what software, especially orchestration software, should do for you.
Bringing It All Together
Containers shouldn’t be as hard as they are. It reminds me of the early days of building Linux servers. If you were really hardcore, you used Arch or Slackware and built everything by hand. The more advanced folks learned how to install distros like Red Hat/Fedora or SuSE. Eventually, Ubuntu made it so simple that everyone flocked to using it for everything. Nirmata is much like Ubuntu. It makes the hard stuff easy because it makes the layer on top of the hard stuff even easier than it was already. And that’s how you drive adoption of containers. Not with education or classes or even explanation. You make it disappear and let developers develop what they want in the way they want to do it.
[…] Architecting Container Direction with Nirmata […]