8 ms·

DevOps is dead? Well I guess that means I can finally delete my fat repo of Ansible, Terraform, and Packer configs. Using AWS, GCE and others doesn't get rid of

DevOps is dead? Well I guess that means I can finally delete my fat repo of Ansible, Terraform, and Packer configs. Using AWS, GCE and others doesn't get rid of DevOps. You're just managing computers in someone else's data center instead of your own.

lisivka 11y ago
You definitely need to delete your Ansible, Terrafor, and Packer. Typical Linux distro is a lot larger than your project, but it works fine without that, at hundreds of platforms. Did you learn how to achieve such level of flexibility?
- rubiquity 11y ago
  I don't understand the correlation you're trying to make. Linux is very sophisticated but it doesn't provision itself.
  - lisivka 11y ago
    Linux distro is much more complex than application, but it installation is simple, because distro is split into lot of independent packages, which are wired using package manager. Lot of naїve developers are trying to solve same problem using imperative tools or develop their own package manager instead of learning of existing, well proven solution.
    - rubiquity 11y ago
      Oh you mean running your own apt/yum mirror? I've done that in the past. There's still configuration involved. You have to configure the packages that your machines then pull. You also have to configure the mirror itself.
      - lisivka 11y ago
        For dependencies, use metapackages. For repository configuration, use "release" package with description of repository. Release package can be installed directly from http. In my cases, I define few variables, then I will install repository definition and main package: export NODE=2 dnf install -y http://..../staging-release.noarch.rpm dnf install -y node-backend (and few other steps in some cases, e.g. putting of host names into /etc/hosts, or formatting and partioning of hard-drives). It works fine on bare metal, vagrant, docker, aws, etc.
        brown9-2 11y ago
        And how do you tell 100s of hosts to install that `node-backend` package?
        lisivka 11y ago
        It is called provisioning. How you created 100s of hosts in first place? Use same tool.
    - aeorgnoieang 11y ago
      I'm pretty sure lots of developers are also using package managers, and sometimes private servers for those same package managers, but configuration management is still a separate thing that needs to be done and using tools to do it is very much a good idea.
      - lisivka 11y ago
        I use same tools (package manager, services, scripts) for about decade. Tried to use Puppet and Ansible, but result is much more complex and it feels like I reinventing the wheel, because I need to implement things which I already have implemented in package manager, like validation, upgrade management, etc. Difference between Ansible and package manager feels like difference between procedural programming and OOP. Difference between Puppet and package manager feels like fight between two competing object oriented models.
        aeorgnoieang 11y ago
        Far be it from me to tell you where or how something should be implemented. If you're happy using packages then that's great! But the other two tools you mentioned using – "services, scripts" – are exactly what a lot of people find to be harder to manage than a configuration management tool. Maybe your "services" and "scripts" are really sophisticated. If true, then perhaps you've implemented your own configuration management tool. If so, maybe you could share it and other people would find it useful too.
        lisivka 11y ago
        You are asking wrong questions. The reason, why I don't use configuration tools is because I do no configuration in production. One of main rules for me is to perform all installation and configuration steps in controlled development environment, then test them in staging and only then deploy verified result to production. Imagine that you are fully installed and configured everything at your new production host but in your development environment, then it powered off, deployed to production environment and powered on again and it works. It is result I want to achieve: deploy only ready to use software to production, in sealed form, so no installation, no tweaking, no anything. Like smartphone on contract. It can be achieved with docker, but docker is relatively new invention and my solution plays well with docker too. So, no, my scripts and services are not a configuration management tool.
    - sergiosgc 11y ago
      I think you are mixing the concerns of configuration managers and package managers. They are at different abstraction points. Step one: install software and its dependencies (package manager). Step two: Have all the software services in your cluster talk to each other (configuration manager). Step three is profit.
      - lisivka 11y ago
        No, I am not mixing them. I just skipping step two, because it can be done automagically after step one.
        sergiosgc 11y ago
        It can. Is it efficient? No. This is so obvious that I'll have to attribute your opinion to lack of experience. Try deploying a stack with a dozen different services, designed with fault tolerance and horizontal scalability in mind, where each service is clustered, without a configuration manager. Then, review your opinion.
        lisivka 11y ago
        I have 25 years of experience. 19 years with Linux alone. Yes, I deployed stacks with dozen of different services. Typical distro has hundreds of services.
