Samsung Acquires Joyent

It's the first sentence of the linked blog post, and the meaning seems pretty clear - instead of waffling on about how amazing an experience it's been and how much they've learned blah blah blah they just say "hey we got bought by Samsung."

Just to provide another perspective, I'm an American anglo who has lived off and on for over 30 years in South Korea, speak the language near fluently, have worked in a variety of Korean institutions from a rural health center to a top research university. Along the way I have benefitted mightily from friendship with some great colleagues and much enjoy the rich culture and fascinating challenges of living in a rapidly changing society. Well-satisfied expats such as myself are not few in number. No surprise, the key is learning the language and using it for creative engagement with Korean society.

That said, I think it's fair to say that among many Koreans Samsung is viewed with respect but no affection. The company history dates back to the Japanese colonial period and is imbued with the pre-WWII Japanese zaibatsu mentality. What some posters are generalizing as "Korean" seems more the rather specialized local culture of Samsung. Personally, I would never work for them.

All I'm saying is that if I'm going to fall in love with the brand, it would be nice if the employees of the company also have the same love for it.

This quote from the parent comment: "Samsung managers are often corrupt and treat their employees like trash"

makes me feel like I'm not fully aware what really goes on and is not something I like to actively support.

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.

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.