12 ms·

Cloud orchestration, Container Orchestration, Kubernetes... I think I am getting old and starting to understand how my parents feel about technology. I am deve

by urza 10y ago

Cloud orchestration, Container Orchestration, Kubernetes... I think I am getting old and starting to understand how my parents feel about technology. I am developer, but mostly work on desktop apps, or embedded devices or lataly on some MVC applications. But reading things like "A Container-Native Stack for Modern Applications and Operations Increase development velocity while simplifying operations." I have no idea what should I imagine and what is it good for... any good introduction or explanation into what is it they actually do?

eliah 10y ago
This might be more in-depth than what you're looking for, but I found this (long) slideshow useful: https://joshpadnick.com/2015/09/01/my-talk-on-choosing-the-right-framework-for-running-docker-containers-in-production/ https://joshpadnick.com/2015/09/01/my-talk-on-choosing-the-r...
novaleaf 10y ago
I always think (thought?) containers are good if you own your own hardware. I use 'micro' cloud vm instances for my deployments and don't feel the need to squish more functionality into a $5/month VM.
moondev 10y ago
For the most part if your application is developed 12 factor style: http://12factor.net http://12factor.net, you shouldn't have to worry about these things as a developer. Stuff like this is more in the ops space. Cloud orchestration: the logic for how your platform provisions and launches instances (think ec2) into your fleet of resources. Container orchestration: the logic for how your applications (containers) are distributed across your fleet of instances Kubernetes: Software that runs on your fleet and manages how/where/when container orchestration happens. There are many players in this space such as mesosphere, swarm, ecs and so on.
- deleted 10y ago
  [deleted]
bkanber 10y ago
So, you build a web app and it gets popular. It needs one load balancer, 5 app servers, at least two database nodes for replication, a redis cluster for caching and queuing, an elasticsearch cluster for full text search, and a cluster of job worker servers to do async stuff like processing images, etc. In the ancient past, like when I'm from, you'd write up a few different bash scripts to help you provision each server type. But setting this all up, you'd still have to run around and create 20 servers and provision them into one of 5 different types, etc. Then there's chef/puppet, which takes your bash script and makes it a little more maintainable. But there are still issues: huge divide between dev/prod environments, and adding 5 new nodes ASAP is still tedious. Now you have cloud and container orchestration. Containers are like the git repos of the server world. You build a container to run each of your apps (nginx, redis, etc), configure each once (like coding and committing), and then they work identically on dev and prod after you launch them (you can clone/pull onto hardware). And what's more, since a container image is pre-built, it launches on metal in a matter of seconds, not minutes. All the apt-get install crap was done at image build time, not container launch time. Things are a lot easier now, but you still have a problem. You're scaling to 30, maybe 50 different servers running 6 or 7 different services. More and more you want to treat your hardware as a generic compute cloud, but you can't escape that, even with docker, your servers have identities and personalities. You still need to sit and think about which of your 50 servers to launch a container on, and make sure it's under the correct load balancer, etc. That's where Kubernetes steps in; it's a level of abstraction higher than docker, and works at the cluster level. You define services around your docker containers, and let Kubernetes initialize the hardware, and abstract it away into a giant compute cloud, and then all you have to do is tell kubernetes to scale a certain service up and down, and it automatically figures out which servers to take the action on and modifies your load balancer for that service accordingly. At the scale of "a few servers", Kubernetes doesn't help much. At the scale of dozens or hundreds, it definitely does. "Orchestration" isn't just a buzzword, it's the correct term here; all those containers and services and pieces of hardware DO need to be wrangled. In the past it was a full time sysadmin job, now it's just a Kubernetes or Fleet config file. Disclosure: I'm currently writing a book on Docker. Disclaimer: I have not had my coffee yet. Edit: Since someone asked, I'm writing a book called "Complete Docker" which will be published by Apress. I don't know the exact pub date that Apress will launch it on, but I expect it'll be available in October.
knownothing 10y ago
all these answers are helpful but misguided. it is a lot of jargon but there is some value to be had, depending on your situation. i'd argue that this situation is if you're a developer at a large company or enterprise. developing can be a nightmare because testing and/or deploying is so difficult. sometimes this is by design, sometimes by virtue of incompetence. other times people want to change it, they just don't know how. tools like this claim they can change this. whether that's true or not. well, that depends on more than just what tools you use but it is part of the equation.
iamleppert 10y ago
Mostly sell snake oil to big companies that don't have popular apps. lol
sjtgraham 10y ago
> I think I am getting old and starting to understand how my parents feel about technology. 1. Anything that is in the world when you’re born is normal and ordinary and is just a natural part of the way the world works. 2. Anything that's invented between when you’re fifteen and thirty-five is new and exciting and revolutionary and you can probably get a career in it. 3. Anything invented after you're thirty-five is against the natural order of things. - Douglas Adams

