11 ms·

The odd thing about having 20 years of experience (while simultaneously being wide-eyed about new tech), is that I now have enough confidence to read interestin

by atonse 7y ago

The odd thing about having 20 years of experience (while simultaneously being wide-eyed about new tech), is that I now have enough confidence to read interesting posts (like any post on k8s) and not think "I HAVE to be doing this" – and rather think "good to know when I do need it." Even for the highest scale app I've worked on (which was something like 20 requests per second, not silicon valley insane but more than average), we got by perfectly fine with 3 web servers behind a load balancer, hooked up to a hot-failover RDS instance. And we had 100% uptime in 3 years. I feel things like Packer (allowing for deterministic construction of your server) and Terraform are a lot more necessary at any scale for generally good hygiene and disaster recovery.

wpietri 7y ago
Same. I like trying out new things, so I have a feel for what they're good for. I tried setting up Kubernetes for my home services and pretty quickly got to "nope!" As the article says, it surely makes sense at Google's scale. But it has a large cognitive and operational burden. Too large, I'd say, for most one-team projects.
hinkley 7y ago
I have, at various times in my career, tried to convince others that there is an awful, awful lot of stuff you can get done with a few copies of nginx. The first “service mesh” I ever did was just nginx as a forward proxy on dev boxes, so we could reroute a few endpoints to new code for debugging purposes. And the first time I ever heard of Consul was in the context of automatically updating nginx upstreams for servers coming and going. There is someone at work trying to finish up a large raft of work, and if I hadn’t had my wires crossed about a certain feature set being in nginx versus nginx Plus, I probably would have stopped the whole thing and suggested we just use nginx for it. I think I have said this at work a few times but might have here as well: if nginx or haproxy could natively talk to Consul for upstream data, I’m not sure how much of this other stuff would have ever been necessary. And I kind of feel like Hashicorp missed a big opportunity there. Their DNS solution, while interesting, doesn’t compose well with other things, like putting a cache between your web server and the services. I think we tried to use that DNS solution a while back and found that the DNS lookups were adding a few milliseconds to each call. Which might not sound like much except we have some endpoints that average 10ms. And with fanout, those milliseconds start to pile up.
- notyourday 7y ago
  > I think we tried to use that DNS solution a while back and found that the DNS lookups were adding a few milliseconds to each call. Which might not sound like much except we have some endpoints that average 10ms. And with fanout, those milliseconds start to pile up. Don't resolve DNS inline rather on every DNS update, resolve it and insert new IP addresses.
  - hinkley 7y ago
    Correct me if I'm wrong, but I believe Consul, lacking a mesh of its own, is leveraging the early 1990's era trick of using round robin DNS to split load over available servers. Caching those values for very long subverts the point of the feature.
    - notyourday 7y ago
      Not really - resolve all backend servers to IPs and list all of them as the nginx backends. When a backend server is removed, update nginx backends. Round-robin balancing using DNS towards a small cluster is silly - you know when any new instance is added to the pool or removed from a pool, so why not push that load balancing onto the load balancer which in your case is nginx?
      - hinkley 7y ago
        You're talking about layering the thing on top of Consul that I already identified in my top level comment. Consul itself advertises DNS resolution for service discovery.
        notyourday 7y ago
        Maybe I was not clear. Whatever is the technology that you use to register the active backends in the DNS, rather than doing name => ip address lookup per request, you can resolve all those names => ip address maps upon the service being brought up/taken down and push the resolved map as a set of backends into nginx config, thus removing the need to query DNS per request.