- lisivka 11y ago
  To anonymous coward, who downvoted me: if your large and "complex" application will be integrated into distro, so you will be able to apt/yum/dnf install it, will you still need your custom installation scripts?
  - jtreminio 11y ago
    `apt-get install nginx` only installs the package and some default configurations. You still need to manage the actual config files yourself. What will you use? Bash? Python? Perl? Why not something like Puppet that keeps track of changes it needs to apply and has many useful features on top of it? What happens if you write your installation scripts to use Ubuntu, but the order comes from high up to move to CentOS/RHEL? Did you write your scripts to be distro-agnostic? Because Puppet's `package` is.
    - lisivka 11y ago
      Actual configuration can be installed using `apt-get install ngingx-site-config-prod`.
      - sergiosgc 11y ago
        Now, try adapting that approach to do Blue/Green deployments [1]. Imagine how that is done using configuration managers. Can you see the advantage now? [1] http://martinfowler.com/bliki/BlueGreenDeployment.html http://martinfowler.com/bliki/BlueGreenDeployment.html
        lisivka 11y ago
        I use it. Blue/Green deployments is one of main reasons to use package managers, because with package manager I can prove that two deployments are identical, including configuration files, which are also deployed using package manager. It was primary reason why we switched from configuration scripts to packages for provisioning and configuration.
        11y ago
jtreminio 11y ago
I agree. I recently created a private cloud infrastructure on Digital Ocean. It would have been easier and faster (and more polished) if I'd gone with AWS, but then I would know how to use AWS, and would not know how to do these things myself. Why learn about HAProxy, keepalived, tinc, etc when you've got AWS to handle it all for you? Answer: Because relying on a service to abstract the inner workings for you is a path to the dark side.
- deleted 11y ago
  [deleted]
- toomuchtodo 11y ago
  Not sure why you're being downvoted. Abstraction is for ease of use, not ignorance as to what's occurring under the hood.
  - rubiquity 11y ago
    > Abstraction is for ease of use, not ignorance as to what's occurring under the hood. I'm stealing this. I love it!
  - davidrusu 11y ago
    No. Abstraction is for higher level thinking. Dev Ops is still young so we are seeing many attempts at providing these abstractions but it is a very large domain to abstract over and thus hard to make a non leaky abstraction. Given a non leaky abstraction, ignorance of whats under the hood is just fine.
    - deleted 11y ago
      [deleted]
    - jtreminio 11y ago
      What I was trying to say was more along the lines of a 3rd-party service abstracting the work is not a good idea in the long-term. It is unthinkable right now, but what will happen with Amazon/AWS goes bankrupt and no longer exists? All these AWS Certified Engineers who are not actually devops will suddenly be lost. On the flipside, if you learn everything from the ground up and then jump on AWS or whatever service is available, you will be in a much better position when the day comes to move away and to something else. Abstractions in something like programming languages is fine because the language won't simply disappear one day - you'll evolve as a programmer and will be stronger for it.
jasode 11y ago
>DevOps is dead? Fyi, the title is using the rhetoric template of: <SOMETHING> is dead. Long live <SOMETHING>. [1] ...where <SOMETHING> is deliberately the same word in both sentences. The construct is a shortened version of: <SOMETHING> in its previous and more well-known form has evolved to <SOMETHING> with a new variation. That <SOMETHING> is still there the whole time -- which is sort of meta-joke connecting the 2 sentences. It's as if someone wrote "Cars are dead. Long live cars." to signal the change from humans manually driving the cars to AI robots doing it. If you read the "cars" literally, it looks nonsensical because there are obviously cars existing both before and after the shift to automation. [1] examples: http://www.pcoitmurphy.com/_books_are_dead__long_live_books__55201.htm http://www.pcoitmurphy.com/_books_are_dead__long_live_books_... https://www.tnooz.com/article/hotels-Airbnb-rented/ https://www.tnooz.com/article/hotels-Airbnb-rented/ http://www.wired.com/insights/2014/08/moocs-are-dead-long-live-the-mooc/ http://www.wired.com/insights/2014/08/moocs-are-dead-long-li...
- oblio 11y ago
  https://en.m.wikipedia.org/wiki/The_king_is_dead,_long_live_the_king https://en.m.wikipedia.org/wiki/The_king_is_dead,_long_live_...!
- mryan 11y ago
  To add to this informative post: The original form of the phrase is "the king is dead, long live the king". It was used when the king died in the sense of "the [old] king is dead, long live the [new] king". So in that light it means "[the old way of] devops is dead, long live [the new way of] devops".
- rubiquity 11y ago
  I would still disagree with that because DevOps really hasn't changed at all. It's not like AWS popped up yesterday. It's been around for a decade.
