4 ms·
One year using Kubernetes in production (2016)
- craydandy 7y agoThe article seems to be from year 2016. Maybe it can be added to the headline.
- dang 7y agoAdded. Thanks!
- rawoke083600 7y agoLesson 1. We probably didn't need it.
- xref 7y agoIn 2019, would you choose something else for container orchestration?
- rawoke083600 7y agoI'll rephrase.. You probably didn't need "container orchestration"
- politelemon 7y agoYes - 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'.
- samvher 7y agoSame 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.
- rumanator 7y ago> 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.
- fivre 7y agoSwarm 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.
- lykr0n 7y agoNomad is a solid, less complex, alternative. Docker Swarm is also an option. Mesos. I'm sure if you look you can find others.
- alasdair_ 7y agoLesson 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.
- rawoke083600 7y agoThat'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 ?
- rumanator 7y agoIt'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.
- mburst 7y agoI 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-reddits-gross-clone-1795337099 https://gizmodo.com/goodbye-and-good-riddance-to-voat-reddit...
- alasdair_ 7y agoHonestly? I now work at Facebook and the answer to that question is “all of them”
- ishankhare07 7y agoDon'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.
- 7532yahoogmail 7y agoSales and marketing. Poorly written.