5 ms·

Sounds a bit like those places aren’t at the scale where a platform team makes sense. What about when the one dev deploying their jar to an ec2 instance moves

Sounds a bit like those places aren’t at the scale where a platform team makes sense. What about when the one dev deploying their jar to an ec2 instance moves on to another company, how does the next dev even understand what this jar stuff is when they just want to push their SPA to vercel. Allowing devs to do whatever they want works at small new orgs but you need to put some kind of shape on it as they grow.

adrianmsmith 3y ago
> What about when the one dev deploying their jar to an ec2 instance moves on to another company, how does the next dev even understand what this jar stuff is I think that's more a problem of one person vs a team, as opposed to deploying JARs on EC2s vs cloud and a bunch of custom tooling. If you have a team of devs and they all deploy JARs to EC2, one of them leaving won't be a problem, the rest will still know how to do it. If you were to have a single platform engineer who's built a bunch of custom tooling over a bunch of Kubernetes files, and nobody knows how it works or where the files are, and then they leave, you've got the same problem as the solo EC2 dev leaving.
- re-thc 3y ago
  > I think that's more a problem of one person vs a team Not always. The "team" you imagine might also be 1 person deploying the jar and the rest copying them. When that person leaves suddenly know 1 knows what to do anymore either.
switch007 3y ago
> Sounds a bit like those places aren’t at the scale where a platform team makes sense. But so many orgs want to believe they are Google scale and you’re stuck with premature teams such as Platform Engineering. Then it just explodes and suddenly you have a director of platform Engineering and multiple sub teams and suddenly OKRs, ADRs, RFCs, team charters and perpetual Kubernetes upgrades and nobody can question its existence any more
- blowski 3y ago
  SOC2 is behind a lot of that. Companies need to be compliant to sell into enterprises. They don’t want to go through the compliance process for each individual team, so they try to standardise. Lots of locally optimised teams don’t necessarily make an effective and efficient system.
  - re-thc 3y ago
    > SOC2 is behind a lot of that. Which might actually be a good thing in disguise. Lots of companies do random things that just look good from the outside. I've been to places where code review wasn't a thing until SOC2 forced their hand and even then it wasn't well enforced.
    - blowski 3y ago
      Yes, I agree. SOC2 is the closest we have to a “professional standard” in engineering right now, and it’s forcing a lot of changes.

adrianmsmith 3y ago

> What about when the one dev deploying their jar to an ec2 instance moves on to another company, how does the next dev even understand what this jar stuff is I think that's more a problem of one person vs a team, as opposed to deploying JARs on EC2s vs cloud and a bunch of custom tooling. If you have a team of devs and they all deploy JARs to EC2, one of them leaving won't be a problem, the rest will still know how to do it. If you were to have a single platform engineer who's built a bunch of custom tooling over a bunch of Kubernetes files, and nobody knows how it works or where the files are, and then they leave, you've got the same problem as the solo EC2 dev leaving.

re-thc 3y ago
> I think that's more a problem of one person vs a team Not always. The "team" you imagine might also be 1 person deploying the jar and the rest copying them. When that person leaves suddenly know 1 knows what to do anymore either.

switch007 3y ago

> Sounds a bit like those places aren’t at the scale where a platform team makes sense. But so many orgs want to believe they are Google scale and you’re stuck with premature teams such as Platform Engineering. Then it just explodes and suddenly you have a director of platform Engineering and multiple sub teams and suddenly OKRs, ADRs, RFCs, team charters and perpetual Kubernetes upgrades and nobody can question its existence any more

blowski 3y ago
SOC2 is behind a lot of that. Companies need to be compliant to sell into enterprises. They don’t want to go through the compliance process for each individual team, so they try to standardise. Lots of locally optimised teams don’t necessarily make an effective and efficient system.
- re-thc 3y ago
  > SOC2 is behind a lot of that. Which might actually be a good thing in disguise. Lots of companies do random things that just look good from the outside. I've been to places where code review wasn't a thing until SOC2 forced their hand and even then it wasn't well enforced.
  - blowski 3y ago
    Yes, I agree. SOC2 is the closest we have to a “professional standard” in engineering right now, and it’s forcing a lot of changes.