5 ms·

I agree with the point that production is hard. There's so many things you just don't think about as a developer that end up being important. Log storage, certi

I agree with the point that production is hard. There's so many things you just don't think about as a developer that end up being important. Log storage, certificate renewal, etc. I think how "hard" kubernetes is depends on how deep you go. If you're building a cluster from scratch, on your own hardware, setting up the control plane yourself etc. it's very very hard. On the other hand, if you're using a hosted service like EKS and you can hand off the hardware and control plane management to someone else, IMO it's actually very easy to use; I actually find it a lot easier than working with the constellation of services amazon has to offer for instance. I do think there are parts of it where "best practices" are still being worked out though, like managing YAML files. There's also definitely some rough edges. Like, Helm charts are great... to use. They're an absolute nightmare to write, and there's all sorts of delightful corner cases like not being able to reliably upgrade things that use StatefulSet (last I used anyway). It's not perfect, but honestly if you learn the core concepts and use a hosted service you can get a lot out of it.

sshine 4y ago
> If you're building a cluster from scratch, on your own hardware, setting up the control plane yourself etc. it's very very hard. I'd like to make a distinction: If you do cluster deployment from scratch, Kubernetes actually gets easier. Because you get good at it. What it also gets is more time-consuming. If you aim to replicate all of AWS, then unrealistically so. The art is knowing when to stop. For a lot of people that's even before Kubernetes. For others, you can run all your apps in a cluster, except persistent storage.
- kazen44 4y ago
  At the end of the day, getting a stable production environment is simply a tradeoff between the amount of complexity you need to make your infrastructure do what you want, and reducing complexity because it removes failure points from the production environment. K8s is nice and all, but if all you really need can be solved by 2 VM's and a way to announce an anycast address (or use a loadbalancer if that is not an option), why would i add all that complexity?
  - sshine 4y ago
    I totally agree. I've gotten away with docker-compose for container orchestration for the last 16 months.
  - b33j0r 4y ago
    For reasons of experience, all I ever want from a system is that it’s reproducible. I had a vanity website running k8s in a managed cloud. I thought I was backed up by my provider and original ansible deployment, which was of course developed iteratively. I originally did this mostly to do a practice deployment, and get the workflow. A few years later, it went down and I didn’t notice for a few weeks. It was too unimportant to invest in monitoring, and not worth it to do over. Redeploying gave me lots of confusing errors (note: I also do this stuff for work) Frankly, I was surprised that the provider doing updates would make my years-stable site fall over. I haven’t tried that one again for funsies, yet. It’s the vendor specificity that was my d’oh!
ActorNightly 4y ago
I disagree that production is hard in itself, I think the way people approach production makes it needlessly more difficult. It seems that when launching a service, everyone seems to try to get the entire stack in one shot, which is difficult. A much better approach is "1. Make it work 2. Make it good 3. Make it fast". Your initial prototypes need to define the core functionality, and then you incrementally build stuff on top of that.
- Veuxdo 4y ago
  Security as well. Now step 0 is "Make it secure". When using microservices connected via the internet, you have no choice.
  - madeofpalk 4y ago
    > When using microservices 1. Make it work
  - dgroshev 4y ago
    Security is a spectrum. You can go from out of the box Debian listening on 22/80/443 directly on internet to WAF, intrusion detection, encrypted overlay networks with CA hierarchy and offline route keys, encryption at rest, elaborate IAM, hardware signed commits, full supply chain audits with every dependency vetted and vendored, multi-access-level logs, mandatory spyware on all corporate gear, and so on and so forth. For most businesses it's more of the former than the latter, and there's definitely no such thing as categorically "secure".
- lcw 4y ago
  > 1. Make it work 2. Make it good 3. Make it fast Anecdotally, everytime someone tells me Kubernetes is overkill and then follows your approach. In a year they end up building the capabilities that come out of the box with Kubernetes, and of course they aren't as well thought out. Because they were done adhoc and as needed.
  - dgroshev 4y ago

sshine 4y ago

> If you're building a cluster from scratch, on your own hardware, setting up the control plane yourself etc. it's very very hard. I'd like to make a distinction: If you do cluster deployment from scratch, Kubernetes actually gets easier. Because you get good at it. What it also gets is more time-consuming. If you aim to replicate all of AWS, then unrealistically so. The art is knowing when to stop. For a lot of people that's even before Kubernetes. For others, you can run all your apps in a cluster, except persistent storage.

kazen44 4y ago
At the end of the day, getting a stable production environment is simply a tradeoff between the amount of complexity you need to make your infrastructure do what you want, and reducing complexity because it removes failure points from the production environment. K8s is nice and all, but if all you really need can be solved by 2 VM's and a way to announce an anycast address (or use a loadbalancer if that is not an option), why would i add all that complexity?
- sshine 4y ago
  I totally agree. I've gotten away with docker-compose for container orchestration for the last 16 months.
- b33j0r 4y ago
  For reasons of experience, all I ever want from a system is that it’s reproducible. I had a vanity website running k8s in a managed cloud. I thought I was backed up by my provider and original ansible deployment, which was of course developed iteratively. I originally did this mostly to do a practice deployment, and get the workflow. A few years later, it went down and I didn’t notice for a few weeks. It was too unimportant to invest in monitoring, and not worth it to do over. Redeploying gave me lots of confusing errors (note: I also do this stuff for work) Frankly, I was surprised that the provider doing updates would make my years-stable site fall over. I haven’t tried that one again for funsies, yet. It’s the vendor specificity that was my d’oh!

ActorNightly 4y ago

I disagree that production is hard in itself, I think the way people approach production makes it needlessly more difficult. It seems that when launching a service, everyone seems to try to get the entire stack in one shot, which is difficult. A much better approach is "1. Make it work 2. Make it good 3. Make it fast". Your initial prototypes need to define the core functionality, and then you incrementally build stuff on top of that.

Veuxdo 4y ago
Security as well. Now step 0 is "Make it secure". When using microservices connected via the internet, you have no choice.
- madeofpalk 4y ago
  > When using microservices 1. Make it work
- dgroshev 4y ago
  Security is a spectrum. You can go from out of the box Debian listening on 22/80/443 directly on internet to WAF, intrusion detection, encrypted overlay networks with CA hierarchy and offline route keys, encryption at rest, elaborate IAM, hardware signed commits, full supply chain audits with every dependency vetted and vendored, multi-access-level logs, mandatory spyware on all corporate gear, and so on and so forth. For most businesses it's more of the former than the latter, and there's definitely no such thing as categorically "secure".
lcw 4y ago
> 1. Make it work 2. Make it good 3. Make it fast Anecdotally, everytime someone tells me Kubernetes is overkill and then follows your approach. In a year they end up building the capabilities that come out of the box with Kubernetes, and of course they aren't as well thought out. Because they were done adhoc and as needed.
- dgroshev 4y ago