31 ms·

2005: your infrastructure is automated using a handful of Bash, Perl and Python scripts written by two system administrators. They are custom, sometimes brittle

2005: your infrastructure is automated using a handful of Bash, Perl and Python scripts written by two system administrators. They are custom, sometimes brittle and get rewritten every 5 years. 2022: your infrastructure is automated using 10 extremely complex devops tools. You automated the two system administrators away - but then had to hire 5 DevOps engineers paid 2x more. The total complexity is 10x. They wrote YAML, TOML, plus Ansible, Pulumi, Terraform scripts. They are custom, sometimes brittle and get rewritten every 3 years. EDIT: to the people claiming that today's infra does more things... No, I'm comparing stuff with the same levels of availability, same deployment times, same security updates.

mountainriver 4y ago
True but to be fair modern infra does a hell of a lot more
lox 4y ago
In 2005 your infrastructure provisioning wasn’t automated. The complexity has increased, but so has what we get. Being able to provision new hardware stacks like software is amazing, in 2005 I had to get quotes from hosting providers.
- iso1631 4y ago
  Whereas now nobody cares about the cost because it's all hidden away in a massive bill at the end of the month?
_vertigo 4y ago
Not pictured: 2005 your average box served some php and static assets, connecting to some generic relational database. Reading logs means grepping files over ssh. 2022 your architecture runs in the cloud, has multiple flavors of databases, queues, caches, and so on. You have at least two orders of magnitude more complexity because you aren’t just serving a web page anymore - you handle payments, integrate with other services, queue tasks for later, and so on. Your automation may be an order of magnitude more complex than 2005, but it enables two orders of magnitude more functionality.
- stathibus 4y ago
  My classic C programmer curmudgeon take is that the root of the problem, as with everything else in this industry, is bad software built on top of bad software built on top of bad software... and on it goes. The systems in your 2022 world are hard to test and maintain because they are bad, and the tools we built to test and maintain them are largely built on the same foundational ideas and technologies, so they are even worse. We're going to have to rip everything back down to the foundation in order to make progress beyond finger-pointing (X is DevOps but Y is software engineering and Z is IT admin).
  - theflyinghorse 4y ago
    What software is bad precisely? The modern browsers? The tools we use to build modern browser apps? Perhaps your gripe is with something else entirely, like modern databases? Or is it the OS that you don't like? Really not sure what you're commenting about here
    - Godel_unicode 4y ago
      They said that the world is bad software on top of bad software, so it’s not one thing. It’s everything being bad and working around everything else being bad.
      - voidfunc 4y ago
        Yea but they didn’t explain why its bad. Software devs complaining about “bad software” is basically an industry trope at this point but often it just means “Its too complex and I don’t understand why that complexity is probably necessary” or “Its not written the way I would have written it”.
      - arinlen 4y ago
        > They said that the world is bad software on top of bad software, so it’s not one thing. I don't know about OP, but I personally feel like software like GCC/clang/MSVC and Debian/Ubuntu and Docker and SSH and Git are pretty great, and were never better. Heck, the whole dotnet ecosystem is turning some significant problems in developer experience into at most minor nuisances. Even Firefox+Chrome are stellar, and extremely solid as-is. Where exactly is this bad software OP is talking about?
