4 ms·

> Orchestration, in general, isn't needed. The major cloud providers are already doing it with virtual machines, and have been for a long time. It's better isol

by gizdan 5y ago

> Orchestration, in general, isn't needed. The major cloud providers are already doing it with virtual machines, and have been for a long time. It's better isolation than Kubernetes can provide. Sure it's not needed! But cloud providers aren't needed in much the same way.

dolni 5y ago
Uh... what? Apples and oranges. Whatever convenience you think Kubernetes provides over EC2/autoscaling (which Kubernetes uses, by the way) is several orders of magnitude less than the convenience of using a cloud provider. That you would draw on-prem versus cloud as an equivalency to Kube vs other deployment methods reeks of inexperience, to me. edit: Oh no, I seem to triggered a drive by Kube fanboy or two. Yes, stealth downvote because you disagree without defending your position. You will do so much to show how right you are.
- gizdan 5y ago
  Right, my point is, you can always run your infra much the same AWS runs their infra. Cloud providers give you certain advantages that on prem doesn't have, and vice versa. Equally, running container orchestration gives you advantages AWS cannot give you (as well as k8s does anyway), and vice versa. I'm a definitely fan of K8s, but I'm not defending it here, however, to saying orchestration isn't needed is silly. In a way what AWS provides is orchestration, it's just for VMs instead of containers. As a devops engineer I've worked with a lot of individuals and with a lot of tooling, and so far I can only say my opinion for container orchestation has only grown stronger. I recall having to explain to certain developers how they have to first figure out more than 5 different services for AWS, then use packer to build an AMI, which is provisioned using Chef, then they have to terraform the relevant services, then use cloud-init to pull configuration values. All in all I had to do most of the work, and the code was scattered in several places. Compare that with a Dockerfile, a pipeline, and some manifest in the same repo. I've seen teams deploy a completely new application from first commit to production in less than a week, with next to zero knowledge of K8s when they started. The same teams, who weren't pros but had a bit of experience with AWS, took several weeks to deploy services of similar complexity on EC2. Saving two weeks of Developer's time and headaches is a lot, considering they're one of the most expensive expenses a company has.
  - throwdbaaway 5y ago
    > I recall having to explain to certain developers how they have to first figure out more than 5 different services for AWS, then use packer to build an AMI, which is provisioned using Chef, then they have to terraform the relevant services, then use cloud-init to pull configuration values. All in all I had to do most of the work, and the code was scattered in several places. That sounds horrible. You can actually do all that from a single repository, using just ansible alone, with one cli invocation: - use packer to build an AMI => ansible - provisioned using Chef => ansible - terraform the relevant services => ansible - use cloud-init to pull configuration values => baked into the image

by gizdan 5y ago

dolni 5y ago

Uh... what? Apples and oranges. Whatever convenience you think Kubernetes provides over EC2/autoscaling (which Kubernetes uses, by the way) is several orders of magnitude less than the convenience of using a cloud provider. That you would draw on-prem versus cloud as an equivalency to Kube vs other deployment methods reeks of inexperience, to me. edit: Oh no, I seem to triggered a drive by Kube fanboy or two. Yes, stealth downvote because you disagree without defending your position. You will do so much to show how right you are.

gizdan 5y ago
Right, my point is, you can always run your infra much the same AWS runs their infra. Cloud providers give you certain advantages that on prem doesn't have, and vice versa. Equally, running container orchestration gives you advantages AWS cannot give you (as well as k8s does anyway), and vice versa. I'm a definitely fan of K8s, but I'm not defending it here, however, to saying orchestration isn't needed is silly. In a way what AWS provides is orchestration, it's just for VMs instead of containers. As a devops engineer I've worked with a lot of individuals and with a lot of tooling, and so far I can only say my opinion for container orchestation has only grown stronger. I recall having to explain to certain developers how they have to first figure out more than 5 different services for AWS, then use packer to build an AMI, which is provisioned using Chef, then they have to terraform the relevant services, then use cloud-init to pull configuration values. All in all I had to do most of the work, and the code was scattered in several places. Compare that with a Dockerfile, a pipeline, and some manifest in the same repo. I've seen teams deploy a completely new application from first commit to production in less than a week, with next to zero knowledge of K8s when they started. The same teams, who weren't pros but had a bit of experience with AWS, took several weeks to deploy services of similar complexity on EC2. Saving two weeks of Developer's time and headaches is a lot, considering they're one of the most expensive expenses a company has.
- throwdbaaway 5y ago
  > I recall having to explain to certain developers how they have to first figure out more than 5 different services for AWS, then use packer to build an AMI, which is provisioned using Chef, then they have to terraform the relevant services, then use cloud-init to pull configuration values. All in all I had to do most of the work, and the code was scattered in several places. That sounds horrible. You can actually do all that from a single repository, using just ansible alone, with one cli invocation: - use packer to build an AMI => ansible - provisioned using Chef => ansible - terraform the relevant services => ansible - use cloud-init to pull configuration values => baked into the image