[Dioxide2119]

> A key feature of a platform should be that the developers choose when a deployment happens.

Agreed. When I was on a platform team we wrote tools to take a process that used to be done by a deployment team (change a DNS record was a helpdesk ticket) and move it into a self-serve system (PR your desired DNS changes in, upon merge, the system deploys the changes), which kept audit happy because 'dev' wasn't touching 'prod' in the unfettered way SOC2 people stay up at night worrying about (even though Enron happened because of bad managment not Office Space but anyways), while still giving Devs effective control of when and where they wanted to make production changes, whether relatively ad-hoc or as part of a CI/CD pipeline.

Humans could approve the self-service PRs, or if a list of in-code rules had been fulfilled, the PR would be auto approved (and potentially even merged but everyone but us was too afraid to set that part up).

[gtirloni]

I'd say that's a CI/CD team.

Platform means different things to different people but it should offer a standardized way of doing things that's well supported while allowing for customization by developers when needed (with less support when you step out of the golden path). It's a combination of software, processes and management buyin.

The way I see most "DevOps" teams working is they're just writing scripts that do whatever was requested without much thought about how sustainable that is, how company-wide policies can be enforced, or retrofitting improvements to other codebases... It's all very quick-and-dirt solution, one after the one until they end up in software engineering madness with developers complaining that things take too long or break easily while devops engineers complain developers don't know what they are doing. It's not a productive situation to be in.

I think platform engineering is just about having a systematic approach that gives developers more peace of mind so they can focus on actually coding features while giving the rest of the organization a bit more control points about how things are maintained. It's the 80/20 rule applied to devops, I guess. Just enough centralization.

I'm also very excited about platform engineering and I think it's a natural progression because, frankly, what people call DevOps these days is just a nightmare. God forbid the org has "distributed DevOps" a.k.a. do whatever you want in your team and when it's time to make a global change we will work with >20 different ways of doing something. That will be quick.

[agentultra]

> what people call DevOps these days is just a nightmare.

I agree! It's taken on a, "you'll know it when you see it," kind of definition and it's hard to pinpoint what "DevOps" is and whether your organization is practising it.

And so I've often seen it become a veneer for the original "silos" it was meant to break down: those handful of developers who still want nothing to do with managing their code and services in production get to throw code over the wall and someone else gets to hold the pager and keep it running, make it fast, etc.

In other words, the company hires "devops" which becomes a new title for "system administrator," and everything stays the same.

Platform engineering, devops, it's all evolving... but some things never seem to change.

[danielovichdk]

I respectfully disagree.

A platform team will eventually and quick fast become a bottleneck, especially if they offer abstractions over infrastructure, paas, saas etc.

Such a team is not any different than previous admin/infra teams. The operation model. When their offering breaks or is incapable, dependent teams wait or is stuck.

A team should be self sufficient and be able to decide for themselves how they cope with what they need to move forward in a sustainable manner. That means they should do everything themselves towards enabling there offering.

I have worked with so called CI/CD teams at least 10 times and it doesn't foster what devops is all about, which is essentially collaboration, mandate and responsibility for your software, inside a smaller team.

It comes down to how you organise and where decisions are placed and carried out. Something that reflects on centuries of command and control organisations where it has been around controlling and not enabling and autonomy.

I have worked a few places where the platform decision was taken on a broad spectrum, aws for example, and from there every individual teams could do whatever.

Every software/product team should be able to do everything they need to develop,test,deploy,secure and monitor their things. It works in a lot of places so of course it can work in a lot of other places.