[verdverm]

It's very valuable to have someone on your team thinking about infra all the time.

We know that we are constantly pulled in many directions in our industry, and often we take shortcuts to get the work out the door. Infra is not a place you typically want to take shortcuts. Burdening devs with the infra | ops responsibilities is a sure way to security incidents and inflated costs.

It does provide a good market for consultants|contractors to come in and clean up afterwards.

If we look at this job separation in a different analogy, why do we typically separate FE & BE development? b/c people can only be expected to be proficient in so much of the stack? And you typically want someone around who is proficient for each part of the stack?

[re-thc]

> If we look at this job separation in a different analogy, why do we typically separate FE & BE development? b/c people can only be expected to be proficient in so much of the stack? And you typically want someone around who is proficient for each part of the stack?

It's just been a convenient way to divide up the work? When FE & BE don't work together and aren't aware of each other it's just another mess. And then people invented Backend For Frontend to deal with it or GraphQL. We're just adding more layers and abstractions and complexities on top.

It's valuable to have someone to be dedicated to infrastructure. It's even more valuable for everyone to be aware of the whole ecosystem. No 1 lives in a silo.

[verdverm]

Truth, I've built a lot of automation for a CI / ops system. The devs have not taken the time to learn it, because business needs them to deliver value to the user. This certainly adds pain at times, but overall the business is better off with specialization and experts.

In an ideal world, it would be great for everyone to be aware, but people have limited time and the systems naturally grow large enough that you would have to spend all of your time just keeping up with the changes.

[re-thc]

> This certainly adds pain at times, but overall the business is better off with specialization and experts.

This is where we have architects, microservices and layers of complexity and abstraction.

> and the systems naturally grow large enough that you would have to spend all of your time just keeping up with the changes.

I've seen more cases where it doesn't actually need to be that large - just like you don't need infinite scaling or 1000 microservices and microfrontends. Instead of accepting that it has to grow - think about how it can work together more efficiently. In a lot of situations there's been more downtime due to redundancy, DR and other setups than having a simple instance.

Everyone architects their own part and a build tool / process for each of it... when does it end?

I see these "systems" that mention more as a mess and most people spend 80% of their time to workaround it or just procrastinate at how fragile it is.

[nostrebored]

Amazon seems to do it fine, as have many other places I’ve worked.

The truth is that infrastructure is not that complex when you have someone giving you building blocks and setting up guardrails. Having someone give you the pipelines and setting the boundaries is great. Choosing the pieces to get the product over the line is not that hard in a world where cloud is the norm.

[slyall]

You need a big team to maintain the platform and provide a controlled access to do stuff (PaaS is the buzzword) and then a bunch of above-average devs that are motivated, trained and incentivized to do their own bits of Infra properly.

Possible at FAANG[1] but gets a lot harder as companies get smaller and/or the devs teams are not setup to do that.

[1] I assume the SREs are not the only ones doing the Infra code