4 ms·

I’d say you don’t need k8s. You just need a good terraform module to set things up for quickly on multiple providers. K8s is worth all the work cus then you c

by eof 5y ago

I’d say you don’t need k8s. You just need a good terraform module to set things up for quickly on multiple providers. K8s is worth all the work cus then you can scale magically. You don’t need to scale magically. You just need to be able to easily deploy. In fact if you think scale will never be an issue you could just run it on hardware, seems like everything would easily fit in a single server.

p_l 5y ago
And with terraform, you're going to be writing pretty much from scratch with every provider out there, as outside of very basics of infrastructure the offerings differ wildly, and even if all you need is a VM with dumb load balancer you have to write ~5x$CLOUD_PROVIDERS resources and abstract it around. Personally k8s is least interesting in scaling, because you could easily scale with other options if you had money to burn
- jeltz 5y ago
  The same is true for Kubernetes too from my experience. Only the very basics of it works cross provider.
  - p_l 5y ago
    Thing is, nothing in Terraform works cross-provider - it's just a (often clunky, though it got better) DSL over JSON which makes for nicer way to call vendor APIs. But I need to know all the details of those APIs anyway. With K8s, the basics that "just work" are pretty wide, the bits that are specific to vendor that are necessary are usually small and contained, and for everything else I have extensible API that allows abstractions like crossplane.io
    - eof 5y ago
      ecosystem is changing rapidly. i actually couldn't say if this is true as I have not played with any of the hosted k8s environments outside of highly complex real world usage. it does seem completely plausible that within the last year or so hosted environments are stable enough and standardized enough that k8s can be a target directly even for small projects. cool. i will try for my next one
      - p_l 5y ago
        The state I described above was somewhat solid by early 2017. Biggest possible issues were if you wanted to pass things like cloud credentials to your apps etc., but standard k8s resources worked pretty well with at most some extra annotations to for example link a Service of type LoadBalancer with specific pre-allocated IP.
magicalhippo 5y ago
> You just need a good terraform module Thank you, I've looked into Terraform before, but had half-way forgotten it. Thanks for the reminder, will have to check out again. > seems like everything would easily fit in a single server We probably need a few. Our client application and integrations do quite a lot of crunching at times. The largest client mentioned has a 16-core server with 64GB RAM for DB and integrations alone, and that is not over-provisioned by any means. They have two or three Citrix servers for the client in addition. Obviously things would be a bit different with something web-based, but more crunching would have to move to server-side due to DB latency. For smaller customers we do fit several of them on a single beefy server currently, and could very likely move forward with that.
- mirceal 5y ago
  are you going to run on multiple clouds or are you targeting just one cloud?
  - magicalhippo 5y ago
    That's the thing. We would probably be happy on one cloud, but I'm worried about not being able to move if the cloud-vendor conditions change. That's why I'd prefer to avoid getting to married to the solutions from a single cloud vendor.
    - eof 5y ago
      if you stick with terraform; it is true that each implementation will be different for each provider. they will be similar for sure but each will be made individually. that said, that is a very very small task to change cloud providers and shouldn't deter you. also as you said, you can easily just start with one.
      - mirceal 5y ago
        changing cloud providers is not a small task
- 5y ago

by eof 5y ago

p_l 5y ago

And with terraform, you're going to be writing pretty much from scratch with every provider out there, as outside of very basics of infrastructure the offerings differ wildly, and even if all you need is a VM with dumb load balancer you have to write ~5x$CLOUD_PROVIDERS resources and abstract it around. Personally k8s is least interesting in scaling, because you could easily scale with other options if you had money to burn

jeltz 5y ago
The same is true for Kubernetes too from my experience. Only the very basics of it works cross provider.
- p_l 5y ago
  Thing is, nothing in Terraform works cross-provider - it's just a (often clunky, though it got better) DSL over JSON which makes for nicer way to call vendor APIs. But I need to know all the details of those APIs anyway. With K8s, the basics that "just work" are pretty wide, the bits that are specific to vendor that are necessary are usually small and contained, and for everything else I have extensible API that allows abstractions like crossplane.io
  - eof 5y ago
    ecosystem is changing rapidly. i actually couldn't say if this is true as I have not played with any of the hosted k8s environments outside of highly complex real world usage. it does seem completely plausible that within the last year or so hosted environments are stable enough and standardized enough that k8s can be a target directly even for small projects. cool. i will try for my next one
    - p_l 5y ago
      The state I described above was somewhat solid by early 2017. Biggest possible issues were if you wanted to pass things like cloud credentials to your apps etc., but standard k8s resources worked pretty well with at most some extra annotations to for example link a Service of type LoadBalancer with specific pre-allocated IP.

magicalhippo 5y ago

> You just need a good terraform module Thank you, I've looked into Terraform before, but had half-way forgotten it. Thanks for the reminder, will have to check out again. > seems like everything would easily fit in a single server We probably need a few. Our client application and integrations do quite a lot of crunching at times. The largest client mentioned has a 16-core server with 64GB RAM for DB and integrations alone, and that is not over-provisioned by any means. They have two or three Citrix servers for the client in addition. Obviously things would be a bit different with something web-based, but more crunching would have to move to server-side due to DB latency. For smaller customers we do fit several of them on a single beefy server currently, and could very likely move forward with that.

mirceal 5y ago
are you going to run on multiple clouds or are you targeting just one cloud?
- magicalhippo 5y ago
  That's the thing. We would probably be happy on one cloud, but I'm worried about not being able to move if the cloud-vendor conditions change. That's why I'd prefer to avoid getting to married to the solutions from a single cloud vendor.
  - eof 5y ago
    if you stick with terraform; it is true that each implementation will be different for each provider. they will be similar for sure but each will be made individually. that said, that is a very very small task to change cloud providers and shouldn't deter you. also as you said, you can easily just start with one.
    - mirceal 5y ago
      changing cloud providers is not a small task
5y ago