by urza 10y ago

eliah 10y ago

This might be more in-depth than what you're looking for, but I found this (long) slideshow useful: https://joshpadnick.com/2015/09/01/my-talk-on-choosing-the-right-framework-for-running-docker-containers-in-production/ https://joshpadnick.com/2015/09/01/my-talk-on-choosing-the-r...

novaleaf 10y ago

I always think (thought?) containers are good if you own your own hardware. I use 'micro' cloud vm instances for my deployments and don't feel the need to squish more functionality into a $5/month VM.

moondev 10y ago

For the most part if your application is developed 12 factor style: http://12factor.net http://12factor.net, you shouldn't have to worry about these things as a developer. Stuff like this is more in the ops space. Cloud orchestration: the logic for how your platform provisions and launches instances (think ec2) into your fleet of resources. Container orchestration: the logic for how your applications (containers) are distributed across your fleet of instances Kubernetes: Software that runs on your fleet and manages how/where/when container orchestration happens. There are many players in this space such as mesosphere, swarm, ecs and so on.

deleted 10y ago
[deleted]

bkanber 10y ago

So, you build a web app and it gets popular. It needs one load balancer, 5 app servers, at least two database nodes for replication, a redis cluster for caching and queuing, an elasticsearch cluster for full text search, and a cluster of job worker servers to do async stuff like processing images, etc. In the ancient past, like when I'm from, you'd write up a few different bash scripts to help you provision each server type. But setting this all up, you'd still have to run around and create 20 servers and provision them into one of 5 different types, etc. Then there's chef/puppet, which takes your bash script and makes it a little more maintainable. But there are still issues: huge divide between dev/prod environments, and adding 5 new nodes ASAP is still tedious. Now you have cloud and container orchestration. Containers are like the git repos of the server world. You build a container to run each of your apps (nginx, redis, etc), configure each once (like coding and committing), and then they work identically on dev and prod after you launch them (you can clone/pull onto hardware). And what's more, since a container image is pre-built, it launches on metal in a matter of seconds, not minutes. All the apt-get install crap was done at image build time, not container launch time. Things are a lot easier now, but you still have a problem. You're scaling to 30, maybe 50 different servers running 6 or 7 different services. More and more you want to treat your hardware as a generic compute cloud, but you can't escape that, even with docker, your servers have identities and personalities. You still need to sit and think about which of your 50 servers to launch a container on, and make sure it's under the correct load balancer, etc. That's where Kubernetes steps in; it's a level of abstraction higher than docker, and works at the cluster level. You define services around your docker containers, and let Kubernetes initialize the hardware, and abstract it away into a giant compute cloud, and then all you have to do is tell kubernetes to scale a certain service up and down, and it automatically figures out which servers to take the action on and modifies your load balancer for that service accordingly. At the scale of "a few servers", Kubernetes doesn't help much. At the scale of dozens or hundreds, it definitely does. "Orchestration" isn't just a buzzword, it's the correct term here; all those containers and services and pieces of hardware DO need to be wrangled. In the past it was a full time sysadmin job, now it's just a Kubernetes or Fleet config file. Disclosure: I'm currently writing a book on Docker. Disclaimer: I have not had my coffee yet. Edit: Since someone asked, I'm writing a book called "Complete Docker" which will be published by Apress. I don't know the exact pub date that Apress will launch it on, but I expect it'll be available in October.

knownothing 10y ago

all these answers are helpful but misguided. it is a lot of jargon but there is some value to be had, depending on your situation. i'd argue that this situation is if you're a developer at a large company or enterprise. developing can be a nightmare because testing and/or deploying is so difficult. sometimes this is by design, sometimes by virtue of incompetence. other times people want to change it, they just don't know how. tools like this claim they can change this. whether that's true or not. well, that depends on more than just what tools you use but it is part of the equation.

iamleppert 10y ago

Mostly sell snake oil to big companies that don't have popular apps. lol

sjtgraham 10y ago

> I think I am getting old and starting to understand how my parents feel about technology. 1. Anything that is in the world when you’re born is normal and ordinary and is just a natural part of the way the world works. 2. Anything that's invented between when you’re fifteen and thirty-five is new and exciting and revolutionary and you can probably get a career in it. 3. Anything invented after you're thirty-five is against the natural order of things. - Douglas Adams