FreeHugs 7y ago
A typical PHP application that does a bit of database updating per request, gets some new data from the DB and templates it should handle 20 requests per second on a single $20/month VM. And in my experience from the last years, VMs have uptime >99.99% these days. What made you settle on a multi-machine setup instead? Was it to reach higher uptime or were you processing very heavy computations per request?
- atonse 7y ago
  Higher uptime and more computation, although this was mostly C# so very efficiently run code. It was an e-commerce site doing +100MM a year. There was little to no room for error. I once introduced a bug in a commit that, in less than an hour, cost us $40,000. So it wasn't about performance. Also this was 9 years ago. So adjust for performance characteristics from back then.
  - dwild 7y ago
    100 000 000$ a year with only 20 requests a second? That's some crazy revenue per request, 100 000 000 / (365 * 24 * 60 * 60) = 3.17$ per request! What were you selling?
    - atonse 7y ago
      Insurance policies :) Good point, actually the 100MM may have included brick and mortar.
    - mytherin 7y ago
      Forgot to multiply by 20, it's actually around $0.15 per request. Still high but certainly not as crazy.
    - aaron_m04 7y ago
      It should be (365 * 24 * 60 * 60 * 20) which brings it to $0.15/req if I did my mental math right. Still a high amount of course.
throwawaymanbot 7y ago
Good Hygiene? erm... what?
sciyoshi 7y ago
There's always more than one way to do things, and it's good to be aware of the trade-offs that different solutions provide. I've worked with systems like you describe in the past, and in my experience you always end up needing more complexity than you might think. First you need to learn Packer, or Terraform, or Salt, or Ansible - how do you pick one? How do you track changes to server configurations and manage server access? How do you do a rolling deploy of a new version - custom SSH scripts, or Fabric/Capistrano, or...? What about rolling back, or doing canary deployments, or...? How do you ensure that dev and CI environments are similar to production so that you don't run into errors from missing/incompatible C dependencies when you deploy? And so on. K8s for us provides a nice, well-documented abstraction over these problems. For sure, there was definitely a learning curve and non-trivial setup time. Could we have done everything without it? Perhaps. But it has had its benefits - for example, being able to spin up new isolated testing environments within a few minutes with just a few lines of code.
- jen20 7y ago
  > First you need to learn Packer, or Terraform, or Salt, or Ansible - how do you pick one? You don't. These are complementary tools. Packer builds images. Salt, Ansible, Puppet or Chef _could_ be used as part of this process, but so can shell scripts (and given the immutability of images in modern workflows, they are the best option). Terraform can be used to deploy images as virtual machines, along with the supporting resources in the target deployment environment.
  - rumanator 7y ago
    > Salt, Ansible, Puppet or Chef _could_ be used as part of this process, but so can shell scripts I don't see the point of your post, and frankly sounds like nitpicking. Ansible is a tool designed to execute scripts remotely through ssh on a collection of servers, and makes the job of writing those scripts trivially easy by a) offering a DSL to write those scripts as a workflow of idempotent operations, and b) offer a myriad of predefined tasks that you can simply add to your scripts and reuse. Sure, you can write shell scripts to do the same thing. But that's a far lower level solution to a common problem, and one that is far hardsr and requires far more man*hours to implement and maintain. With Ansible you only need to write a list of servers, ensure you can ssh into them, and write a high-level description of your workflow as idempotent tasks. It takes you literally a couple of minutes to pull this off. How much time would you take to do the same with your shell scripts?
lazyier 7y ago
Kubernetes has complexity for a reason. It's trying to solve complex problems in a standardized and mature manner. If you don't need those problems solved then it's not going to benefit you a whole lot. Of course if you are using docker already and are following best practices with containers then converting to Kubernetes really isn't that hard. So if you do end up needing more problems solved then you are willing to tackle on your own then switching over is going to be on the table. The way I think about it is if you are struggling to deploy and manage the life cycle of your applications... fail overs, rolling updates, and you think you need some sort of session management like supervisord or something like to manage a cloud of processes and you find yourself trying to install and manage applications and services developed by third parties.... Then probably looking at Kubernetes is a good idea. Let K8s be your session manager, etc.
- throwsprtsdy 7y ago
  What is a "mature manner"?
  - threeseed 7y ago
    For example by covering all of the NFRs. You don't always find open source programs that have dedicated so much effort to security, monitoring, governance etc. And doing so in a very professional and methodical way.
- pavon 7y ago
  I would qualify that a little more. If you are using docker and deploying to a cloud environment already, then moving to a cloud-managed kubernetes cluster really isn't that hard. I've seen too many full-time employees eaten up by underestimating what it takes to deploy and maintain a kubernetes cluster. Their time would have been far better spent on other things.
  - yahyaheee 7y ago
    That story is getting a lot easier but historically was awful
moksly 7y ago
I think anyone considering these wild setups should read about how stackowerflow is hosted on a couple of IIS servers. It’s a sobering reminder that you often don’t need the new cool.
- jiofih 7y ago
  Nothing much happens if SO goes down, they are not doing a ton of business transactions.
  - fishnchips 7y ago
    Nothing much? The world stops producing software:)
    - sgt 7y ago
      He's got a point though. Ironically the world's most highly scaled software are often fairly unimportant. Think Facebook - people would get annoyed if it went down for a day, but it'd soon be forgotten. Your banks are built with less scalable software but is much more critical.
  - pnako 7y ago
    That's right. As opposed to stock exchange software, which runs on complex micro-services cloud k8s thing-as-a-thing virtualized rotozooming engines. Wait, no, it's literally just good-old n-tier architecture with one big server process and some database backend. Pet food delivery startups use k8s to manage their MEAN stack. Meanwhile grown-ups still have "monoliths" connected to something like Oracle, DB2 or MS SQL server, because that's obviously the most reliable setup. The cloud/k8s stuff is an ad-hoc wannabe mainframe built on shaky foundations.
    - rumanator 7y ago
      > Meanwhile grown-ups still have "monoliths" connected to something like Oracle, DB2 or MS SQL server, because that's obviously the most reliable setup. More often than not they just crystalized their 90s knowledge and just pretended there aren't better tools for the job because it would take some work to adopt them and no one notices it in their work anyway. The "Oracle" keyword is a telltale sign.
JMTQp8lwXL 7y ago
Who is giving you 100% uptime? All major providers (AWS, GCP, Azure, etc) all have had outages in the past 3 years. And that level of infrastructural failure doesn't care about whether or not you're using k8s.
- tobib 7y ago
  Not OP but you can achieve higher availability through means like redundancy, availability zones, multi-region deployments, etc.
- threeseed 7y ago
  EKS (AWS Kubernetes) has the control plane across 3 AZs. It is very rare to have a complete region outage so it is pretty close to 100% uptime.
fxtentacle 7y ago
The odd thing about having 10 years of experience as a consultant is that you know when to write "Kubernetes" into a project proposal, even though everyone agrees that it'll be a sub-optimal solution. But both you and their tech lead want to be able to write "used Kubernetes" on your CV in the future, plus future-oriented initiatives inside your contact's company tend to get more budget allocated to them. So it's a sound decision for everyone and for the health of the project to just go with whatever tech is fancy enough, but won't get into the way too badly. Enter Kubernetes, the fashionable Docker upgrade that you won't regret too badly ;)
bitL 7y ago
I worked on a transacted 20-60k messages/s system and am not sure K8S wouldn't be a hindrance there... Imagine writing Kafka using K8S and microservices.
echelon 7y ago
> Even for the highest scale app I've worked on (which was something like 20 requests per second, Kubernetes is not for you. 5kQPS times a hundred or more services and Kubernetes fits the bill. > And we had 100% uptime in 3 years. Not a single request failed in that time serving at 20 QPS? I'm a little suspicious. Regardless, if you were handling 10 or 100 times this volume to a single service, you'd want additional systems in place to assure hitless deploys.
- rumanator 7y ago
  > Not a single request failed in that time serving at 20 QPS? I'm a little suspicious. Things that aren't monitored are also things that don't fail.
