Hacker News Reader

> I have always known at least one or two people who are great developers but they don’t want to know anything about operating systems, sockets, file descriptors, service level objectives and all that

IMO, those are not great developers. If you know nothing about how your code is running at a low level, you will reach a point at some scale where you’ve caused performance issues, and don’t have the fundamental knowledge necessary to fix it. Skilled or good, sure, but “great” implies mastery.

> I’m very much in the, “you wrote it, you run it,” camp.

As a sibling comment of mine pointed out, these are generally orthogonal skillsets. The main problem I’ve seen with it is that due to the relative ease of XaaS, dev teams with little to know knowledge of infra can indeed stand up an entire stack, and it will work quite well at first.

Databases, for example, are remarkably fast at small scale, even when your schema is horrible and your queries are sub-optimal. But if you don’t know the fundamentals (my first point), you won’t know that it’s abnormal for a modern RDBMS to take hundreds of milliseconds for a well-written query (assuming it’s not a cold read). You see that your latency is “good enough,” so you move on with the next task.

Then, when the service gets more popular, you hit the limits of the DB, so you vertically scale (if it isn’t already “Serverless” and auto-scaling – barf). It isn’t until the bill is astronomical that someone will bother to ask why it is you need a $10K/month DB.

> as demands on the platform team grow it can take longer to wait for your change requests to be deployed

That sounds like an ops or deployment team, not a platform team. A key feature of a platform should be that the developers choose when a deployment happens.

> 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).

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.

> 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.

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.

Deployment happens… to where?

The problem with "You wrote it, you run it" is they are completely orthogonal skillsets, and you lose the benefits of specialization. It introduces a high amount of context switching, and loses consistency in how services operate.

Sounds like the horizontal vs vertical integration debate all over again.

> It introduces a high amount of context switching

As opposed to having that context now shared between two people on separate teams?