6 ms·

What makes containers in general, and Kubernetes specifically, compelling to me are the following: - the deployment artifact is a "fresh" instance that's "boot

What makes containers in general, and Kubernetes specifically, compelling to me are the following: - the deployment artifact is a "fresh" instance that's "booted" in a fraction of the time—as in a couple of seconds vs a few minutes—than a new EC2 instance would be - since the deployment artifact is a fresh instance, there is no need to manipulate an existing instance already running your application as part of your deploy process (e.g. scp, ssh, unpack, run commands, restart/reload application) - if you design your build pipeline appropriately, the actual data needed to be shipped is effectively just a diff from the previous image. In my org, that could mean the difference between shipping a 300MB vehicle to ~300 instances and shipping a 300KB vehicle to almost certainly less than 300 Kubernetes nodes There are other things as well, but I wanted to stay roughly within the parameters of your examples. If your organization doesn't already have a continuous integration story, I'd say it probably isn't ready for containers in production. If your cloud footprint isn't costing you let's say >= $50k/mo or so, I might argue that the engineering effort to Kubernetize your things is probably better spent in more direct ways on your product. If you do have a CI/CD story, and you do have a very wide, expansive, and expensive cloud footprint, containers and Kubernetes are extremely compelling possible solutions.

cryptarch 9y ago
What if you're in the ground-zero scenario: there is an application but practically no infrastructure? I'm in that situation now (with a SaaS product), and my approach so far has been: * set up tests * set up Docker images * set up docker-compose for easy local deployments * do lots of work to make the app behave inside Docker * take control of AWS and IAM using CloudFormation, making it easy to set up and roll back permissions * bootstrap KOPS/K8s with CloudFormation Future work: * set up Jenkins CI on top of K8s * K8s deployments of the app for CI * staging K8s deployments * K8s in production This has been my first venture in operations and it's been very interesting and rewarding, but at times it gets very intimidating to "be" operations with no senior guidance. I enjoy the freedom and responsibility and I feel like I at least have a significantly better grasp on this than anyone else in the company, but I wish I knew of a way to feel like my work was good in an absolute sense, like "definitely good enough". Has anyone here gone through a similar scenario, bootstrapping ops infrastructure in a small business? Would you have any remarks regarding architecture, or the politics required to make the importance of solid ops and the improvement of software reliability and security clear?
- brianwawok 9y ago
  Generally it's fun resume builder but not actually time well spent on your business. One super server can go far enough and hopefully you can design it to be able to scale as needed later.
  - jameskegel 9y ago
    This is a risky assertion to make, in some cases for us.
    - jerf 9y ago
      All engineering advice comes with the implicit caveat "subject to your local concerns". Yes, of course you may be working in a startup that requires 25GPUs to serve even one customer. No sarcasm. I can imagine some startups that might meet that requirement. But there are an awful lot of startups that start massively overengineering their footprint early when all they need is a web server with a cold or hot spare (use a load balancer with automatic failover if you've got one in your cloud or something, if not I wouldn't stress, and automatic failover on prototype-level application code can cause its own issues) and a database server with a good backup story and some mechanism for quickly bringing up a new one if necessary. (This generally leads you to some sort of clustering thing or a hot replicated spare because it doesn't take long before your database requires hours to rebuild from a backup or something.) You're often better served just giving occasional thought to how you might split things up in the future and using that to at least hint your design than actually splitting things up immediately.
  - aeorgnoieang 9y ago
    > you can design it to be able to scale as needed later What's different about what you're referring to above and what the commenter mentioned? It seems to me like they were designing the app to be able to scale.
    - brianwawok 9y ago
      Except they are also doing the dev-ops yucky work to do the scaling. It is a lot of extra work with no value until later. Say they are making a crud app. Keep no state in session. Deploy as easily as possible. Boom, done. Later you can add a load balancer to scale to 100 servers. Right now you can run it on 1. It is 'designed to scale'. But actually running your single app in a 1 node k8s cluster? That is days of extra work for nothing right now.

cryptarch 9y ago

What if you're in the ground-zero scenario: there is an application but practically no infrastructure? I'm in that situation now (with a SaaS product), and my approach so far has been: * set up tests * set up Docker images * set up docker-compose for easy local deployments * do lots of work to make the app behave inside Docker * take control of AWS and IAM using CloudFormation, making it easy to set up and roll back permissions * bootstrap KOPS/K8s with CloudFormation Future work: * set up Jenkins CI on top of K8s * K8s deployments of the app for CI * staging K8s deployments * K8s in production This has been my first venture in operations and it's been very interesting and rewarding, but at times it gets very intimidating to "be" operations with no senior guidance. I enjoy the freedom and responsibility and I feel like I at least have a significantly better grasp on this than anyone else in the company, but I wish I knew of a way to feel like my work was good in an absolute sense, like "definitely good enough". Has anyone here gone through a similar scenario, bootstrapping ops infrastructure in a small business? Would you have any remarks regarding architecture, or the politics required to make the importance of solid ops and the improvement of software reliability and security clear?

brianwawok 9y ago
Generally it's fun resume builder but not actually time well spent on your business. One super server can go far enough and hopefully you can design it to be able to scale as needed later.
- jameskegel 9y ago
  This is a risky assertion to make, in some cases for us.
  - jerf 9y ago
    All engineering advice comes with the implicit caveat "subject to your local concerns". Yes, of course you may be working in a startup that requires 25GPUs to serve even one customer. No sarcasm. I can imagine some startups that might meet that requirement. But there are an awful lot of startups that start massively overengineering their footprint early when all they need is a web server with a cold or hot spare (use a load balancer with automatic failover if you've got one in your cloud or something, if not I wouldn't stress, and automatic failover on prototype-level application code can cause its own issues) and a database server with a good backup story and some mechanism for quickly bringing up a new one if necessary. (This generally leads you to some sort of clustering thing or a hot replicated spare because it doesn't take long before your database requires hours to rebuild from a backup or something.) You're often better served just giving occasional thought to how you might split things up in the future and using that to at least hint your design than actually splitting things up immediately.
- aeorgnoieang 9y ago
  > you can design it to be able to scale as needed later What's different about what you're referring to above and what the commenter mentioned? It seems to me like they were designing the app to be able to scale.
  - brianwawok 9y ago
    Except they are also doing the dev-ops yucky work to do the scaling. It is a lot of extra work with no value until later. Say they are making a crud app. Keep no state in session. Deploy as easily as possible. Boom, done. Later you can add a load balancer to scale to 100 servers. Right now you can run it on 1. It is 'designed to scale'. But actually running your single app in a 1 node k8s cluster? That is days of extra work for nothing right now.