closeparen 7y ago
Yes. Three web servers and a load balancer is fine. Three web servers and a load balancer, repeated 1,000 times across the enterprise in idiosyncratic ways and from scratch each time, is less fine. That’s where Kubernetes-shaped solutions (like Mesos that came before it) become appropriate. You can get a lot done with a sailboat. For certain kinds of problems you might genuinely need an aircraft carrier. But then you’d better have a navy. Don’t just wander onto the bridge and start pressing buttons.
- mmazing 7y ago
  You're right. However, a lot of new (or just bad) devs miss the whole Keep It Simple Stupid concept and think that they NEED Kubernetes-shaped solutions in order to "do it the right way". Many times three web servers and a load balancer are exactly what you need.
  - threeseed 7y ago
    And then what about when you need to add monitoring, logging, APM, tracing, application metrics etc. Suddenly you have gone from 3 instances to 20.
    - bdibs 7y ago
      I personally went from 4 servers to 5, self hosting ELK and it works great.
    - mmazing 7y ago
      Adding an entirely new instance is not the only way to accomplish each of those things. A lot of those things can be treated just like applications. You don't need a whole new computer to run Outlook, another computer to run Sublime Text, another computer to run Chrome, etc etc. All of that is irrelevant to my main point though. It's never one size fits all and then all your problems are solved. You are far better off actually assessing your needs and picking the right solution instead of relying on solutions that "worked for bigger companies so they'll work for me" without really giving it a lot of thought if you need to go that far.
cmhnn 7y ago
I don't know about "lot more necessary". The images are one part of the equation especially to meet various regulations. There is a ton to running a large scale service especially if you are the service that the people who are posting how wicked smart they are at k8 service runs on. Google found that out yesterday when they said "oh hey people expect support maybe we should charge". That is not new for grown ups. The cloud existed before k8 and k8's creator has a far less mature cloud than AWS or Azure. But this thread has convinced me of one thing. It's time to re-cloak and never post again because even though the community is a cut above some others at the end of the day it's still a bunch of marks and if you know the inside it is hard to bite your lip.
Damogran6 7y ago
I'm in a similar boat, only my eyes are wide, glazed over, and I'm lost in the word salad...which only seems to be getting worse.
Ill_ban_myself 7y ago
The most important video I've ever watched for my career and sanity: https://www.youtube.com/watch?v=bzkRVzciAZg https://www.youtube.com/watch?v=bzkRVzciAZg

by atonse 7y ago

wpietri 7y ago

Same. I like trying out new things, so I have a feel for what they're good for. I tried setting up Kubernetes for my home services and pretty quickly got to "nope!" As the article says, it surely makes sense at Google's scale. But it has a large cognitive and operational burden. Too large, I'd say, for most one-team projects.

hinkley 7y ago

I have, at various times in my career, tried to convince others that there is an awful, awful lot of stuff you can get done with a few copies of nginx. The first “service mesh” I ever did was just nginx as a forward proxy on dev boxes, so we could reroute a few endpoints to new code for debugging purposes. And the first time I ever heard of Consul was in the context of automatically updating nginx upstreams for servers coming and going. There is someone at work trying to finish up a large raft of work, and if I hadn’t had my wires crossed about a certain feature set being in nginx versus nginx Plus, I probably would have stopped the whole thing and suggested we just use nginx for it. I think I have said this at work a few times but might have here as well: if nginx or haproxy could natively talk to Consul for upstream data, I’m not sure how much of this other stuff would have ever been necessary. And I kind of feel like Hashicorp missed a big opportunity there. Their DNS solution, while interesting, doesn’t compose well with other things, like putting a cache between your web server and the services. I think we tried to use that DNS solution a while back and found that the DNS lookups were adding a few milliseconds to each call. Which might not sound like much except we have some endpoints that average 10ms. And with fanout, those milliseconds start to pile up.