winternett 4y ago
It's usually always a solution with an overly complex chain of tools that only do a small part of deployment/security tasks because it's a food chain, where each vendor can eat a part of the company's budget consistently, based on a problem that really isn't consistently solved... Apps are still no more secure because there are several points where they can be compromised, rather than just a few involved in a less automated, but more easily replicate-able process. Also, I don't need "flavor of the month" skills to get things done. There is always a revolving door of fly-by-night-hype tools and brands that regularly rise and fall in the IT world... I avoid them (new hyped products) like the plague. I'm fine with being the stubborn middle aged IT guy now. :P It's all a food chain based on making money. What matters to me most is whether money is being made from the product that is deployed, and if it's simple, reliable, and secure enough to be worth development. I don't do my job to make a bunch of companies money by using their DevOps tools. Screw impressing other engineers with solution complexity every time. Functional reliability always wins at the end of the day. Leveraging a massive list of Ops tools only creates a huge backlog of update work, designing efficiency and simplicity in most of my solutions is what ultimately pleases most of my clients.
paddlepop 4y ago
This is a build deployment perspective. I for one do not miss hosts never being patched because all those slight modifications to systems files that were tweaked several builds ago and now everyone is too scare to touch. I won't miss the 12 month projects to upgrade some dated software to a slightly less dated version of that same software. From my perspective in Security, DevOps has made life much better.
- tech_tuna 4y ago
  At my first company, our builds happened whenever the release engineer (he was friends with the milk man and chimney sweep) felt like "doing a build". As another example, CI/CD adds a lot more work and maintenance but it results in better overall hygiene.
- fragmede 4y ago
  The ability to spin up a box, have it run insecure code, and then spin it down; and the ability to do that all day long, is worth it for the security benefits that all this complexity entails.
  - HWR_14 4y ago
    > The ability to spin up a box, have it run insecure code, and then spin it down; and the ability to do that all day long What's the best way to do that? I have some insecure code that needs to run about 6x a day, and so far my best thought has been an isolated box outside my network that does the internet based fetches, translates the data and then submits them over the web to another service that verifies/checks the output.
inopinatus 4y ago
All you’ve demonstrated is that some folks are bad at SRE.
CommanderData 4y ago
IaC wasn't even prevelant or a production ready thing back in 2005. I'm unsure what magical bash scripting would do any of that, maybe it the data centres too!
- aghahsdsdfh 4y ago
  IaC wasn't a thing because you honestly didn't need code to solve the vast majority of deployment problems. It was a configuration issue. Not 2005, but a year later in 2006 I was using cfengine to deploy code and configuration to servers from an svn repository. The same svn repository had dhcpd configs that described pretty much every device on the network. The dhcp configs also pointed to a tftp service from which new nodes pxe booted to an installer which pulled down the node specific kickstart, and provisioned the machine. We didn't call it infrastructure as code, but it sure fucking smells the same.
bryanrasmussen 4y ago
>to the people claiming that today's infra does more things... No, I'm comparing stuff with the same levels of availability, same deployment times, same security updates. ok but in my experience it seems like more things are being done in places I see with devops nowadays versus back then. I mean I know you say that it's the same, but it's hard to believe your statement in a comment versus my lying eyes. It seems more likely to me that your two examples are both actually fictitious and thus it is easy for you to say that they are exactly the same in what gets output - or have you been at the same place for 17 years, seen the changes, yet have had no input on the company to stop the madness? Because if the latter that would also seem... weird.
- thr0wawayf00 4y ago
  Were microservices a thing back in 2005? Honest question, I always assumed that SOA was more of a newer philosophy in web software. The scale of what we build has changed a lot over the years, as well as the need to handle the variance of scale through techniques like auto-scaling. All of that adds an incredible amount of complexity in systems that surely didn't exist 18 years ago.
  - bryanrasmussen 4y ago
    I don't think SOA was in common discussion in 2005, I think more about 2007 would sound right, Rest was pretty much the winner by 2009. But perhaps my memories here are warped by my personal career and not having to have the arguments after 2009. No I don't think microservices was anywhere at that time, although one could argue that they are a repackaging of the ideas of Small Pieces, Loosely Joined https://en.wikipedia.org/wiki/Small_Pieces_Loosely_Joined https://en.wikipedia.org/wiki/Small_Pieces_Loosely_Joined or an architectural expression of loose coupling https://en.wikipedia.org/wiki/Loose_coupling https://en.wikipedia.org/wiki/Loose_coupling for corporate data.
mediascreen 4y ago
I run 50+ smallish applications on AWS using Bitbucket Pipelines, Fargate, Aurora MySQL, S3, Cloudfront and a few other services. Most of the setup is scripted using very simple Cloudformation scripts. I estimate that I spend maybe 10% of my time on this and the rest of my time on ordinary dev/architecture tasks. Before Docker and AWS this would have taken me so much more time. The only drawback is that we have a hard time finding other developers in the company that want and have the time to learn the setup. It's not very complicated, but require some familiarity with the AWS ecosystem. It can seem daunting to someone who has to learn it from scratch.
- russellendicott 4y ago
  > The only drawback is that we have a hard time finding other developers in the company that want and have the time to learn the setup This is my experience as well in enterprise cloud. I don't get it. Have these people seen what cloud jobs pay for less work?
shrubble 4y ago
1997: a team of 5 sys admins, 3 of them functional alcoholics, writing only in Bash scripts, manage over 2000 internet facing SPARC machines. A lot of DevOps is actually CVOps - stuff that people get familiar with so they can put it in their resume.
- iso1631 4y ago
  What was wrong with the other 2?
  - nineteen999 4y ago
    Dysfunctional alcoholics.
- iso1631 4y ago
  Those bash scripts probably still in place and working, meanwhile modern ways of managing the servers have been recreated a dozen times over the last 25 years as every time a new person comes in there's always a better way of doing things. The difference is now you're a failure if you stay at the same job for more than 2 or 3 years.
  - deleted 4y ago
    [deleted]
- barking_biscuit 4y ago
  CVOps - hahahaha. I've always heard and used the term "Resume Driven Development" but I guess CVOps is a nice term too.
lazyant 4y ago
2005: no cloud, had to order 1Us, wait, rack up. Needed a DBA for the database, a network sysadmin for the networking, all to serve a simple website with not the same level of HA. We are doing way more now, which needs some more complexity and yes, in many cases we are overengineering it.
- iso1631 4y ago
  2005 Linode sold me VMs, no need for a DBA or network admin for a simple main/reserve website 17 years later and getting more than 364 days uptime out of AWS is apparently "not worth the cost"
EdwardDiego 4y ago
So someone overengineered something in 2022, and therefore, nothing's better? How about my anecdata: 2010: your infrastructure is automated using a handful of Bash, Perl and Python scripts written by two system administrators. They are custom, brittle in the face of scaling needs, and get rewritten continuously as your market share and resulting traffic grows. Outages happen far too often, you think, but you would, because you're someone who gets paged for this shit, because you know a core system well... ...that got broken by a Perl script you didn't wrote. 2019: your infrastructure runs on EKS, applications are continuously deployed as soon as they're ready using Jenkins and Flux. You wrote some YAML, but it's far better than that Perl stuff you used to have to do. The IDE support is like night vs day. You have two sysops, or devops, or whatever, who watch over the infra. You've had to attend to a system outage once in the past two years, because an AWS datacentre overheated, and the sysops just wanted to be sure. You write some YAML, the sysops write some CDK. Your system is far more dynamically scalable, auditable, and reliable. My anecdote can totally beat up your anecdote.(In other words, this is a silly line of argument)
icod1 4y ago
My 2020 looks like this: no docker no k8s 1 server git repo /var/www/domain_name git clone git_url /var/www/domain_name/backend/ cd /var/www/domain_name/backend/ go build Updates git pull go build systemctl restart domain_name.backend.service I pay 46€/month and I'm looking forward to halve those costs. Server load is mostly <0.5 I call this the incubation server. If a project takes off I rent a more expensive, but dedicated, server. It's very unlikely that I ever need more than 1 single server per project. I will never write microservices, I can scale fine with a monolith. Lately I even moved away from JS frontends to render everything with Go on the server. Yeah it requires more resources but I'll gladly offer those resources for lower response times and a consistent experience. Sadly companies that are hiring don't see it that way. That's ok. I'll just stay unemployed and try building my own stuff until something succeeds again. I had a 7 year long project that brought in 5-7k€/m. The server costed 60€/m. I can do that again. I know it's not your kind of scale or income level, but it allowed me to have a good life living it my way.
- mmcnl 4y ago
  No one ever said a VPS with a shell script is terrible. You think of scale the wrong way. Scaling is not only about increasing from 10 requests / second to 1000 requests / second. Scaling is about organizational scale too, i.e. how do you ensure going from 2 to 20 developers increases productivity by at least 20x and not 1.5x? Tools like Docker, Kubernetes and whatever absolutely help in that regard.
