3 ms·

If you're going to deploy to a cloud service you are likely going to use the Kubernetes service provided by the cloud. EKS, AKS, GKE, etc. You don't need to slo

by mfer 5y ago

If you're going to deploy to a cloud service you are likely going to use the Kubernetes service provided by the cloud. EKS, AKS, GKE, etc. You don't need to slog through anything with those. Most people aren't going to be Kubernetes operators and will use the tools that are easy for them so they can focus on what they are doing (which isn't about operating a cluster). Time is finite and most people don't have the job of being Kubernetes experts. They are spending their time using it to do something else. Managed tools make it possible for them to spend more time on what's important to them.

smackeyacky 5y ago
Well, yeah, but how do you move from Docker Desktop kubernetes to something like AKS? Some time back, one of the things stopping me from migrating off Visual Studio was that I had been relying on the integrated tools to help with deployment of my small system. I came to the sudden realisation that I had no idea exactly what to do to deploy something like a lambda function or a container into ECS, because it was being done for me by the AWS Visual Studio toolkit. It's kind of dangerous in lots of ways. You have little idea of security contexts, of how the different parts interact, of what you might be accidentally exposing to the general internet. It's like anything that demos well: it hides all the stuff you need to know about at the expense of trying to get you started quickly. Hiding all the dodgy decisions the wizard makers make will get you burned. In the end, I would have been much better off learning the AWS CLI - I ended up having to do it anyway to utilise a github action to do my deployments. At the very least, these tools should spit out the commands they are running in some kind of ordered fashion so you can "play along". Long term, the hand-holding is counter productive for most developers.
- twblalock 5y ago
  > Long term, the hand-holding is counter productive for most developers. Most developers will never set up a Kubernetes cluster from scratch, and they don't need to know how to do it, and outside of very small companies they probably won't even be allowed to do it. At most they will write a Helm chart or something similar, in order to install their software in a Kubernetes cluster that is maintained by SRE or a cloud provider.

by mfer 5y ago

smackeyacky 5y ago

Well, yeah, but how do you move from Docker Desktop kubernetes to something like AKS? Some time back, one of the things stopping me from migrating off Visual Studio was that I had been relying on the integrated tools to help with deployment of my small system. I came to the sudden realisation that I had no idea exactly what to do to deploy something like a lambda function or a container into ECS, because it was being done for me by the AWS Visual Studio toolkit. It's kind of dangerous in lots of ways. You have little idea of security contexts, of how the different parts interact, of what you might be accidentally exposing to the general internet. It's like anything that demos well: it hides all the stuff you need to know about at the expense of trying to get you started quickly. Hiding all the dodgy decisions the wizard makers make will get you burned. In the end, I would have been much better off learning the AWS CLI - I ended up having to do it anyway to utilise a github action to do my deployments. At the very least, these tools should spit out the commands they are running in some kind of ordered fashion so you can "play along". Long term, the hand-holding is counter productive for most developers.

twblalock 5y ago
> Long term, the hand-holding is counter productive for most developers. Most developers will never set up a Kubernetes cluster from scratch, and they don't need to know how to do it, and outside of very small companies they probably won't even be allowed to do it. At most they will write a Helm chart or something similar, in order to install their software in a Kubernetes cluster that is maintained by SRE or a cloud provider.