notyourday 7y ago
> I think we tried to use that DNS solution a while back and found that the DNS lookups were adding a few milliseconds to each call. Which might not sound like much except we have some endpoints that average 10ms. And with fanout, those milliseconds start to pile up. Don't resolve DNS inline rather on every DNS update, resolve it and insert new IP addresses.
- hinkley 7y ago
  Correct me if I'm wrong, but I believe Consul, lacking a mesh of its own, is leveraging the early 1990's era trick of using round robin DNS to split load over available servers. Caching those values for very long subverts the point of the feature.
  - notyourday 7y ago
    Not really - resolve all backend servers to IPs and list all of them as the nginx backends. When a backend server is removed, update nginx backends. Round-robin balancing using DNS towards a small cluster is silly - you know when any new instance is added to the pool or removed from a pool, so why not push that load balancing onto the load balancer which in your case is nginx?
    - hinkley 7y ago
      You're talking about layering the thing on top of Consul that I already identified in my top level comment. Consul itself advertises DNS resolution for service discovery.
      - notyourday 7y ago
        Maybe I was not clear. Whatever is the technology that you use to register the active backends in the DNS, rather than doing name => ip address lookup per request, you can resolve all those names => ip address maps upon the service being brought up/taken down and push the resolved map as a set of backends into nginx config, thus removing the need to query DNS per request.

FreeHugs 7y ago

A typical PHP application that does a bit of database updating per request, gets some new data from the DB and templates it should handle 20 requests per second on a single $20/month VM. And in my experience from the last years, VMs have uptime >99.99% these days. What made you settle on a multi-machine setup instead? Was it to reach higher uptime or were you processing very heavy computations per request?

atonse 7y ago
Higher uptime and more computation, although this was mostly C# so very efficiently run code. It was an e-commerce site doing +100MM a year. There was little to no room for error. I once introduced a bug in a commit that, in less than an hour, cost us $40,000. So it wasn't about performance. Also this was 9 years ago. So adjust for performance characteristics from back then.
- dwild 7y ago
  100 000 000$ a year with only 20 requests a second? That's some crazy revenue per request, 100 000 000 / (365 * 24 * 60 * 60) = 3.17$ per request! What were you selling?
  - atonse 7y ago
    Insurance policies :) Good point, actually the 100MM may have included brick and mortar.
  - mytherin 7y ago
    Forgot to multiply by 20, it's actually around $0.15 per request. Still high but certainly not as crazy.
  - aaron_m04 7y ago
    It should be (365 * 24 * 60 * 60 * 20) which brings it to $0.15/req if I did my mental math right. Still a high amount of course.

throwawaymanbot 7y ago

Good Hygiene? erm... what?

sciyoshi 7y ago

There's always more than one way to do things, and it's good to be aware of the trade-offs that different solutions provide. I've worked with systems like you describe in the past, and in my experience you always end up needing more complexity than you might think. First you need to learn Packer, or Terraform, or Salt, or Ansible - how do you pick one? How do you track changes to server configurations and manage server access? How do you do a rolling deploy of a new version - custom SSH scripts, or Fabric/Capistrano, or...? What about rolling back, or doing canary deployments, or...? How do you ensure that dev and CI environments are similar to production so that you don't run into errors from missing/incompatible C dependencies when you deploy? And so on. K8s for us provides a nice, well-documented abstraction over these problems. For sure, there was definitely a learning curve and non-trivial setup time. Could we have done everything without it? Perhaps. But it has had its benefits - for example, being able to spin up new isolated testing environments within a few minutes with just a few lines of code.