- barking_biscuit 4y ago
  I think it's somewhat disingenuous to compare DevOps requirements of 5-7k/m projects with systems run and operated by companies in the mid market. That said, something I often wonder about is if you could minus out 100% of the cruft systems run by realistic sized companies, exactly how cheaply could you run them and with what DX? Half of the problem is things built by 100 people with competing and shifting priorities will never result in a clean, tidy, sensible system and it's mighty difficult to minus out the effects that the organization scale has on the end result. I'm currently working through building a hobby project on that as far as I know will only ever have one user, but I'm enjoying the total freedom to take my sweet time building it exactly as nice as I wish the systems I wrangle in my day job would be and I'm 100% looking to run it for free or as close to free but with as much performance as I can get because why the hell not? It's a totally different ballgame.
Traubenfuchs 4y ago
I think you mean: > your infrastructure is automated using 10 extremely complex devops tools ... held together by ... > a handful of Bash, Perl and Python scripts written by two system administrators. They are custom, sometimes brittle and get rewritten every 5 years. We learned nothing in the last decades. If at all, complexity for the same things multiplied.
bluedino 4y ago
2005: you had 4 people that understand what everything did 2022: you have a team of monkeys clicking buttons Joking aside, it seems like the developers these days don't have the understanding that they did a while back. Not being involved with the nitty-gritty causes them to just write code willy-nilly.
kmitz 4y ago
Author claim is more about how to make people work together on deployment. Rather than a rant on devops tools. You can do simple things with modern devops tools. You can go off rails with simple scripts. It's not the tooling, it's about engineering maturity and the requirements of what you're building.
phendrenad2 4y ago
Perl/Bash/Python? Maybe for non-mission-critical things. By 2005 everyone who needs stability/scalability were using J2EE.
rndmind 4y ago
Today's shit has 10x or 100x more throughput, it makes sense that upgrading data response and availability requires more people. But, todays devops has become a proprietary mix of aws protocols, constantly changing standards and languages. I still use bash scripting wherever I can, it is much more simple and has been ultimately unchanged for decades, which is nice for compatibility
mmcnl 4y ago
2005: your infrastructure powers a webshop with $1m annual revenue 2022: your infrastructure powers a $5b startup

mountainriver 4y ago

True but to be fair modern infra does a hell of a lot more

lox 4y ago

In 2005 your infrastructure provisioning wasn’t automated. The complexity has increased, but so has what we get. Being able to provision new hardware stacks like software is amazing, in 2005 I had to get quotes from hosting providers.

iso1631 4y ago
Whereas now nobody cares about the cost because it's all hidden away in a massive bill at the end of the month?

_vertigo 4y ago

Not pictured: 2005 your average box served some php and static assets, connecting to some generic relational database. Reading logs means grepping files over ssh. 2022 your architecture runs in the cloud, has multiple flavors of databases, queues, caches, and so on. You have at least two orders of magnitude more complexity because you aren’t just serving a web page anymore - you handle payments, integrate with other services, queue tasks for later, and so on. Your automation may be an order of magnitude more complex than 2005, but it enables two orders of magnitude more functionality.

stathibus 4y ago
My classic C programmer curmudgeon take is that the root of the problem, as with everything else in this industry, is bad software built on top of bad software built on top of bad software... and on it goes. The systems in your 2022 world are hard to test and maintain because they are bad, and the tools we built to test and maintain them are largely built on the same foundational ideas and technologies, so they are even worse. We're going to have to rip everything back down to the foundation in order to make progress beyond finger-pointing (X is DevOps but Y is software engineering and Z is IT admin).
- theflyinghorse 4y ago
  What software is bad precisely? The modern browsers? The tools we use to build modern browser apps? Perhaps your gripe is with something else entirely, like modern databases? Or is it the OS that you don't like? Really not sure what you're commenting about here
  - Godel_unicode 4y ago
    They said that the world is bad software on top of bad software, so it’s not one thing. It’s everything being bad and working around everything else being bad.
    - voidfunc 4y ago
      Yea but they didn’t explain why its bad. Software devs complaining about “bad software” is basically an industry trope at this point but often it just means “Its too complex and I don’t understand why that complexity is probably necessary” or “Its not written the way I would have written it”.
    - arinlen 4y ago
      > They said that the world is bad software on top of bad software, so it’s not one thing. I don't know about OP, but I personally feel like software like GCC/clang/MSVC and Debian/Ubuntu and Docker and SSH and Git are pretty great, and were never better. Heck, the whole dotnet ecosystem is turning some significant problems in developer experience into at most minor nuisances. Even Firefox+Chrome are stellar, and extremely solid as-is. Where exactly is this bad software OP is talking about?

winternett 4y ago

It's usually always a solution with an overly complex chain of tools that only do a small part of deployment/security tasks because it's a food chain, where each vendor can eat a part of the company's budget consistently, based on a problem that really isn't consistently solved... Apps are still no more secure because there are several points where they can be compromised, rather than just a few involved in a less automated, but more easily replicate-able process. Also, I don't need "flavor of the month" skills to get things done. There is always a revolving door of fly-by-night-hype tools and brands that regularly rise and fall in the IT world... I avoid them (new hyped products) like the plague. I'm fine with being the stubborn middle aged IT guy now. :P It's all a food chain based on making money. What matters to me most is whether money is being made from the product that is deployed, and if it's simple, reliable, and secure enough to be worth development. I don't do my job to make a bunch of companies money by using their DevOps tools. Screw impressing other engineers with solution complexity every time. Functional reliability always wins at the end of the day. Leveraging a massive list of Ops tools only creates a huge backlog of update work, designing efficiency and simplicity in most of my solutions is what ultimately pleases most of my clients.

paddlepop 4y ago

This is a build deployment perspective. I for one do not miss hosts never being patched because all those slight modifications to systems files that were tweaked several builds ago and now everyone is too scare to touch. I won't miss the 12 month projects to upgrade some dated software to a slightly less dated version of that same software. From my perspective in Security, DevOps has made life much better.

tech_tuna 4y ago
At my first company, our builds happened whenever the release engineer (he was friends with the milk man and chimney sweep) felt like "doing a build". As another example, CI/CD adds a lot more work and maintenance but it results in better overall hygiene.
fragmede 4y ago
The ability to spin up a box, have it run insecure code, and then spin it down; and the ability to do that all day long, is worth it for the security benefits that all this complexity entails.
- HWR_14 4y ago
  > The ability to spin up a box, have it run insecure code, and then spin it down; and the ability to do that all day long What's the best way to do that? I have some insecure code that needs to run about 6x a day, and so far my best thought has been an isolated box outside my network that does the internet based fetches, translates the data and then submits them over the web to another service that verifies/checks the output.

inopinatus 4y ago

All you’ve demonstrated is that some folks are bad at SRE.

CommanderData 4y ago

IaC wasn't even prevelant or a production ready thing back in 2005. I'm unsure what magical bash scripting would do any of that, maybe it the data centres too!

aghahsdsdfh 4y ago
IaC wasn't a thing because you honestly didn't need code to solve the vast majority of deployment problems. It was a configuration issue. Not 2005, but a year later in 2006 I was using cfengine to deploy code and configuration to servers from an svn repository. The same svn repository had dhcpd configs that described pretty much every device on the network. The dhcp configs also pointed to a tftp service from which new nodes pxe booted to an installer which pulled down the node specific kickstart, and provisioned the machine. We didn't call it infrastructure as code, but it sure fucking smells the same.

bryanrasmussen 4y ago