mc32 11y ago
The article is muddled. It's like some came up with a title and then tried to support their conclusion with rambling thoughts without much cohesion. Deadlines, I guess.

lisivka 11y ago

You definitely need to delete your Ansible, Terrafor, and Packer. Typical Linux distro is a lot larger than your project, but it works fine without that, at hundreds of platforms. Did you learn how to achieve such level of flexibility?

rubiquity 11y ago
I don't understand the correlation you're trying to make. Linux is very sophisticated but it doesn't provision itself.
- lisivka 11y ago
  Linux distro is much more complex than application, but it installation is simple, because distro is split into lot of independent packages, which are wired using package manager. Lot of naїve developers are trying to solve same problem using imperative tools or develop their own package manager instead of learning of existing, well proven solution.
  - rubiquity 11y ago
    Oh you mean running your own apt/yum mirror? I've done that in the past. There's still configuration involved. You have to configure the packages that your machines then pull. You also have to configure the mirror itself.
    - lisivka 11y ago
      For dependencies, use metapackages. For repository configuration, use "release" package with description of repository. Release package can be installed directly from http. In my cases, I define few variables, then I will install repository definition and main package: export NODE=2 dnf install -y http://..../staging-release.noarch.rpm dnf install -y node-backend (and few other steps in some cases, e.g. putting of host names into /etc/hosts, or formatting and partioning of hard-drives). It works fine on bare metal, vagrant, docker, aws, etc.
      - brown9-2 11y ago
        And how do you tell 100s of hosts to install that `node-backend` package?
        lisivka 11y ago
        It is called provisioning. How you created 100s of hosts in first place? Use same tool.
  - aeorgnoieang 11y ago
    I'm pretty sure lots of developers are also using package managers, and sometimes private servers for those same package managers, but configuration management is still a separate thing that needs to be done and using tools to do it is very much a good idea.
    - lisivka 11y ago
      I use same tools (package manager, services, scripts) for about decade. Tried to use Puppet and Ansible, but result is much more complex and it feels like I reinventing the wheel, because I need to implement things which I already have implemented in package manager, like validation, upgrade management, etc. Difference between Ansible and package manager feels like difference between procedural programming and OOP. Difference between Puppet and package manager feels like fight between two competing object oriented models.
      - aeorgnoieang 11y ago
        Far be it from me to tell you where or how something should be implemented. If you're happy using packages then that's great! But the other two tools you mentioned using – "services, scripts" – are exactly what a lot of people find to be harder to manage than a configuration management tool. Maybe your "services" and "scripts" are really sophisticated. If true, then perhaps you've implemented your own configuration management tool. If so, maybe you could share it and other people would find it useful too.
        lisivka 11y ago
        You are asking wrong questions. The reason, why I don't use configuration tools is because I do no configuration in production. One of main rules for me is to perform all installation and configuration steps in controlled development environment, then test them in staging and only then deploy verified result to production. Imagine that you are fully installed and configured everything at your new production host but in your development environment, then it powered off, deployed to production environment and powered on again and it works. It is result I want to achieve: deploy only ready to use software to production, in sealed form, so no installation, no tweaking, no anything. Like smartphone on contract. It can be achieved with docker, but docker is relatively new invention and my solution plays well with docker too. So, no, my scripts and services are not a configuration management tool.
  - sergiosgc 11y ago
    I think you are mixing the concerns of configuration managers and package managers. They are at different abstraction points. Step one: install software and its dependencies (package manager). Step two: Have all the software services in your cluster talk to each other (configuration manager). Step three is profit.
    - lisivka 11y ago
      No, I am not mixing them. I just skipping step two, because it can be done automagically after step one.
      - sergiosgc 11y ago
        It can. Is it efficient? No. This is so obvious that I'll have to attribute your opinion to lack of experience. Try deploying a stack with a dozen different services, designed with fault tolerance and horizontal scalability in mind, where each service is clustered, without a configuration manager. Then, review your opinion.
        lisivka 11y ago
        I have 25 years of experience. 19 years with Linux alone. Yes, I deployed stacks with dozen of different services. Typical distro has hundreds of services.
lisivka 11y ago
To anonymous coward, who downvoted me: if your large and "complex" application will be integrated into distro, so you will be able to apt/yum/dnf install it, will you still need your custom installation scripts?
- jtreminio 11y ago
  `apt-get install nginx` only installs the package and some default configurations. You still need to manage the actual config files yourself. What will you use? Bash? Python? Perl? Why not something like Puppet that keeps track of changes it needs to apply and has many useful features on top of it? What happens if you write your installation scripts to use Ubuntu, but the order comes from high up to move to CentOS/RHEL? Did you write your scripts to be distro-agnostic? Because Puppet's `package` is.
  - lisivka 11y ago
    Actual configuration can be installed using `apt-get install ngingx-site-config-prod`.
    - sergiosgc 11y ago
      Now, try adapting that approach to do Blue/Green deployments [1]. Imagine how that is done using configuration managers. Can you see the advantage now? [1] http://martinfowler.com/bliki/BlueGreenDeployment.html http://martinfowler.com/bliki/BlueGreenDeployment.html
      - lisivka 11y ago
        I use it. Blue/Green deployments is one of main reasons to use package managers, because with package manager I can prove that two deployments are identical, including configuration files, which are also deployed using package manager. It was primary reason why we switched from configuration scripts to packages for provisioning and configuration.
        11y ago

jtreminio 11y ago

I agree. I recently created a private cloud infrastructure on Digital Ocean. It would have been easier and faster (and more polished) if I'd gone with AWS, but then I would know how to use AWS, and would not know how to do these things myself. Why learn about HAProxy, keepalived, tinc, etc when you've got AWS to handle it all for you? Answer: Because relying on a service to abstract the inner workings for you is a path to the dark side.

deleted 11y ago
[deleted]
toomuchtodo 11y ago
Not sure why you're being downvoted. Abstraction is for ease of use, not ignorance as to what's occurring under the hood.
- rubiquity 11y ago
  > Abstraction is for ease of use, not ignorance as to what's occurring under the hood. I'm stealing this. I love it!
- davidrusu 11y ago
  No. Abstraction is for higher level thinking. Dev Ops is still young so we are seeing many attempts at providing these abstractions but it is a very large domain to abstract over and thus hard to make a non leaky abstraction. Given a non leaky abstraction, ignorance of whats under the hood is just fine.
  - deleted 11y ago
    [deleted]
  - jtreminio 11y ago
    What I was trying to say was more along the lines of a 3rd-party service abstracting the work is not a good idea in the long-term. It is unthinkable right now, but what will happen with Amazon/AWS goes bankrupt and no longer exists? All these AWS Certified Engineers who are not actually devops will suddenly be lost. On the flipside, if you learn everything from the ground up and then jump on AWS or whatever service is available, you will be in a much better position when the day comes to move away and to something else. Abstractions in something like programming languages is fine because the language won't simply disappear one day - you'll evolve as a programmer and will be stronger for it.

jasode 11y ago

>DevOps is dead? Fyi, the title is using the rhetoric template of: <SOMETHING> is dead. Long live <SOMETHING>. [1] ...where <SOMETHING> is deliberately the same word in both sentences. The construct is a shortened version of: <SOMETHING> in its previous and more well-known form has evolved to <SOMETHING> with a new variation. That <SOMETHING> is still there the whole time -- which is sort of meta-joke connecting the 2 sentences. It's as if someone wrote "Cars are dead. Long live cars." to signal the change from humans manually driving the cars to AI robots doing it. If you read the "cars" literally, it looks nonsensical because there are obviously cars existing both before and after the shift to automation. [1] examples: http://www.pcoitmurphy.com/_books_are_dead__long_live_books__55201.htm http://www.pcoitmurphy.com/_books_are_dead__long_live_books_... https://www.tnooz.com/article/hotels-Airbnb-rented/ https://www.tnooz.com/article/hotels-Airbnb-rented/ http://www.wired.com/insights/2014/08/moocs-are-dead-long-live-the-mooc/ http://www.wired.com/insights/2014/08/moocs-are-dead-long-li...

oblio 11y ago
https://en.m.wikipedia.org/wiki/The_king_is_dead,_long_live_the_king https://en.m.wikipedia.org/wiki/The_king_is_dead,_long_live_...!
mryan 11y ago
To add to this informative post: The original form of the phrase is "the king is dead, long live the king". It was used when the king died in the sense of "the [old] king is dead, long live the [new] king". So in that light it means "[the old way of] devops is dead, long live [the new way of] devops".
rubiquity 11y ago
I would still disagree with that because DevOps really hasn't changed at all. It's not like AWS popped up yesterday. It's been around for a decade.

mc32 11y ago

The article is muddled. It's like some came up with a title and then tried to support their conclusion with rambling thoughts without much cohesion. Deadlines, I guess.