jen20 7y ago
> First you need to learn Packer, or Terraform, or Salt, or Ansible - how do you pick one? You don't. These are complementary tools. Packer builds images. Salt, Ansible, Puppet or Chef _could_ be used as part of this process, but so can shell scripts (and given the immutability of images in modern workflows, they are the best option). Terraform can be used to deploy images as virtual machines, along with the supporting resources in the target deployment environment.
- rumanator 7y ago
  > Salt, Ansible, Puppet or Chef _could_ be used as part of this process, but so can shell scripts I don't see the point of your post, and frankly sounds like nitpicking. Ansible is a tool designed to execute scripts remotely through ssh on a collection of servers, and makes the job of writing those scripts trivially easy by a) offering a DSL to write those scripts as a workflow of idempotent operations, and b) offer a myriad of predefined tasks that you can simply add to your scripts and reuse. Sure, you can write shell scripts to do the same thing. But that's a far lower level solution to a common problem, and one that is far hardsr and requires far more man*hours to implement and maintain. With Ansible you only need to write a list of servers, ensure you can ssh into them, and write a high-level description of your workflow as idempotent tasks. It takes you literally a couple of minutes to pull this off. How much time would you take to do the same with your shell scripts?

lazyier 7y ago

Kubernetes has complexity for a reason. It's trying to solve complex problems in a standardized and mature manner. If you don't need those problems solved then it's not going to benefit you a whole lot. Of course if you are using docker already and are following best practices with containers then converting to Kubernetes really isn't that hard. So if you do end up needing more problems solved then you are willing to tackle on your own then switching over is going to be on the table. The way I think about it is if you are struggling to deploy and manage the life cycle of your applications... fail overs, rolling updates, and you think you need some sort of session management like supervisord or something like to manage a cloud of processes and you find yourself trying to install and manage applications and services developed by third parties.... Then probably looking at Kubernetes is a good idea. Let K8s be your session manager, etc.

throwsprtsdy 7y ago
What is a "mature manner"?
- threeseed 7y ago
  For example by covering all of the NFRs. You don't always find open source programs that have dedicated so much effort to security, monitoring, governance etc. And doing so in a very professional and methodical way.
pavon 7y ago
I would qualify that a little more. If you are using docker and deploying to a cloud environment already, then moving to a cloud-managed kubernetes cluster really isn't that hard. I've seen too many full-time employees eaten up by underestimating what it takes to deploy and maintain a kubernetes cluster. Their time would have been far better spent on other things.
- yahyaheee 7y ago
  That story is getting a lot easier but historically was awful

moksly 7y ago

I think anyone considering these wild setups should read about how stackowerflow is hosted on a couple of IIS servers. It’s a sobering reminder that you often don’t need the new cool.

jiofih 7y ago
Nothing much happens if SO goes down, they are not doing a ton of business transactions.
- fishnchips 7y ago
  Nothing much? The world stops producing software:)
  - sgt 7y ago
    He's got a point though. Ironically the world's most highly scaled software are often fairly unimportant. Think Facebook - people would get annoyed if it went down for a day, but it'd soon be forgotten. Your banks are built with less scalable software but is much more critical.
- pnako 7y ago
  That's right. As opposed to stock exchange software, which runs on complex micro-services cloud k8s thing-as-a-thing virtualized rotozooming engines. Wait, no, it's literally just good-old n-tier architecture with one big server process and some database backend. Pet food delivery startups use k8s to manage their MEAN stack. Meanwhile grown-ups still have "monoliths" connected to something like Oracle, DB2 or MS SQL server, because that's obviously the most reliable setup. The cloud/k8s stuff is an ad-hoc wannabe mainframe built on shaky foundations.
  - rumanator 7y ago
    > Meanwhile grown-ups still have "monoliths" connected to something like Oracle, DB2 or MS SQL server, because that's obviously the most reliable setup. More often than not they just crystalized their 90s knowledge and just pretended there aren't better tools for the job because it would take some work to adopt them and no one notices it in their work anyway. The "Oracle" keyword is a telltale sign.

JMTQp8lwXL 7y ago

Who is giving you 100% uptime? All major providers (AWS, GCP, Azure, etc) all have had outages in the past 3 years. And that level of infrastructural failure doesn't care about whether or not you're using k8s.

