Platform Engineering Is The New Kid On The Block

Platform Engineering is the new kid on the block in the world of DevOps and Continuous Delivery, at least that is the claim. To begin the process of adoption of CD it is useful to have people that know what they are doing and that can guide organisations toward success, but, at least in the messaging around Platform Engineering, it seems to be saying something different to that, and falling into a very old trap.

In this episode, author, speaker and software engineer Dave Farley explores what Platform Engineering is, what it should be, and where current proponents may be offering some bad advice.

-

⭐ PATREON:

Join the Continuous Delivery community and access extra perks & content!

-

👕 T-SHIRTS:

A fan of the T-shirts I wear in my videos? Grab your own, at reduced prices EXCLUSIVE TO CONTINUOUS DELIVERY FOLLOWERS! Get money off the already reasonably priced t-shirts!

🚨 DON'T FORGET TO USE THIS DISCOUNT CODE: ContinuousDelivery

-

🔗 LINKS:

-

BOOKS:

and NOW as an AUDIOBOOK available on iTunes, Amazon and Audible.

📖 "Continuous Delivery Pipelines" by Dave Farley

NOTE: If you click on one of the Amazon Affiliate links and buy the book, Continuous Delivery Ltd. will get a small fee for the recommendation with NO increase in cost to you.

-

CHANNEL SPONSORS:

I am a platform engineer and my work is basically to encapsulate the accidental complexity of the environments in which the code runs so the developers can focus on doing code. Why not let the devs do that too? cost and almost impossible to find people able to do so. Most devs we interview hardly know what TDD, DDD, TBD, and CI are now add on top knowing Docker and some infrastructure and you will look at a pool of candidates that is terrible expensive and small or non-existant.

In that scenario is where someone like me, 15 years doing software engineering and system administration, comes and encapsulates a lot of the complexity so the company can access a wider hiring pool and start adding value.

[emmanouilgkatziouras]

If you are around long enough eventually it's just engineering.

[thought-provoker]

"Platform engineering" is often a nice way of saying, _"We're moving back to specialist teams who don't understand the business context within which they operate - but we call them platforms now."_

[ryanslab]

I work in the enterprise. I’m considered a platform engineer and previously called a DevOps engineer. I like the term because it puts me and my team into a product mindset instead of services mindset. Products scale much easier than services. When I build a platform, I’m building abstractions of hundreds of AWS services, services in AWS, on-prem and other SaaS services with APIs. I look at the services through the lens of the organization’s security and compliance policies. This saves developers so much time that they don’t have to worry about the security and compliance of a service because me and my team put those guardrails in the abstraction. We cannot expect developers to know all these things or be expected to learn them. It would be such a waste of money. Another benefit a platform is on boarding and off boarding developers, self-service and giving management the tools they need to hold development teams accountable.

[sanler]

For me, as mobile engineer, overuse of platform team concept nowadays looks more like a result of dysfunctional processes.

“We need a platform team” is usually said when project is buried in technical debt due to inadequate power balance engineering vs product design. So the alleged solution is: let’s put a couple of engineers outside of product design so that they are not overloaded with features and can take care of overall quality.

[tribble]

I think the hype around platform engineering comes from the same managers that 10 years ago demanded big data solutions for dbs that fit in memory. A premature silo to pretend to be bigger than they are at the expense of the engineers

[michaelpeterson]

I think at least part of the issue here is we are talking about two very different things that have almost the same name. The new "platform engineering" role appears to focus on DevOps admin and common tooling. But the platform team as described in Team Topologies is a software engineering team that creates things like common code libraries and interfaces into security, connection pooling, auth, monitoring, logging, metrics, and other fundamental code requirements.
Platform engineering has co-opted the term platform and distorted its meaning. 0:02 0:02

[fennecbesixdouze]

I was on a project where we started using serverless and it was great. We used all the abstractions that AWS provided directly for infrastructure and we could write very clear code where we understood everything we were using, all of the the platform abstractions we were using were clearly documented by AWS and predictable and high-quality.

We were so successful the business started investing more into our serverless and bringing "serverless" enthusiast people on board. At that point, it all fell apart. The serverless enthusiast people started writing "construct libraries": more abstractions on top of the AWS abstractions to abstract away bits of infrastructure that might be useful in many places, so we could be "DRY". Now we had to contend with home-grown "platform infrastructure" abstractions that were not at the level of quality that AWS could deliver.

