4 ms·

I often find teams are legit spending more time configuring containers and the ecosystems around them. Far more than using classic servers and more than using s

I often find teams are legit spending more time configuring containers and the ecosystems around them. Far more than using classic servers and more than using server-less. Although the tech is great it seems to bloat quite a lot as of recently. Just an observation. As a consultant i love it tho - projects take far longer to complete.

sieabahlpark 6y ago
I think it's the case where traditional methods are faster because any issue already has a stack overflow answer. Whereas the new tech stacks are still in the discovery phase. Containers are useful and they do simplify application deployment in terms of dependency management. If you've never used the full k8-native stack it's easy to dismiss it. K8 recently with operators has made running distributed software as easy as configuring yaml. It's the same struggle you have with traditional stacks while you discover which config values and ansible scripts get you what you want.
- pepemon 6y ago
  Why are you defining Ansible as some script engine? "Bash on steroids" is definitely Ansible anti-pattern.
  - p_l 6y ago
    It's also the only model Ansible is reliable at. At least I always found it hilariously problematic to replicate check state -> fix approach from other options.
    - pepemon 6y ago
      > It's also the only model Ansible is reliable at. Please elaborate more on your statement. I have folks within my team whose paycheck consists of their ability to write fully idempotent roles and playbooks. Well, even I can do this without any pain, but my expertise has shifted into Kubernetes in past years.
      - pas 6y ago
        It's certainly possible. I used Chef for this. And spent a few years maintaining a pretty nice cookbook for a small startup. Then tried to use Ansible to setup and maintain an OpenStack cluster. Biggest hell no so far I found in "orchestration and config management". It was a big ball of yikes and anti-patterns, plus it was extremely slow, brittle and hard to debug. Is this Ansible's fault? No, of course not. But it's no wonder k8s seems the way forward. Having an active system that checks and maintains state and appropriate abstractions to describe apps, services, containers, volumes, network, etc. is easier than to write really idempotent playbooks.
        p_l 6y ago
        In a way it is ansible's fault, at least from my point of view. The reason is that the whole execution model of Ansible is essentially "a shell script in YAML form". Which makes it really, really easy to pick up for many system administrators. But it makes for (IMHO) harder time writing idempotent code, especially with some of the heavy ansible promoters being responsible for some of the worst code around (Red Hat).
jrockway 6y ago
A lot of organizations have legacy code floating around, and using something like a service mesh to get monitoring and tracing for that app is easier than rewriting the app to provide those features itself. I used to work on a legacy PHP app and the way it was structured pretty much precluded those things; there was no way to keep metrics in memory for Prometheus to scrape (without hacks anyway), and there was no way to get it to emit a UDP packet with tracing information after writing a body to the browser (the framework just kills the script at that point). I just put Envoy in front of it and suddenly we could see "what fraction of requests are timing out" or "what endpoints are returning 500 errors". The idea of Istio is that it just does that stuff automatically; it can use the k8s configuration that you already wrote to add things like observability hooks, smarter routing (avoid cascading failure modes without writing your own "suicide pact" controller), etc. I know everyone on HN has an app that they deploy by rsyncing some scripts to a server, and if they're on vacation they don't do releases, and if there's an error the script sends them an SMS saying "I'm broken", but that really stops scaling past a certain number of employees and traffic level, and some of these things that people write articles about are for those cases. Maintaining 10 servers is a lot closer to maintaining a million servers than it is to maintaining 1 server; people have written tools with that use case in mind. If you have one employee that maintains an app that runs on on server, you can probably ignore all of this stuff. If you are bigger than that, you might want to say "maybe this can help" rather than dismissing it as being too complicated. The complexity comes from "we're big enough to need 100 developers, and it would be nice if they could all deploy and monitor their own product", not from "let's find some unnecessary complexity". (If you look at how people are making money in the software industry right now, you'll see that having organizations run their own apps is apparently challenging. People will pay thousands a month for their cloud provider or a third party to run open source software for them on a server that costs them less than a hundred dollars a month. Things like Kubernetes are designed to make running that stuff on your own a possibility. Someday I'd like to do a little contest where I pay you $100 if you can run some sort of computer program for 6 months continuously. I doubt that many people on HN would be successful; they just never built any infrastructure for running computer programs. They have their one app running kind of okay, and that's the best they can do. It's actually scary that nobody sees this as a problem. )
- 6y ago
joekrill 6y ago
It's not like the underlying problems and learning curves didn't exist before this, though. You had to learn to use and configure Ansible/Terraform/Puppet/whatever to get your "classic" servers up and running. You have to deal with secrets and configuration management somehow. You have to manually deal with your dependencies and inter-dependencies, and any possible conflicts that came along with that. Logging, service discovery, metrics collection, etc. And for some folks it's better to continue using that "classic server" strategy and deal with those problems. Maybe they've already invested the time to learn to deal with those problems, or they already have systems and practices in place to deal with that stuff in an elegant way. But a lot of folks are seeing the enormous benefits of containers and the ecosystems that come with them. For them it's worth the trade-offs and the time to take to learn how this stuff works. Anyway, it's pretty clear at this point that this stuff isn't going away any time soon, and in fact only becoming more and more popular and useful. Clearly there's a reason for that.
- TomMarius 6y ago
  When I think of before, I remember how 13 year old me "deployed" a PHP scripted (gaming) website over FTP to be used by 10k concurrent users on a shared hosting server that I later found out to be run by a single 16 year old guy (that company is the country's largest hosting provider today). Everything worked flawlessly and was fast; the hosting guy wasn't a wizard as well.
  - kev009 6y ago
    VCs and developer marketing have created a cottage industry around maximizing operational complexity.
  - yencabulator 6y ago
    A lot of the complexity comes from wanting to avoid single points of failure and building for scalability. Your shared hosting server was an orange, modern cloud is apples. Sometimes you want an orange.
    - 6y ago

sieabahlpark 6y ago

I think it's the case where traditional methods are faster because any issue already has a stack overflow answer. Whereas the new tech stacks are still in the discovery phase. Containers are useful and they do simplify application deployment in terms of dependency management. If you've never used the full k8-native stack it's easy to dismiss it. K8 recently with operators has made running distributed software as easy as configuring yaml. It's the same struggle you have with traditional stacks while you discover which config values and ansible scripts get you what you want.

pepemon 6y ago
Why are you defining Ansible as some script engine? "Bash on steroids" is definitely Ansible anti-pattern.
- p_l 6y ago
  It's also the only model Ansible is reliable at. At least I always found it hilariously problematic to replicate check state -> fix approach from other options.
  - pepemon 6y ago
    > It's also the only model Ansible is reliable at. Please elaborate more on your statement. I have folks within my team whose paycheck consists of their ability to write fully idempotent roles and playbooks. Well, even I can do this without any pain, but my expertise has shifted into Kubernetes in past years.
    - pas 6y ago
      It's certainly possible. I used Chef for this. And spent a few years maintaining a pretty nice cookbook for a small startup. Then tried to use Ansible to setup and maintain an OpenStack cluster. Biggest hell no so far I found in "orchestration and config management". It was a big ball of yikes and anti-patterns, plus it was extremely slow, brittle and hard to debug. Is this Ansible's fault? No, of course not. But it's no wonder k8s seems the way forward. Having an active system that checks and maintains state and appropriate abstractions to describe apps, services, containers, volumes, network, etc. is easier than to write really idempotent playbooks.
      - p_l 6y ago
        In a way it is ansible's fault, at least from my point of view. The reason is that the whole execution model of Ansible is essentially "a shell script in YAML form". Which makes it really, really easy to pick up for many system administrators. But it makes for (IMHO) harder time writing idempotent code, especially with some of the heavy ansible promoters being responsible for some of the worst code around (Red Hat).

jrockway 6y ago

A lot of organizations have legacy code floating around, and using something like a service mesh to get monitoring and tracing for that app is easier than rewriting the app to provide those features itself. I used to work on a legacy PHP app and the way it was structured pretty much precluded those things; there was no way to keep metrics in memory for Prometheus to scrape (without hacks anyway), and there was no way to get it to emit a UDP packet with tracing information after writing a body to the browser (the framework just kills the script at that point). I just put Envoy in front of it and suddenly we could see "what fraction of requests are timing out" or "what endpoints are returning 500 errors". The idea of Istio is that it just does that stuff automatically; it can use the k8s configuration that you already wrote to add things like observability hooks, smarter routing (avoid cascading failure modes without writing your own "suicide pact" controller), etc. I know everyone on HN has an app that they deploy by rsyncing some scripts to a server, and if they're on vacation they don't do releases, and if there's an error the script sends them an SMS saying "I'm broken", but that really stops scaling past a certain number of employees and traffic level, and some of these things that people write articles about are for those cases. Maintaining 10 servers is a lot closer to maintaining a million servers than it is to maintaining 1 server; people have written tools with that use case in mind. If you have one employee that maintains an app that runs on on server, you can probably ignore all of this stuff. If you are bigger than that, you might want to say "maybe this can help" rather than dismissing it as being too complicated. The complexity comes from "we're big enough to need 100 developers, and it would be nice if they could all deploy and monitor their own product", not from "let's find some unnecessary complexity". (If you look at how people are making money in the software industry right now, you'll see that having organizations run their own apps is apparently challenging. People will pay thousands a month for their cloud provider or a third party to run open source software for them on a server that costs them less than a hundred dollars a month. Things like Kubernetes are designed to make running that stuff on your own a possibility. Someday I'd like to do a little contest where I pay you $100 if you can run some sort of computer program for 6 months continuously. I doubt that many people on HN would be successful; they just never built any infrastructure for running computer programs. They have their one app running kind of okay, and that's the best they can do. It's actually scary that nobody sees this as a problem. )

6y ago

joekrill 6y ago

It's not like the underlying problems and learning curves didn't exist before this, though. You had to learn to use and configure Ansible/Terraform/Puppet/whatever to get your "classic" servers up and running. You have to deal with secrets and configuration management somehow. You have to manually deal with your dependencies and inter-dependencies, and any possible conflicts that came along with that. Logging, service discovery, metrics collection, etc. And for some folks it's better to continue using that "classic server" strategy and deal with those problems. Maybe they've already invested the time to learn to deal with those problems, or they already have systems and practices in place to deal with that stuff in an elegant way. But a lot of folks are seeing the enormous benefits of containers and the ecosystems that come with them. For them it's worth the trade-offs and the time to take to learn how this stuff works. Anyway, it's pretty clear at this point that this stuff isn't going away any time soon, and in fact only becoming more and more popular and useful. Clearly there's a reason for that.

TomMarius 6y ago
When I think of before, I remember how 13 year old me "deployed" a PHP scripted (gaming) website over FTP to be used by 10k concurrent users on a shared hosting server that I later found out to be run by a single 16 year old guy (that company is the country's largest hosting provider today). Everything worked flawlessly and was fast; the hosting guy wasn't a wizard as well.
- kev009 6y ago
  VCs and developer marketing have created a cottage industry around maximizing operational complexity.
- yencabulator 6y ago
  A lot of the complexity comes from wanting to avoid single points of failure and building for scalability. Your shared hosting server was an orange, modern cloud is apples. Sometimes you want an orange.
  - 6y ago