Hacker News new | past | comments | ask | show | jobs | submit login
One year using Kubernetes in production (2016) (techbeacon.com)
30 points by Caitin_Chen 18 days ago | hide | past | web | favorite | 16 comments

The article seems to be from year 2016. Maybe it can be added to the headline.

Added. Thanks!

Don't know why but the post doesn't mention Ingress resources when it comes to exposing and load balancing your services. It is a much better and official way then that mentioned in the article.

Sales and marketing. Poorly written.


Lesson 1.1: Occasionally, ignore lesson 1.

I once worked on a game (Pokemon GO) that went from zero users to over 100 million users in a bit over two weeks.

Scaling was still very, very stressful but it wouldn't have happened at all without Kubernetes.

Thanks guys.

That's Why I said "probably" and not "always", on how many projects have you worked before and after pokemon go that went from zero to 100mil users ?

It's better to accept a tad more complexity upfront than having to figure out midflight how to scale an unscalable solution.

Perhaps another good example is how voat failed to capitalize on reddit's mass exodus because mostly their service was rendered unusable by their apparent inability to scale.

I think Kubernetes adds quite a bit of complexity if you've never worked with it before. As does any technology though really. Much easier these days to drag sliders right for more server resources if needed from AWS, GCP, Heroku, etc. Sure it'll cost more, but you have 100mil users and if your system doesn't scale horizontally you probably have a problem that isn't going to be solved by Kubernetes or any other orchestration system.

As an aside I think Voat failed because the community that came was toxic and the team behind it had no intentions of quelling it. https://gizmodo.com/goodbye-and-good-riddance-to-voat-reddit...

Honestly? I now work at Facebook and the answer to that question is “all of them”

In 2019, would you choose something else for container orchestration?

Yes - I maintain that Swarm is a much simpler offering that's easier to get started with in a 'smaller' setup, or in a mixed environment of monoliths and miniliths and microliths in one big family.

There is much less in terms of cognitive load on the developers, fewer moving parts to know about. Importantly the ability to use the same docker-compose.yml for develop, debug, build, deployment comes with the immense value of the boring sameness that a production deployment should have, and not having to worry over 'one more thing' or 'one more moving part' or 'one more translation layer'.

Swarm might be a simpler option in the sense that FreeBSD is a simpler option than Linux in some cases (perhaps not the most apt comparison, but bear with me). Sure, by itself it may win out on technical merit in some cases, but: * Nothing you want to use will target it as a supported platform. It may very well work, but you're going to be figuring out how it works yourself. * Most community discussion around general architecture/networking/common problems/workarounds for those problems will be for the other, more popular platform. Again, you'll be blazing your own trail.

That all said, figuring how to do this yourself or how to adopt solutions for other platforms can be _fun_. I find it fun. I wish more people found it fun, and believe we'd have a more diverse, vibrant infrastructure ecosystem if most other people also found it fun. In practice, however, I've found that few people find this fun, and those that do have no time to have said fun. Most users I work with ask a combination of "can you provide idiot-proof instructions for this?" and "have other people done this already to hash out the difficult bits?".

For a variety of reasons, Swarm lost the popularity war, and so it doesn't matter what, if anything, it does better.

Same experience here, I feel Docker Swarm is a bit underappreciated. I have experimented with Kubernetes but Swarm seems a lot simpler when you have a mix of stateful and stateless services. You can have many of the benefits of an orchestrator but still manually manage volumes, and configuration files are very understandable.

> Yes - I maintain that Swarm is a much simpler offering that's easier to get started with in a 'smaller' setup, or in a mixed environment of monoliths and miniliths and microliths in one big family.

+1 on Docker Swarm. Although it does have its kinks, it's far simpler to get working, has a smoother learning curve, and does the job well.

I would argue that Docker Swarm is ideal for those cases where it's unlikely you'll need a lot of autoscaling or operate a large cluster.

Nomad is a solid, less complex, alternative. Docker Swarm is also an option. Mesos. I'm sure if you look you can find others.

I'll rephrase..

You probably didn't need "container orchestration"

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact