4 ms·

Maybe this is a mix of a couple of items in the list but when I read about the stacks in use nowadays I wonder if these would not fit the waste bucket. For exa

by cfn 5y ago

Maybe this is a mix of a couple of items in the list but when I read about the stacks in use nowadays I wonder if these would not fit the waste bucket. For example, there is a team I know of that is building a web application that serves maybe a couple of thousand people (if they ever acquire all of them as customers). They spent all this year building a humungous infrastructure with all the modern acronyms and have nothing to show the clients but a bunch of K8s this and Docker that.

qaq 5y ago
This is industry wide issue. Working on a much larger project old school version SRE team of 4 managed all the infra. "Cloud Native" version team of 7 DevOps 1.5 years building out CI/CD setup that is still somewhat iffy.
- wruza 5y ago
  I feel much less like an impostor when I read this. Thanks, HN! Is it even worth it adopting ci/cd for my small craft or am I fine sticking with push, ssh, pull, [vi config.json]? What do they actually achieve with it? Edit: incorrect idiom
  - yakshaving_jgt 5y ago
    You are fine with what you have. In general, fix your pains when you feel them. Not before.
  - marcosdumay 5y ago
    Do push, ssh, pull receive any parameter that may cause your program to misbehave if you get it wrong? If yes, then it's worth automating, if no, then no. Anyway, would you call putting the entire interaction in a shell script "ci/cd"?
    - alexchamberlain 5y ago
      If yes, then you have an acknowledged risk. That doesn't immediately say you should automate it - depends on the cost and _risk introduced_ by the automation.
  - kqr 5y ago
    Think of it in terms of principles. Why do we do continuous delivery in the most abstract sense? To get real value out of, and production feedback from, your code as quickly as possible. Both of these always help you write higher-quality code. The ideal is deploying every single commit. What could prevent you from this? Primarily two things: 1. You risk screwing the process up, causing expense in terms of damage to customers. 2. You don't like how much work it is to deploy every single commit; the transaction cost, even when everything goes right, is too high for your personal tastes. Continuous delivery automation tooling helps with these two issues. If they are not problems (in other words, you do things right every time and you don't mind doing it manually for every commit) then you don't have the problems tooling would solve, so no reason to use said tooling. Continuous integration is different from continuous delivery, and more about coding patterns than automation.
  - gilbetron 5y ago
    If you find yourself adding errors to your code that would have been caught with some basic testing that you usually do (or want to do) but forgot to do or were too lazy to do, then add some tests using whatever the typical framework is for the language you are on. Maybe do some simple github actions CI - it's pretty easy and a decent skill to have regardless. Having "unit" tests is a good habit to get into no matter what, really, but that doesn't mean you need a bit CI/CD pipeline. CD isn't really needed until the creation of your application is complex, or you have actual customers/users that depend on it.
- Cthulhu_ 5y ago
  I've experienced similar projects. Big microservices, multi-engineering team, full time SRE team etc... but it was basically a CRUD system, all the heavy lifting was done by an old mainframe black box system, hidden away by yet another old Java application. It was a lot of engineers flexing. And of course, the same engineers that started it had moved on to greener pastures well before the system went live and was tested by real life and real customers. I think I've finally grown enough of a pair to never tolerate something like that. Prove that you need microservices first. Prove that you - prove that the organization - can manage the overhead and complexity.
islon 5y ago
Meanwhile the two interns just finished the same web app using php, mysql and jquery because they didn't know any better.
heurisko 5y ago
There is an incentive for developers to build an over-engineered solution for a CV feels like it is now a principal-agent problem. There is then a feedback loop, as companies then have to require developers with CVs that have the technology.

by cfn 5y ago

qaq 5y ago

This is industry wide issue. Working on a much larger project old school version SRE team of 4 managed all the infra. "Cloud Native" version team of 7 DevOps 1.5 years building out CI/CD setup that is still somewhat iffy.

wruza 5y ago
I feel much less like an impostor when I read this. Thanks, HN! Is it even worth it adopting ci/cd for my small craft or am I fine sticking with push, ssh, pull, [vi config.json]? What do they actually achieve with it? Edit: incorrect idiom
- yakshaving_jgt 5y ago
  You are fine with what you have. In general, fix your pains when you feel them. Not before.
- marcosdumay 5y ago
  Do push, ssh, pull receive any parameter that may cause your program to misbehave if you get it wrong? If yes, then it's worth automating, if no, then no. Anyway, would you call putting the entire interaction in a shell script "ci/cd"?
  - alexchamberlain 5y ago
    If yes, then you have an acknowledged risk. That doesn't immediately say you should automate it - depends on the cost and _risk introduced_ by the automation.
- kqr 5y ago
  Think of it in terms of principles. Why do we do continuous delivery in the most abstract sense? To get real value out of, and production feedback from, your code as quickly as possible. Both of these always help you write higher-quality code. The ideal is deploying every single commit. What could prevent you from this? Primarily two things: 1. You risk screwing the process up, causing expense in terms of damage to customers. 2. You don't like how much work it is to deploy every single commit; the transaction cost, even when everything goes right, is too high for your personal tastes. Continuous delivery automation tooling helps with these two issues. If they are not problems (in other words, you do things right every time and you don't mind doing it manually for every commit) then you don't have the problems tooling would solve, so no reason to use said tooling. Continuous integration is different from continuous delivery, and more about coding patterns than automation.
- gilbetron 5y ago
  If you find yourself adding errors to your code that would have been caught with some basic testing that you usually do (or want to do) but forgot to do or were too lazy to do, then add some tests using whatever the typical framework is for the language you are on. Maybe do some simple github actions CI - it's pretty easy and a decent skill to have regardless. Having "unit" tests is a good habit to get into no matter what, really, but that doesn't mean you need a bit CI/CD pipeline. CD isn't really needed until the creation of your application is complex, or you have actual customers/users that depend on it.
Cthulhu_ 5y ago
I've experienced similar projects. Big microservices, multi-engineering team, full time SRE team etc... but it was basically a CRUD system, all the heavy lifting was done by an old mainframe black box system, hidden away by yet another old Java application. It was a lot of engineers flexing. And of course, the same engineers that started it had moved on to greener pastures well before the system went live and was tested by real life and real customers. I think I've finally grown enough of a pair to never tolerate something like that. Prove that you need microservices first. Prove that you - prove that the organization - can manage the overhead and complexity.

islon 5y ago

Meanwhile the two interns just finished the same web app using php, mysql and jquery because they didn't know any better.

heurisko 5y ago

There is an incentive for developers to build an over-engineered solution for a CV feels like it is now a principal-agent problem. There is then a feedback loop, as companies then have to require developers with CVs that have the technology.