[BryonLape]

There are no new ideas, just new ways of labeling them.

[gooseberry]

It reminds me ESB. On my next to last job my company had specialized ESB teams (and even an architect responsible for all of that) to hide the complexity of communication between services. I was part of it for some time implementing several ESB-services. One job and couple of years later, my next company was decommissioning ESB-services (and teams) to bring control back to feature teams. They also introduced devops teams (they called theirs members SRE) to hide complexity of infrastructure and deployment. So devops created a pipeline, although it didn't deliver anything anywhere. I left that job too, so I don't know how it all ended.

[GlebWritesCode]

My understanding is that platform engineering helps with plumbing. For any decent sized project you want devs to be working on business problems, not battling arcane platform/infra stuff.

In last 3 orgs we had foundational libraries that help with things like message passing, auth in web services, caching, working with relational DB (both data and schema), logging, metrics, healthchecks, object storage, notifications (sms/email).

Previous employer had me and one other colleague who built this stuff for several dev teams to use (we worked on business tasks as well), and eventually they introduced the dedicated platform team to improve the libraries and support other tech stacks that are in use.

In my opinion those libraries are essential even if you use one tech stack across the company. They make it easy for easy onboarding, switching developers between projects

[eugeneterblanche]

Where can I get that T shirt? I am having a bad day with our "Platforms"

[adambickford]

I worked at a fortune 100 company with a forced 'platform' and it was terrible. Forced upgrades that could just blow up an entire sprint with breaking changes, yet you can't get things like a modern version of java on the platform. Some terrible leaky yaml mess over the real cloud apis, only you can't google anything and slower, undocumented bug fixes. A new cloud service that solves your problem? Not for at least a year for the 'platform team' to add another bad abstraction over the latest cloud services, assuming they think you need it and they feel like supporting it.

All while touting innovation and autonomy.

[HedleyLuna]

Imagine expecting a software engineer to deeply understand networking and how a load balancer can be optimized or maybe how to somewhat standardize k8s clusters across hundreds of teams in order to reduce costs or maybe you want to use a data platform but need a high data governance ? Well, platform teams do it (with well-defined and automated APIs) so stream aligned software engineers can deliver what matters.
Team Topologies explains it really well.

[ContinuousDelivery]

I didn't say that there was, Platform Team != Platform Engineering

[andrewfigaroa]

I agree, the same problem that happened to "DevOps"

From being the culture that helps in deploying code as seamlessly (without friction) as possible.
To
Any team of sysadmin that knows jenkins...

[seanknowles]

I am on the platform team. It works well, and I enjoy it. Nothing wrong with Platform teams.

[FlaviusAspra]

I agree with the statement "this is what platform engineering teams do, and this cannot work in cases other than the most simplistic".

But

I think 95% of these organizations have over-engineered themselves into frustration, and in reality they ARE operating in simplistic situations. The cost then is self-inflicted.

Don't forget: elegance comes from simplicity.

Don't forget: vertically sliced, highly available, modular, hexagonal monoliths go a very long way.

Don't forget: each microservice in isolation is exactly a modulith as described above, and independently deployable.

[Jebusankel]

My understanding of platform engineering is that PaaSs like Heroku have set the high water mark for Developer Experience, and we should aim for that even if we have to build our own internal infrastructure or need the scalability and distributedness of a modern kubernetes based system.

[billsmoke]

I've worked as a platform engineer at a geospatial research company for a couple of years now. The whole point of my position being created was that the company tried the whole DevOps thing (like many other companies) which led to the Devs and data engineers being completely burnt out from having to maintain infrastructure, monitoring, observability, CI/CD processes on top of their regular roles. I've got over 15 years experience working as a network engineer, sys administrator, linux admin and have quite a solid basis in AWS, so I do a lot of the infrastructure stuff that Devs don't give a fuck about lol. I don't think Platform engineering is hype, to second another persons comment, platform engineering is a reaction to failure that was DevOps, or trying to entirely amalgamate developers with the enormous task of maintaining networks, CI/CD processes, observability and cloud infrastructure.