5 ms·

I have to disagree. It doesn't introduce burden and complexity. They're already there whether you use Kubernetes or not. The difference is that if you did buil

I have to disagree. It doesn't introduce burden and complexity. They're already there whether you use Kubernetes or not. The difference is that if you did build it all by hand as the author said, if it ever scales, you're going to have double the job to make it scale. It's all a question of: do I think my software will succeed? If it's a hobby project that will never get big, it's not worth the hassle. If it actually has a chance of succeeding, the small added complexity of Kubernetes will pay dividends extremely quickly when the system needs to scale. Even with as little as two machines, I'd argue k8s is already adding more value than managing those by hand. People can say otherwise because they're used to it, but being used to it is not the point of the discussion. The author also talks about Ansible which is another piece of complexity that would be comparable with doing it in k8s. I'd argue you have less YAMLs with k8s than with Ansible for a small project. The only argument I see for doing anything by hand today is if it's a play thing.

carlosrdrz 8y ago
I see what you mean, but I don't really agree. You can introduce that burden and complexity whenever you want. If you spend the start of your project working on this, you will be prepared for scaling (if you ever need it) but you could have used that time on actually working on the project and checking if you actually will need scale at some point. I don't know about your projects, but I'm my case most (all) of them doesn't really need any kind of scale. Hell, this blog has a tiny 5$ DO machine and is still happily serving traffic from HN. I do understand not all projects are small blog instances, though :) I guess in my case I prefer to just keep it simple and see how far I go with that setup than spending time working on making the perfectly-scalable project that is never serving more than 2 requests per second. If it ever grows, I will need to work to make it scale, sure, but on the other hand that is a good problem to have. Anyway, I understand this is pretty subjective and depends on how you think about your projects and your requirements, so I do understand there will be people both in agreement and disagreement.
- Draiken 8y ago
  I completely agree it's overkill to run your own cluster. That'd be good for a learning experience, but way too complex to use/maintain otherwise. However I read somewhere you had experience with Kubernetes, right? That means there is no extra work to learn the technology. Now let's take your blog as an example. I'm gonna guess there's an official Docker image for whatever software you use and you could create an image, deployment + service + ingress in less than an hour for it (pretty much every example out there is about how to setup a blog, heh). If you have to do all that manually through SSH, I'd argue it takes pretty much the same time and the complexity is the same. You will simply change the tools/concepts but won't be caught by manual gotchas.
falcolas 8y ago
Let's talk about complexity for a moment, for one aspect of a simple service: ingress. Kubernetes: apiVersion: extensions/v1beta1 kind: Ingress metadata: name: test-ingress spec: rules: - http: paths: - path: /testpath backend: serviceName: test servicePort: 80 Nginx: location /testpath { proxy_path http://127.0.0.1:8080 } Which is less complex? Which is beta, and thus could be changed over time (it happens a lot). Which one requires major (and breaking) infrastructure updates every 3 months? > I'd argue you have less YAMLs with k8s than with Ansible for a small project. Since you typically need one yaml document per K8s resource, and can describe multiple independent and idempotant actions in one Ansible document, I think this is easily demonstrable as false for small projects (and likely big projects as well).
- justinsaccount 8y ago
  The first one is a complete configuration you could kubectl apply into a cluster that sends traffic to a backend service that may be running across multiple instances on multiple machines. The second is a configuration fragment that is useless by itself that would send all traffic to a single instance running on localhost.
  - falcolas 8y ago
    You can just drop it in a conf.d folder created by the package install and it would work just fine. Also we're talking simple projects, and simple projects are typically not distributed; typically don't need to be distributed. That said, supporting multiple backends with different load balancing algorithms is also pretty simple to write as well.
    - justinsaccount 8y ago
      Ok, great... I have a bunch of simple projects like that, one web instance running on a single host. How do I safely upgrade it without downtime? Ensuring that the new version starts up properly and can receive traffic before sending it requests and stopping the old one? With k8s: kubectl set image deployment/my-deployment mycontainer=myimage:1.9.1 (or just use kubectl apply -f) With your nginx config: ????
munchbunny 8y ago
> do I think my software will succeed? With hobby projects for the vast majority of people, the answer is somewhere in the territory of "you can worry about that after it succeeds."

carlosrdrz 8y ago

I see what you mean, but I don't really agree. You can introduce that burden and complexity whenever you want. If you spend the start of your project working on this, you will be prepared for scaling (if you ever need it) but you could have used that time on actually working on the project and checking if you actually will need scale at some point. I don't know about your projects, but I'm my case most (all) of them doesn't really need any kind of scale. Hell, this blog has a tiny 5$ DO machine and is still happily serving traffic from HN. I do understand not all projects are small blog instances, though :) I guess in my case I prefer to just keep it simple and see how far I go with that setup than spending time working on making the perfectly-scalable project that is never serving more than 2 requests per second. If it ever grows, I will need to work to make it scale, sure, but on the other hand that is a good problem to have. Anyway, I understand this is pretty subjective and depends on how you think about your projects and your requirements, so I do understand there will be people both in agreement and disagreement.

Draiken 8y ago
I completely agree it's overkill to run your own cluster. That'd be good for a learning experience, but way too complex to use/maintain otherwise. However I read somewhere you had experience with Kubernetes, right? That means there is no extra work to learn the technology. Now let's take your blog as an example. I'm gonna guess there's an official Docker image for whatever software you use and you could create an image, deployment + service + ingress in less than an hour for it (pretty much every example out there is about how to setup a blog, heh). If you have to do all that manually through SSH, I'd argue it takes pretty much the same time and the complexity is the same. You will simply change the tools/concepts but won't be caught by manual gotchas.

falcolas 8y ago

Let's talk about complexity for a moment, for one aspect of a simple service: ingress. Kubernetes: apiVersion: extensions/v1beta1 kind: Ingress metadata: name: test-ingress spec: rules: - http: paths: - path: /testpath backend: serviceName: test servicePort: 80 Nginx: location /testpath { proxy_path http://127.0.0.1:8080 } Which is less complex? Which is beta, and thus could be changed over time (it happens a lot). Which one requires major (and breaking) infrastructure updates every 3 months? > I'd argue you have less YAMLs with k8s than with Ansible for a small project. Since you typically need one yaml document per K8s resource, and can describe multiple independent and idempotant actions in one Ansible document, I think this is easily demonstrable as false for small projects (and likely big projects as well).

justinsaccount 8y ago
The first one is a complete configuration you could kubectl apply into a cluster that sends traffic to a backend service that may be running across multiple instances on multiple machines. The second is a configuration fragment that is useless by itself that would send all traffic to a single instance running on localhost.
- falcolas 8y ago
  You can just drop it in a conf.d folder created by the package install and it would work just fine. Also we're talking simple projects, and simple projects are typically not distributed; typically don't need to be distributed. That said, supporting multiple backends with different load balancing algorithms is also pretty simple to write as well.
  - justinsaccount 8y ago
    Ok, great... I have a bunch of simple projects like that, one web instance running on a single host. How do I safely upgrade it without downtime? Ensuring that the new version starts up properly and can receive traffic before sending it requests and stopping the old one? With k8s: kubectl set image deployment/my-deployment mycontainer=myimage:1.9.1 (or just use kubectl apply -f) With your nginx config: ????

munchbunny 8y ago

> do I think my software will succeed? With hobby projects for the vast majority of people, the answer is somewhere in the territory of "you can worry about that after it succeeds."