>to the people claiming that today's infra does more things... No, I'm comparing stuff with the same levels of availability, same deployment times, same security updates. ok but in my experience it seems like more things are being done in places I see with devops nowadays versus back then. I mean I know you say that it's the same, but it's hard to believe your statement in a comment versus my lying eyes. It seems more likely to me that your two examples are both actually fictitious and thus it is easy for you to say that they are exactly the same in what gets output - or have you been at the same place for 17 years, seen the changes, yet have had no input on the company to stop the madness? Because if the latter that would also seem... weird.

thr0wawayf00 4y ago
Were microservices a thing back in 2005? Honest question, I always assumed that SOA was more of a newer philosophy in web software. The scale of what we build has changed a lot over the years, as well as the need to handle the variance of scale through techniques like auto-scaling. All of that adds an incredible amount of complexity in systems that surely didn't exist 18 years ago.
- bryanrasmussen 4y ago
  I don't think SOA was in common discussion in 2005, I think more about 2007 would sound right, Rest was pretty much the winner by 2009. But perhaps my memories here are warped by my personal career and not having to have the arguments after 2009. No I don't think microservices was anywhere at that time, although one could argue that they are a repackaging of the ideas of Small Pieces, Loosely Joined https://en.wikipedia.org/wiki/Small_Pieces_Loosely_Joined https://en.wikipedia.org/wiki/Small_Pieces_Loosely_Joined or an architectural expression of loose coupling https://en.wikipedia.org/wiki/Loose_coupling https://en.wikipedia.org/wiki/Loose_coupling for corporate data.

mediascreen 4y ago

I run 50+ smallish applications on AWS using Bitbucket Pipelines, Fargate, Aurora MySQL, S3, Cloudfront and a few other services. Most of the setup is scripted using very simple Cloudformation scripts. I estimate that I spend maybe 10% of my time on this and the rest of my time on ordinary dev/architecture tasks. Before Docker and AWS this would have taken me so much more time. The only drawback is that we have a hard time finding other developers in the company that want and have the time to learn the setup. It's not very complicated, but require some familiarity with the AWS ecosystem. It can seem daunting to someone who has to learn it from scratch.

russellendicott 4y ago
> The only drawback is that we have a hard time finding other developers in the company that want and have the time to learn the setup This is my experience as well in enterprise cloud. I don't get it. Have these people seen what cloud jobs pay for less work?

shrubble 4y ago

1997: a team of 5 sys admins, 3 of them functional alcoholics, writing only in Bash scripts, manage over 2000 internet facing SPARC machines. A lot of DevOps is actually CVOps - stuff that people get familiar with so they can put it in their resume.

iso1631 4y ago
What was wrong with the other 2?
- nineteen999 4y ago
  Dysfunctional alcoholics.
iso1631 4y ago
Those bash scripts probably still in place and working, meanwhile modern ways of managing the servers have been recreated a dozen times over the last 25 years as every time a new person comes in there's always a better way of doing things. The difference is now you're a failure if you stay at the same job for more than 2 or 3 years.
- deleted 4y ago
  [deleted]
barking_biscuit 4y ago
CVOps - hahahaha. I've always heard and used the term "Resume Driven Development" but I guess CVOps is a nice term too.

lazyant 4y ago

2005: no cloud, had to order 1Us, wait, rack up. Needed a DBA for the database, a network sysadmin for the networking, all to serve a simple website with not the same level of HA. We are doing way more now, which needs some more complexity and yes, in many cases we are overengineering it.

iso1631 4y ago
2005 Linode sold me VMs, no need for a DBA or network admin for a simple main/reserve website 17 years later and getting more than 364 days uptime out of AWS is apparently "not worth the cost"

EdwardDiego 4y ago

So someone overengineered something in 2022, and therefore, nothing's better? How about my anecdata: 2010: your infrastructure is automated using a handful of Bash, Perl and Python scripts written by two system administrators. They are custom, brittle in the face of scaling needs, and get rewritten continuously as your market share and resulting traffic grows. Outages happen far too often, you think, but you would, because you're someone who gets paged for this shit, because you know a core system well... ...that got broken by a Perl script you didn't wrote. 2019: your infrastructure runs on EKS, applications are continuously deployed as soon as they're ready using Jenkins and Flux. You wrote some YAML, but it's far better than that Perl stuff you used to have to do. The IDE support is like night vs day. You have two sysops, or devops, or whatever, who watch over the infra. You've had to attend to a system outage once in the past two years, because an AWS datacentre overheated, and the sysops just wanted to be sure. You write some YAML, the sysops write some CDK. Your system is far more dynamically scalable, auditable, and reliable. My anecdote can totally beat up your anecdote.(In other words, this is a silly line of argument)

