Myths about platform engineering: what it is and what it isn't | Hacker News Reader

Myths about platform engineering: what it is and what it isn't

cloud.google.com

73 pointsmeysamazad34 comments

My company started using GCP in the last few months, and my tolerance for sanctimonious engineering articles from Google has gone down quite a bit as a result.

TIL a new word: Sanctimonious: making a show of being morally superior to other people.

I think you hit the nail on the head there.

Even if they have something good to say, the end result is that they can ship their spyware more efficiently. I'd rather give an audience to someone who is working on a project that helps humanity.

I worked in an AWS + GCP environment. There was a clique of people infatuated by Google. They would exert every effort to cargo cult Google and fail consistently. Their leadership chain also doted on Google so the end result was nothing got done and excuses were made with the promise of Google solutions, one day.

I've worked extensively with both GCP and AWS. I've met many Google engineers, TAMs, etc. and I wholeheartedly agree with your sentiment.

That said, I prefer GCP as a product to AWS (and don't even get me started on Azure).

I agree. Use all three and Azure is the worst.

At least Azure has UI workflows for everything that is also exposed via AZ, Powershell, ARM and bicep.

Nothing like tracking down what magic spell is needed to reveal on the CLI features not exposed on dashboards.

My AWS pet peeve is that there are edge cases where the console does some bit of magic but the AWS CLI team is allergic to including it.

Protip: If it’s useful enough to appear on the console, it’s useful enough for the command line.

Only once you have invested significant effort in implementing all the failure-handling and retry mechanisms in your code, then Azure works smoothly.

May be personal preference, or what you experienced first, but I prefer Azure with AWS as a close second, GCP as a distant third.

I find that AWS is overly account-focused, and it's more difficult to do operations at an org level. Azure is the inverse.

But I also don't like how Azure PaaS/serverless deploys open to the Internet by default.

You prefer Azure? Things on Azure don't work by default.

Can't be worse than Azure though!

This article specifically seems reasonable. There's still some very smart people at Google. Unfortunate that the culture eroded so much over the past 5-10 years and may be unrecoverable, though.

Full disclosure, I’m a PM on GKE. These articles get written because EVERY CUSTOMER WE TALK TO ASKS FOR THEM. “What are the best practices for x…”. Personally I stave these question off with “it depends” or “I’d really need to understand your business so we can appropriately talk about trade offs”. But honestly, I would LOVE if my customers trust amongst each other would mitigate the need to ask us for all up best practices on how to build and ship software.

I have a perhaps useful piece of feedback:

If customers are asking for this, its important to ask why. The more obvious you make best practices (like via the UI, documentation etc) and what generally GCP offerings should be used for (e.g., Firestore is a NoSQL database that is good for flexible, hierarchical data structures to store and query data) and have strong use case examples, it would got a long way to mitigating this. It won't obviate it entirely, but it would likely move the needle on customer satisfaction. Whats driving these forms of contact is that it isn't obvious and clear what tech should be used for what, and in what common circumstances.

[0]: FWIW I have the same feedback about all the big cloud providers.

Fair feedback. My team is working hard to up level the documentation. But sometimes complex problems require complex solutions and it is quite the art to capture the 80% use case while leaving room for the rest.

I also think these questions are driven from a CYA perspective. Most of the enterprise companies I talk to are interested in offloading risk on to their cloud provider (but still somehow wanting every single knob available).

Platform engineering applies the lessons the cloud providers have learned to internal software delivery.

Self service + APIs for all offerings reduces friction for developers and allow automating the most recurring things they want to do. Pay as you go pricing is the counterweight to the increase in freedom.

Viewing is this way makes the direction the whole platform engineering space is developing towards much more predictable.

> While the paradigm of "you build it, you run it" worked for systems of lower complexity and size, modern software systems are larger and more complex today than before, and the role of platform engineering has become increasingly vital in today's world.

YBIYRI and platform engineering are not at odds with each other. In fact, platform engineering should be an enabler of YBIYRI.

You Build It, You Run It

Thanks! It's the main subject of the post and right there on the first line of the quoted text but I realise I could have been clearer.

Reminds me of DOP #235: In the mid-2000s, Werner Vogels introduced the idea of “you build it, you run it”. This concept suggested that the same team responsible for building a product should also be responsible for running and maintaining it. However, despite the initial enthusiasm, we have yet to see this phrase truly materialize in practice. The industry has faced challenges in fully realizing the “build it, run it” philosophy.

https://www.devopsparadox.com/episodes/diving-into-platform-...

These don’t really read like “myths” exactly, but I appreciate the attempt to clarify the practice of platform engineering. The big question is: what is the platform?

of course it depends, but I think the industry is moving toward specific criteria.

I work directly in the space, fellow coworkers just published a series of articles attempting to answer the question about what the “platform” actually is [0]

0. https://developer.app

I read this and learned nothing.

If your idea is to 'save' developers from becoming experts in devops best practices, I think you're going the wrong way.

I know someone who works sales at a heroku clone who has this same mindset.

“Save devs from devops”

respectfully, after knowing and working with many ex googlers; i don’t think google are the operators and cloud experts they once were and thought themselves to be.

Hm. This is a lot of "isn't" and not a lot of "is", limiting the usefulness.

For example, something we as a platform team contribute to our products success is data safety, backups and archiving. Our dev-teams are just using our postgres clusters with little effort. That way they can say they are using a highly available storage layer, with perodic backups, backups being periodically restore-tested, backups being archived long-term and archived to multiple different locations and providers. We check many non-functional boxes overall.

And if a B2B customer wants to be a jerk about it, we can be invited to such meetings. And suddenly they aren't talking to a regular Dev or PO anymore, but someone who has been doing this for 10 - 15 years across different companies and industries.

This kind of backup tends to be very, very valuable to our smaller and more agile teams.

What a weird, sad, pointless article. There's nothing new about "platform engineering" or "internal developer platforms". The only myth is that these labels represent new ideas or unique approaches. These are just not-particularly-new names for something software companies and IT organizations have been doing for decades. And GCP offers no particularly unique or innovative tools, services, or support for building an internal platform.

I used the exact phrase "internal development platform" for the automation infrastructure I was developing to provide resources, security, libraries, databases, web endpoints, etc for internal ASP.NET applications at a state university where I worked over 20 years ago. It ran on a half-dozen bare-metal physical servers in the datacenter across the hall from my office. And I knew at the time that we didn't come up with some brilliant new breakthrough idea for organizing application development, because the university's mainframe programmers on the other side of the building had built a similar automation platform over 20 years before that. We modeled a lot of our design on theirs.

And here I am in 2024, working for companies, building exactly the same sorts of solutions, with all the same parameters and components, just in a different computing environment. Templates, access, runtime, database, storage, sessions, load balancing, logging, security. Whether it's a mainframe in the 80s, a few Windows servers in the 00s, cloud VMs in the 10s, or Kubernetes in the 20s, it's all the same problem space, and guess what, Google or anyone else preaching "platform engineering" hasn't created or realized anything new.

One might think that the wheel is periodically reinvented until one realizes that you are the wheel.

Could be worse, could be a lo-code platform.

I didn't notice the cloud.google.com source and thought this might be about developing software platforms that do something. That kind of Platform engineer has been around a long time now. Turns out this is about a software platform that does something for doing something, like the administration of software development or the machinery for devops. Good for any internal tool developers if it's not already obvious to them.

I think Platform Engineering is meant to die. If services like AWS or GCP were user friendly (from the perspective of product engineers) then we wouldn’t need platform engineers (or at least we would need orders of magnitude fewer platform engineers). The industry is young, though, that’s why I think we have the figure of the platform engineer.

Could you imagine having a Compiler Engineer define APIs and quotas so that you can use a compiler? Of course no. We can use compilers directly because they are mature software.

if your compiler was directly linked to your bank account, then you very well might have a compiler engineer to make sure you don't go bankrupt

I've noticed over the past few years that the role of the Platform Engineer is increasingly being rolled into that of the Software Engineer.

Can you imagine needing a license to operate a push lawnmower? Of course no. Therefore we don’t need pilot’s licenses.

Reply on news.ycombinator.com