3 ms·

Guy lost me at k8s and terraform - just put your thing on a single VM and yolo.

oooyay 2y ago
I can understand why you'd say that, but I don't think the world's that black and white. Many people would say a detached, Typescript frontend is less simple than SSR. At this point in my career writing a bunch of ad-hoc, per-page Javascript would be more toilsome than writing components. Thus, the prevailing idea of "simple" would be less simple for me. In that same way, if you've spent a large chunk of your career in Kubernetes then managed Kubernetes is probably a lot more simple than maintaining an image production pipeline and a disjointed Terraform deploy. You'd have to make a choice between immutability and non-immutability with VMs as well, and design lifecycles for them if you choose immutability. That choice is made for you with Kubernetes and has well-established patterns. That's to say, simple is highly subjective. Like another comment said, simple is the technology you know best today (and that you can easily hire for).
- marcosdumay 2y ago
  > You'd have to make a choice between immutability and non-immutability with VMs as well I'd like to emphasize the yolo from the GP. I does really not imply image maintenance and immutability. (By the way, "non-immutability" is called "mutability".) And no, if you know kubernetes to your heart, it's still very often easier to start the grug way and build OPS up only after you have something to run on it. (But, of course, there are exceptions. There are always exceptions.)
tracerbulletx 2y ago
k8s is easy once you know it imo. My recent project I made a Digital ocean cluster and some Github actions to deploy to it in like half an hour, and it would be easy to port to another cloud, or self hosted k8s cluster. It can auto scale nodes, do 0 downtime deployments, bg deployments, has automated certificate provisioning, it does everything I need.
- mrj 2y ago
  I don't know why this is being downvoted, this is my experience too. I don't mess with networking or volumes in k8s but it gives me a lot of stuff out of the box for when I need it later. It takes a couple of minutes to copy and paste the Deployment definition and change a few things. The trouble with "single vm and yolo" it is tech debt of the worst kind. It's not a shortcut you might have to expand on someday, it's the kind where whole platform changes are necessary. Someday that vm process won't be enough and that'll require changing everything about the deploy, potentially at a time when big changes aren't desirable. If the business is starting to pick up so that we need something more reliable, that's the wrong time to want to replatform. I'd rather but in a small amount of upfront knowing that I won't have a big tech debt to pay back later. So I keep it real simple, and keep away from parts that I know will give me a headache. I use a managed service and plan to give it to somebody else when we're big enough to have that somebody else. Then they can worry about the parts I didn't. It's wise not to do too much upfront, for sure. But it's wise not to back into corners that are hard to undo later, too.
  - jonas21 2y ago
    > Someday that vm process won't be enough For a surprisingly large set of cases, that day will never come. I've scaled services to millions of users on a single VM. The best debt is the kind you never have to pay off.
    - mrj 2y ago
      I don't doubt it but you can do that on one computer with k8s too, these are not at odds.

I can understand why you'd say that, but I don't think the world's that black and white. Many people would say a detached, Typescript frontend is less simple than SSR. At this point in my career writing a bunch of ad-hoc, per-page Javascript would be more toilsome than writing components. Thus, the prevailing idea of "simple" would be less simple for me. In that same way, if you've spent a large chunk of your career in Kubernetes then managed Kubernetes is probably a lot more simple than maintaining an image production pipeline and a disjointed Terraform deploy. You'd have to make a choice between immutability and non-immutability with VMs as well, and design lifecycles for them if you choose immutability. That choice is made for you with Kubernetes and has well-established patterns. That's to say, simple is highly subjective. Like another comment said, simple is the technology you know best today (and that you can easily hire for).

marcosdumay 2y ago
> You'd have to make a choice between immutability and non-immutability with VMs as well I'd like to emphasize the yolo from the GP. I does really not imply image maintenance and immutability. (By the way, "non-immutability" is called "mutability".) And no, if you know kubernetes to your heart, it's still very often easier to start the grug way and build OPS up only after you have something to run on it. (But, of course, there are exceptions. There are always exceptions.)

tracerbulletx 2y ago

k8s is easy once you know it imo. My recent project I made a Digital ocean cluster and some Github actions to deploy to it in like half an hour, and it would be easy to port to another cloud, or self hosted k8s cluster. It can auto scale nodes, do 0 downtime deployments, bg deployments, has automated certificate provisioning, it does everything I need.

mrj 2y ago
I don't know why this is being downvoted, this is my experience too. I don't mess with networking or volumes in k8s but it gives me a lot of stuff out of the box for when I need it later. It takes a couple of minutes to copy and paste the Deployment definition and change a few things. The trouble with "single vm and yolo" it is tech debt of the worst kind. It's not a shortcut you might have to expand on someday, it's the kind where whole platform changes are necessary. Someday that vm process won't be enough and that'll require changing everything about the deploy, potentially at a time when big changes aren't desirable. If the business is starting to pick up so that we need something more reliable, that's the wrong time to want to replatform. I'd rather but in a small amount of upfront knowing that I won't have a big tech debt to pay back later. So I keep it real simple, and keep away from parts that I know will give me a headache. I use a managed service and plan to give it to somebody else when we're big enough to have that somebody else. Then they can worry about the parts I didn't. It's wise not to do too much upfront, for sure. But it's wise not to back into corners that are hard to undo later, too.
- jonas21 2y ago
  > Someday that vm process won't be enough For a surprisingly large set of cases, that day will never come. I've scaled services to millions of users on a single VM. The best debt is the kind you never have to pay off.
  - mrj 2y ago
    I don't doubt it but you can do that on one computer with k8s too, these are not at odds.