tobib 7y ago
Not OP but you can achieve higher availability through means like redundancy, availability zones, multi-region deployments, etc.
threeseed 7y ago
EKS (AWS Kubernetes) has the control plane across 3 AZs. It is very rare to have a complete region outage so it is pretty close to 100% uptime.

fxtentacle 7y ago

The odd thing about having 10 years of experience as a consultant is that you know when to write "Kubernetes" into a project proposal, even though everyone agrees that it'll be a sub-optimal solution. But both you and their tech lead want to be able to write "used Kubernetes" on your CV in the future, plus future-oriented initiatives inside your contact's company tend to get more budget allocated to them. So it's a sound decision for everyone and for the health of the project to just go with whatever tech is fancy enough, but won't get into the way too badly. Enter Kubernetes, the fashionable Docker upgrade that you won't regret too badly ;)

bitL 7y ago

I worked on a transacted 20-60k messages/s system and am not sure K8S wouldn't be a hindrance there... Imagine writing Kafka using K8S and microservices.

echelon 7y ago

> Even for the highest scale app I've worked on (which was something like 20 requests per second, Kubernetes is not for you. 5kQPS times a hundred or more services and Kubernetes fits the bill. > And we had 100% uptime in 3 years. Not a single request failed in that time serving at 20 QPS? I'm a little suspicious. Regardless, if you were handling 10 or 100 times this volume to a single service, you'd want additional systems in place to assure hitless deploys.

rumanator 7y ago
> Not a single request failed in that time serving at 20 QPS? I'm a little suspicious. Things that aren't monitored are also things that don't fail.

closeparen 7y ago

Yes. Three web servers and a load balancer is fine. Three web servers and a load balancer, repeated 1,000 times across the enterprise in idiosyncratic ways and from scratch each time, is less fine. That’s where Kubernetes-shaped solutions (like Mesos that came before it) become appropriate. You can get a lot done with a sailboat. For certain kinds of problems you might genuinely need an aircraft carrier. But then you’d better have a navy. Don’t just wander onto the bridge and start pressing buttons.

mmazing 7y ago
You're right. However, a lot of new (or just bad) devs miss the whole Keep It Simple Stupid concept and think that they NEED Kubernetes-shaped solutions in order to "do it the right way". Many times three web servers and a load balancer are exactly what you need.
- threeseed 7y ago
  And then what about when you need to add monitoring, logging, APM, tracing, application metrics etc. Suddenly you have gone from 3 instances to 20.
  - bdibs 7y ago
    I personally went from 4 servers to 5, self hosting ELK and it works great.
  - mmazing 7y ago
    Adding an entirely new instance is not the only way to accomplish each of those things. A lot of those things can be treated just like applications. You don't need a whole new computer to run Outlook, another computer to run Sublime Text, another computer to run Chrome, etc etc. All of that is irrelevant to my main point though. It's never one size fits all and then all your problems are solved. You are far better off actually assessing your needs and picking the right solution instead of relying on solutions that "worked for bigger companies so they'll work for me" without really giving it a lot of thought if you need to go that far.

cmhnn 7y ago

I don't know about "lot more necessary". The images are one part of the equation especially to meet various regulations. There is a ton to running a large scale service especially if you are the service that the people who are posting how wicked smart they are at k8 service runs on. Google found that out yesterday when they said "oh hey people expect support maybe we should charge". That is not new for grown ups. The cloud existed before k8 and k8's creator has a far less mature cloud than AWS or Azure. But this thread has convinced me of one thing. It's time to re-cloak and never post again because even though the community is a cut above some others at the end of the day it's still a bunch of marks and if you know the inside it is hard to bite your lip.

Damogran6 7y ago

I'm in a similar boat, only my eyes are wide, glazed over, and I'm lost in the word salad...which only seems to be getting worse.

Ill_ban_myself 7y ago

The most important video I've ever watched for my career and sanity: https://www.youtube.com/watch?v=bzkRVzciAZg https://www.youtube.com/watch?v=bzkRVzciAZg