5 ms·

I like to believe that serverless technologies and cloud services reduce complexity for the org, but obviously that's at the cost of offloading that complexity

I like to believe that serverless technologies and cloud services reduce complexity for the org, but obviously that's at the cost of offloading that complexity to the cloud providers (and welding an org's software to that provider for years, if not decades). So different, but not less complex overall. But maybe there is value in having some of that complexity consistent across a small number of cloud providers.

hinkley 4y ago
Every time our operating costs go up (eg, cloud providers), something else in the organization gets more complicated in order to make up the shortfall. Or super simple when we go out of business. No free lunches here.
- parsley27 4y ago
  That assumes operating costs go up with cloud providers. Some orgs see savings, but obviously not all.
  - hinkley 4y ago
    Some developers are merely bad at math. Most are awful. Others take this flaw to epic proportions. Be afraid of the developer who confidently tells you the math works out. It's true that a lot of organizations had operational teams that have become money pits, or pushed back on all quality of life improvements because they don't have the talent, the budget, or the imagination to pull it off. When we move to the cloud we start aspiring to these things we didn't have because they were expensive. I don't know of anyone who moved to the cloud and didn't move the goalposts. We were just talking in another thread, as we often do here, about how much YAGNI is going on out there. Yes, the price per feature goes down, but the overall price doesn't seem to. And I get stuck taking care of things someone else used to worry about, which is opportunity cost on top of it all. What is also true is that developers can learn a lot from their operational peers and avoid expensive mistakes. With cloud we have none of those peers. We have to learn everything first hand. By someone who is all too happy to let us wrap rope around our necks and then 'rescue' us from themselves. That's a perverse incentive and quite a setup for a fairly fucked up codependent relationship. At least with interdepartmental drama some of the money stays in the company longer before going to vendors.
    - datavirtue 4y ago
      We used to have devs bringing in frameworks and libraries without reading the manual. Now they spin up entire services or subsystems without reading the manual. You should read through the docs for MongoDB Atlas...which plainly illustrate that you now need a DBA unless you're cool with people pressing buttons in a panic during some type of self-induced performance issue.
tomrod 4y ago
Having moved services from on prem servers to EC2 to OCP to EKS, I don't think these decrease complexity.
mark242 4y ago
They absolutely do reduce complexity! For example, think about building, testing, and deployments. In pre-cloud Internet times, you'd have an untold number of extremely brittle bash scripts, cron jobs, rsync ssh key setup, fleets of build + test boxes to manually worry about disk space, pre-provisioned dev/QA database servers with also untold brittle sql startup/teardown scripts, and all of the requisite people whose job it was to solely maintain this infrastructure along with database tuning, build fleet monitoring, the list of menial tasks just goes on and on and on. Today, you have a yaml file in your .github/workflows directory. Now I agree that there are "different" requirements. Understanding the complexity of your workflows etc is no small feat-- but you're replacing such a huge amount of what used to be extremely expensive and brittle architecture with, basically, a text file or two. That's a huge cost savings.
- beardedetim 4y ago
  Are you counting Chef/Ansible/Puppet/etc as things that came during the cloud era or that those things were not used to solve the problems you raised before the cloud era?
  - mark242 4y ago
    Having used Puppet, the promise of Puppet was very different than the realities of Puppet and imo more accurately reflects the "different complexities" point. The point of those provision-bare-metal-on-the-fly frameworks just evaporated when, for example, you could launch a container on Fargate with, again, a single text file, or similar on Heroku.
- chasd00 4y ago
  idk, in the enterprise world all those things still exist but they're applied against AWS/other instead of your servers in the datacenter. Instead of "build+test boxes" you have "build+test instances". It takes the same level of redtape/approvals to get an AWS instance as it took to get a server in the old datacenter. All my enterprise clients have the dedicated infrastructure teams they always had, only now they're working in AWS/other and not the datacenter.

hinkley 4y ago

Every time our operating costs go up (eg, cloud providers), something else in the organization gets more complicated in order to make up the shortfall. Or super simple when we go out of business. No free lunches here.

parsley27 4y ago
That assumes operating costs go up with cloud providers. Some orgs see savings, but obviously not all.
- hinkley 4y ago
  Some developers are merely bad at math. Most are awful. Others take this flaw to epic proportions. Be afraid of the developer who confidently tells you the math works out. It's true that a lot of organizations had operational teams that have become money pits, or pushed back on all quality of life improvements because they don't have the talent, the budget, or the imagination to pull it off. When we move to the cloud we start aspiring to these things we didn't have because they were expensive. I don't know of anyone who moved to the cloud and didn't move the goalposts. We were just talking in another thread, as we often do here, about how much YAGNI is going on out there. Yes, the price per feature goes down, but the overall price doesn't seem to. And I get stuck taking care of things someone else used to worry about, which is opportunity cost on top of it all. What is also true is that developers can learn a lot from their operational peers and avoid expensive mistakes. With cloud we have none of those peers. We have to learn everything first hand. By someone who is all too happy to let us wrap rope around our necks and then 'rescue' us from themselves. That's a perverse incentive and quite a setup for a fairly fucked up codependent relationship. At least with interdepartmental drama some of the money stays in the company longer before going to vendors.
  - datavirtue 4y ago
    We used to have devs bringing in frameworks and libraries without reading the manual. Now they spin up entire services or subsystems without reading the manual. You should read through the docs for MongoDB Atlas...which plainly illustrate that you now need a DBA unless you're cool with people pressing buttons in a panic during some type of self-induced performance issue.

tomrod 4y ago

Having moved services from on prem servers to EC2 to OCP to EKS, I don't think these decrease complexity.

mark242 4y ago

They absolutely do reduce complexity! For example, think about building, testing, and deployments. In pre-cloud Internet times, you'd have an untold number of extremely brittle bash scripts, cron jobs, rsync ssh key setup, fleets of build + test boxes to manually worry about disk space, pre-provisioned dev/QA database servers with also untold brittle sql startup/teardown scripts, and all of the requisite people whose job it was to solely maintain this infrastructure along with database tuning, build fleet monitoring, the list of menial tasks just goes on and on and on. Today, you have a yaml file in your .github/workflows directory. Now I agree that there are "different" requirements. Understanding the complexity of your workflows etc is no small feat-- but you're replacing such a huge amount of what used to be extremely expensive and brittle architecture with, basically, a text file or two. That's a huge cost savings.

beardedetim 4y ago
Are you counting Chef/Ansible/Puppet/etc as things that came during the cloud era or that those things were not used to solve the problems you raised before the cloud era?
- mark242 4y ago
  Having used Puppet, the promise of Puppet was very different than the realities of Puppet and imo more accurately reflects the "different complexities" point. The point of those provision-bare-metal-on-the-fly frameworks just evaporated when, for example, you could launch a container on Fargate with, again, a single text file, or similar on Heroku.
chasd00 4y ago
idk, in the enterprise world all those things still exist but they're applied against AWS/other instead of your servers in the datacenter. Instead of "build+test boxes" you have "build+test instances". It takes the same level of redtape/approvals to get an AWS instance as it took to get a server in the old datacenter. All my enterprise clients have the dedicated infrastructure teams they always had, only now they're working in AWS/other and not the datacenter.