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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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]
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.
36 comments
[ 2.9 ms ] story [ 83.5 ms ] threadI think you hit the nail on the head there.
That said, I prefer GCP as a product to AWS (and don't even get me started on Azure).
Nothing like tracking down what magic spell is needed to reveal on the CLI features not exposed on dashboards.
Protip: If it’s useful enough to appear on the console, it’s useful enough for the command line.
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.
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.
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).
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.
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.
YBIYRI and platform engineering are not at odds with each other. In fact, platform engineering should be an enabler of YBIYRI.
https://www.devopsparadox.com/episodes/diving-into-platform-...
If your idea is to 'save' developers from becoming experts in devops best practices, I think you're going the wrong way.
“Save devs from devops”
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
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.
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.
Could be worse, could be a lo-code platform.