icod1 4y ago

My 2020 looks like this: no docker no k8s 1 server git repo /var/www/domain_name git clone git_url /var/www/domain_name/backend/ cd /var/www/domain_name/backend/ go build Updates git pull go build systemctl restart domain_name.backend.service I pay 46€/month and I'm looking forward to halve those costs. Server load is mostly <0.5 I call this the incubation server. If a project takes off I rent a more expensive, but dedicated, server. It's very unlikely that I ever need more than 1 single server per project. I will never write microservices, I can scale fine with a monolith. Lately I even moved away from JS frontends to render everything with Go on the server. Yeah it requires more resources but I'll gladly offer those resources for lower response times and a consistent experience. Sadly companies that are hiring don't see it that way. That's ok. I'll just stay unemployed and try building my own stuff until something succeeds again. I had a 7 year long project that brought in 5-7k€/m. The server costed 60€/m. I can do that again. I know it's not your kind of scale or income level, but it allowed me to have a good life living it my way.

mmcnl 4y ago
No one ever said a VPS with a shell script is terrible. You think of scale the wrong way. Scaling is not only about increasing from 10 requests / second to 1000 requests / second. Scaling is about organizational scale too, i.e. how do you ensure going from 2 to 20 developers increases productivity by at least 20x and not 1.5x? Tools like Docker, Kubernetes and whatever absolutely help in that regard.
barking_biscuit 4y ago
I think it's somewhat disingenuous to compare DevOps requirements of 5-7k/m projects with systems run and operated by companies in the mid market. That said, something I often wonder about is if you could minus out 100% of the cruft systems run by realistic sized companies, exactly how cheaply could you run them and with what DX? Half of the problem is things built by 100 people with competing and shifting priorities will never result in a clean, tidy, sensible system and it's mighty difficult to minus out the effects that the organization scale has on the end result. I'm currently working through building a hobby project on that as far as I know will only ever have one user, but I'm enjoying the total freedom to take my sweet time building it exactly as nice as I wish the systems I wrangle in my day job would be and I'm 100% looking to run it for free or as close to free but with as much performance as I can get because why the hell not? It's a totally different ballgame.

Traubenfuchs 4y ago

I think you mean: > your infrastructure is automated using 10 extremely complex devops tools ... held together by ... > a handful of Bash, Perl and Python scripts written by two system administrators. They are custom, sometimes brittle and get rewritten every 5 years. We learned nothing in the last decades. If at all, complexity for the same things multiplied.

bluedino 4y ago

2005: you had 4 people that understand what everything did 2022: you have a team of monkeys clicking buttons Joking aside, it seems like the developers these days don't have the understanding that they did a while back. Not being involved with the nitty-gritty causes them to just write code willy-nilly.

kmitz 4y ago

Author claim is more about how to make people work together on deployment. Rather than a rant on devops tools. You can do simple things with modern devops tools. You can go off rails with simple scripts. It's not the tooling, it's about engineering maturity and the requirements of what you're building.

phendrenad2 4y ago

Perl/Bash/Python? Maybe for non-mission-critical things. By 2005 everyone who needs stability/scalability were using J2EE.

rndmind 4y ago

Today's shit has 10x or 100x more throughput, it makes sense that upgrading data response and availability requires more people. But, todays devops has become a proprietary mix of aws protocols, constantly changing standards and languages. I still use bash scripting wherever I can, it is much more simple and has been ultimately unchanged for decades, which is nice for compatibility

mmcnl 4y ago

2005: your infrastructure powers a webshop with $1m annual revenue 2022: your infrastructure powers a $5b startup