I've actually been on a platform team before
We did a few different things:
- created shareable independently deployable services and libraries other teams could use for their products
- had our own products that could be deployed to customers (internal and external)
- trialed newer versions of frameworks and tooling
- helped with integration of other teams products and our products, services, and libraries
- worked on technical processes for deploying different products with clashing dependencies to a limited environment
Were we perfect? No.
Did we make mistakes? Many.
Did we improve the development experience for other teams? I think so. We did remove a few large workloads by replacing the need for more devs with a toolimg that turned 2 weeks of work into 30 minutes for a non technical person. (Form building tool - very complex and non standard).
Can you discuss more about your work to help with integrations? Our team, which handles billing, has gradually been establishing ourselves as more of a platform team in the recent past. It feels like we’re on the same page between product and engineering about how our team should focus on billing workflows and leave features access to product dev teams. Of course, there’s a bunch of old code that definitely does not fit that model.
I’d love to hear more about how y’all handled building tooling for product dev teams based on integrations.
For integrations with external data sources we made services or applications that pulled and pushed data where the integration point for other teams was consistent and well known. Specifically we pulled and pushed medical data from web, desktop, and JavaScript sources all with different formats, transformed it to the well known format so every team could interact with it using the same data format, and then made it available in a JavaScript API for use in various webpages.
For internal data which was mostly in a form format we had various packages to handle display and interaction with the data in the form and data sources the form required and the webpage could provide. Not all applications could provide all data sources.
Building the tool was creating a standalone form builder that could create reusable versioned forms the applications could use and render. There were client and server side packages to handle the various rendering requirements and data integrations. This really did cut multiple weeks into less than an hour. They were complex forms with considerable data population, validation, show/hide, logic
For different environments the applications either needed to use a service or not. If none did then it was not deployed.
We did have an auditing service that was deployed everywhere that the applications would send data to.
The team I was on needed to use all of the tools we built so we built them as though we would have to fix them.
We had some excellent testers that would try and break everything we did and they verified they still worked in isolation and in realistic environments before they got to prod. I believe we only had 3 prod incidents and they were because temporary fixes were not prioritized to be fixed by decision makers, or a deployment process was not followed by people outside the platform team.
How did we deal with old code? If data version < new code version then use old code. There was a fair bit of version specific logic that needed to be preserved.
Thanks! Were the form builders used to generate mostly internal forms or were they used to generate forms included in the product? If the latter, did you have to limit the different UI/UX variants of how they could appear in the product?
The form builders were used for both internal and external forms.
The customers did not use the form builder - supplied a spec and then a dedicated team handled building it.
The team I was on did not care what was in the forms. We only cared about the functionality in the forms as far as we needed to implement and maintain the various packages and libraries to render the form.
We did have tooling to "release" or promote the forms to the different environments.
The variation to ui was styling which was handled by coordination with the design team so the correct css classes were attached in the correct places.
Any ux provided by the form being rendered was limited only by the form config. I believe we just disallowed some specific complex form input types for certain environments.
My first job was on a platform team. Our main internal product was this sprawling framework for generating APIs and connecting to resources and such. After I left I realized they’d basically just rolled their own web framework that was much shittier than any open source project.
My last project there was to start work on an internal observability system. At my next job they used new relic and I realized that project was just building a terrible New Relic lol
Every time I see a company reinventing the wheel, I chuckle at the thought of ever increasing number of poor engineers that would be banging their head against the wall for years to come.
The fact that people get away with this just shows that we don’t have too few engineers, we have too many. Enough to think we have time to reinvent things instead of using what exists.
It isnt about reinventing the wheel. Many times, it is about consolidation. An org does NOT need 12 different implementation of an API gateway. Same with observability when one team uses Grafana, another use New Relic, and another uses DataDog. Another with Splunk, Nagios. All that adds up cost wise and is ineffecient.
1 or 2 is enough with some standardized governance.
Building tooling so everyone can use one or two consistent, repeatable way is not reinvention.
Wish I wasn't late to this party, I can probably write a book on platform teams.
At my current client I recently wrote a 5-page report on what is going wrong with their platform team and how to fix it.
It makes perfect sense to have central teams with expertise that handle certain cross cutting concern in larger organizations. Deployments, Kubernetes cluster, Logging, etc. It is much more efficient to have everyone use more or less the same stuff instead of having them all invent their wheels poorly.
However, *every* single platform team I have seen was mismanaged and pretty much all made the same mistake: a lack of product thinking.
When you're a platform team, those other developers are basically your *customers* and the customer's opinion, simply, matters more than yours. That doesn't mean you have to follow all of them, but you most certainly should give a lot of weight to these opinions. But platform teams tend to consist of developers who like these technical challenges and generally dislike having to work 'for' other devs, especially if they have different opinions on stuff. So typical mistakes I see:
* Not consulting with the software engineers they do work for on decisions they make.
* Forcing certain tools onto devs from purely a cost perspective
* Forcing certain tools/patterns onto devs from a 'security' perspective
* Ignoring feedback that doesn't align with their view of the platform
* Abstracting away 'complexity' by throwing away all flexibility of the cloud platform you're using.
That's just a few examples which led me to believe that while platform teams can be a benefit, if they are managed poorly they can also be a massive detriment. The client I work for is so big that they have multiple platform teams that are separated in their own silos (kubernetes, CI/CD, messaging, logging) that don't really talk to each other. So secret management, which is a cross-cutting concern within a platform, is so poorly managed we need to move production credentials around by hand.
this is pretty much spot on, I have about 9yoe and about 5 of those have been on mobile native platform teams as engineer.
I hated my previous manager attitude towards dealing with feature teams, he basically wanted to go to war with any proposal made by them instead of working with them to improve our workflows.
Having feature teams as your clients means that you have to prioritize other's DX over hurt feelings.
Some of the responsabilities I've had over the years:
- everything CI/CD related
- Release Management
- Core libs for native (think networking, analytics, navigation, UI components for huge apps)
- Build systems optimizations
- Infra management
- Helping teams automate workflows
- Dealing with rare crashes / bugs that fall through the cracks (this is my favorite part, to get to see very rare issues and understand and fix them)
- monitor key analytics to try to prevent fires
Exactly. It goes completely against the original notion of "DevOps"; putting Dev and Ops together in teams instead of having different silos makes things a lot more efficient.
How the term DevOps got used by managers to make it a generalist job title is one of my biggest pet peeves.
Idunno where you heard managers made it a generalist title, over the past hand full of years I've seen it entirely usurped by IT so ops people get to claim they are devs without any idea how to design or build software. They strong scripts together to automate processes then declare they know how to build software. It'd be adorable if they didn't go around demanding people follow their standards and approaches. They should go back to managing the exchange server imo
> Idunno where you heard managers made it a generalist title, over the past hand full of years I've seen it entirely usurped by IT so ops people get to claim they are devs without any idea how to design or build software.
The one does not exclude the other.
> They should go back to managing the exchange server IMO
IMHO this is quite disrespectful to a lot of ops people.
the only thing I would add is even when platform teams are working well, consulting with developers and trying to earnestly help, they can still cause more issues if they end up accelerating the progress of bad decisions made by technical leadership.
for example, a product team might be assigned with any of the following tasks, which might be things both leadership and developers want. all of these are real examples from my time as a lead of a product team.
* make it easier for dev teams to create new springboot microservices
* add mongodb as a persistence layer option
* introduce the means for a service can fetch from the persistence layer of another service to avoid unnecessary REST calls
* to reduce data permission bugs, create a common authorization system that allows data-level permissioning for any persistence layer
* provide common support for "live" database queries over websockets
however, if any of these things are actually leading the team in the wrong direction, an effecient and motivated platform team can quickly roll out architectural anti-patterns which result in crippling the productivity of the entire software department.
as examples of how the above backfired
* devs create dozens of microservices for every little feature and now the product requires 200GB of memory to run and the average request response time is 5 seconds
* mongodb is quickly & widely adopted. unfortunately, it doesn't support the kinds of joins needed, so now every PUT, PATCH, & DELETE to the application layer is a mess of updating the same data in multiple collections to have everything structured "just so" to get reasonable performance for the various GET requests we're supporting. thousands of hours go into making things work which would come out of the box with an RDBMS for free.
* services can no longer be updated independently. each services persistence layers' schema is effectively public. changes to how data is stored in one service requires tracing out every other service which uses this data and updating them at the same time, and then repeating the process for those services. circular dependencies effectively prevent changes from being possible outright in some cases.
* the common authorization abstraction does not sufficiently meet the performance or feature requirements of all app teams. features available which would allow teams to be successful are sealed off. accessing them requires introducing escape hatches which are more popular than the official interface. data permission bugs proliferate.
* live database queries over websockets crush certain databases. it is complicated to implement. teams attempt to implement it for a long time. eventually, people implement polling to avoid performance concerns. this is deemed good enough for 99% of use-cases. the common abstraction only has 2 or 3 serious clients which each have their own unique performance characteristics. this results in them eventually deciding to implement their own websocket interfaces specialized in their own workloads.
in my opinion, product teams are put in a really hard situation where they are not empowered to decide on the direction, only enable and accelerate what has already been decided. i much prefer a more standard ops / devops team which, in my experience, tend to work more closely with decision-makers early on in the design process.
The most toxic client I worked for had a 'platform architect' without any engineers to build the platform who was incompetent and also a complete asshole (there was a "we don't work with " club, it was that bad).
All he did was get in the way of progress of people with actual experience and engineering skills. One of his ideas (that we killed quickly) was that teams weren't allowed to use databases but everything should be on Kafka.
Yeah we basically told that dude to go pound sand.
Weirdest most unprofessional person I ever worked with. In my very first meeting with him he was basically bullying our solution architect. I told him directly that he was being unprofessional and should use the weekend to reflect on what the heck was going on between the two of them and figure out a way to work together as adults. It was my first time ever doing something this direct.
After I left he was made CTO of the company. Go figure. They're also constantly hiring. Guess why.
Fair question. To me, it's a team that provides a platform for the product teams to build upon. That would involve helping with infrastructure, scalability, observability and similar.
Nah DevOps is narrower, and involves less infra. I've met DevOps engineers who couldn't code at all, only knew how to use UI programs like Jenkins. You could never survive a platforms engineer job like that
DevOps is simply a culture principle where Dev and Ops are in the same team instead of different silo's, which makes communication much better and thus makes teams more efficient.
So you're both wrong and that's a hill I'm going to die on ;)
yeah i’ve heard of “platform” meaning anything from “business logic of the core api that other teams call”, or IT, or local development support, or devops, or what it means at my place which is like app-side scalability (eg owning the code for how the application interacts with database and cloud services).
When I was working on a platform team, it was basically building a self-service in-house AWS with services that developers can shop around and use in a standardize way. A private cloud with a lot of self-service , vetted services.
We basically replicated many cloud-native service with tooling so a dev team can get whatever they need in an automated way. A lot of designing around how to scaffold things. If you ever needed anything, you go to a portal and can auto-provision services your app needs. Need to load test 100 concurrent users via load testing? Service Now, request the feature. Here are your endpoints, keys. And have a go at it.
New hires, needing to run kubernetes locally? Again, here is a repo with all the scaffolding tooling to set up your local environment. Need to run a 4 node cluster in an air-gap environment, pull another repo. Create a ticket to get 4 servers and the IAAS tooling will create your cluster, your own gitlab instance, your own CICD orchestrator for your team.
Basically help teams deliver quicker and more securely. If you came to me with an architecture diagram with needed guard rails, those items could be provisioned to your team's namespace. Like your own vault server. And we provide the code samples or help them wire their node/python/java app to use a FIPS server. And if they needed regulatory compliance, we have tooling that will enable encryption, auditing, and logging for 7 years. By just filling out annotations and variables in their manifest. So they can pass a compliance audit.
That was was meant by building the platform. There was a lot of architecture work on building repeatable tooling in a way that scalfold things ad-hoc and scale. Without developers needed to know simple things like high-load , high transaction load testing. Just follow the framework and IAAS will spin up nodes to DDOS your app and measure your throughput and turn on your monitoring/observability if you needed it too.
It had to be architected in a way, a new hire could build on top of that platform. So we had clearly defined standards and governance on creating new tooling that follow naming/style standards. And services had to be accessible via REST because those developers may want to do their own automation and enable/turn things they need.
It cover very arcane things like ADA as well. Need your app to pass some ADA accessibility compliance? We had a service for that as well. It ran selenium, some commercial ADA testing tool and invoked via annotations in a deployment manifest.
Some CxO/VP had a big budget and wanted AWS in-house. Great learning experience. And this also gave me very positive impression of Nordic country off-shoring. Those engineers from those Nordic/Slavic countries are profoundly good.
I just responded to someone on this thread about being a newbie developer (basically less than 2 years under my belt) and how the platform team made it super easy for me to essentially roll out features on top of their templates and whatever else they provide. When I was a new hire, I didn't need to learn about all those complex layers behind the tools for api development, thank God lol. Nice writeup by the way!
i was hired as an external developer for the new platform team of a big german enterprise.
It was essentially just a way to keep these people busy. Someone up high had budget to spend and liked the idea of a platform team.
It was meant to standardize basically everything within the giant company and educuate other teams. Where the teams range from "kubernet in the cloud" to "manually copy paste this folder via USB (no joke) onto the IIS running on this server".
They also liked the idea of service / product discovery. What even exists within this giant company and how do we make sure someone on team X finds it and can assess whether it makes sense.
I quit after a week. In theory nothing wrong with the idea or approach, but the thought of converting hundreds of developers and products in various stages of competency and legacy to "the platform" sounds horrible.
> Someone up high had budget to spend and liked the idea of a platform team.
SOMETIMES this really sums it up, platform teams arise at times because someone has too much extra time and budget to burn.
I've seen some become an elephant graveyard and where people coast while they get a promotion.
> the idea of service / product discovery.
lmao, can't believe this happens everywhere... the promised land of service and API dictionaries so people know what a specific service does... only for people not to know said dictionary exists and instead book another 1 hour meeting
lmao, your comment hits hard
I remember hearing about service discovery conceptually over a decade ago and thinking it sounded clever but couldn't figure out how it would magically provide whatever services I needed.
Turns out, for God's sake it's just DNS people. Fuck. Everyone needs to stop shopping this promised land magical idea around, it's just fucking DNS. Throw mesh networking in to give the network layer more intelligent configuration if you want, use some message bus pink Floyd bullshit if you want, but it's all so much more than needed in 99.9% of cases to simply say "Gotta go to auth.svc boss, where is it?" Fkn DNS knows.
It is a little bit more than DNS. For microservices in a container workflow, yeah, the automatic DNS registration and propagation is important.
But service discovery can also be full searchable "Developer" storefronts that can search publish APIs.
You build your microservice API, have some annotations, and a standard pathing to an OpenAPI/Swagger spec, it can publish all of that for you. Deploy CICD, the API has full documentation, searchable in a repo, users can register clients that get automatic approval to said APIs. With scoped access. E.G. Some get GET/POST/PUT while others only get GET.
All based on annotation labels in a helm chart or docker-compose. That registers the DNS, publishes the documentation in a e-commerce, shippable, testable way. But I would like to be able shop for an Internal API that has say an inventory lookup. Test the all the HTTP methods within that portal, export the swagger, and register to use both GET/PUT. And have that all auto-provision with my own API gateway protected endpoint because it also provides transformation for legacy apps. And open up the routes for me.
From just filling out variables in your repository.
Every platform team I've worked with ends up writing their own libraries and frameworks, and requires the whole company to use them. Usually their libs are wrappers around open source projects, with defaults supplied which are applicable for your specific company.
While this can speed up development and create a central place to distribute important changes, it also is yet another abstraction layer that devs have to learn. And when devs inevitably need to use a feature of the underlying library that was not exposed in the wrapper, requiring more updates at the wrapper layer.
I think it would be far more enabling for platform teams to share utilities to use alongside the open source frameworks, or plugins to those frameworks, rather than obfuscating wrappers that need constant maintenance.
Not platforms technically front end, but I've seen exactly where you described. Where someone promised the PO that building some common UI library would make the style consistent. They spent like a year building a shitty wrapper around an open source library. They set it up in like 2 of our 8 services , then claim victory and started pressuring other teams to use them. In half our services, they straight up did not work. In the rest, it was blocking all sorts of options in a way that's super overfitted towards the only two services they bothered to test.
Me and several engineers/managers spent months fighting it until it was finally put in the ground
In my role I work on the front end design system, implement backend features, upgrade packages in our monorepo, standardize functions and code, maintain our eslint rules, act as a peer to devs, write documentation, etc. honestly I feel I am just person with an incredible amount of hats.
I was on an architecture team that provided (among other things) platform. We built out templates for different kinds of projects (angular application, bff web apis, core domain services apis, NService bus sagas, [Akka.NET](http://Akka.NET) applications etc.) that had shared plumbing baked in for whatever dependencies were typical of the use case including the terraform scripts to provision those dependencies (like databases, redis caches, Kafka topics, etc.). All the new projects used these templates to bootstrap and could get a shell up and deployed really quickly and then jump right into the business logic.
We also built some specialized libraries for common functionality like Kafka pub/sub with and without streaming, clients/apis for interacting with various third party APIs etc.
We did a lot of other things that were more about architecture than platform as well, but they're not really part of this discussion.
It actually worked out really well because projects ended up relatively independent of each other, ie if there was functionality inside the templates we needed to update, teams could update existing projects on their schedule using the template as a reference and weren't strongly coupled. When we had to make updates to the actual shared libraries like the Kafka support libs, if it was a critical update we'd have to communicate with all the teams to do it but if it was non-critical people could do it at leisure. There was also an added benefit of making it easier for teams to swap members because the structure of their projects was all very similar. They'd need to learn the domain but not how that team structured APIs or service listener projects.
At my current position, we have a lot of nuget packages that all the projects use - not built by a "platform team" but just people on our team, we're a much smaller .NET group - and it has been a complete clusterfuck whenever we need to upgrade version because we end up having to support multiple versions of these libraries when one team needs to upgrade a dependency to get a certain bit of functionality but another team was dependent on the previous version because the later version broke something else and it ends up limiting when we can fully upgrade the dependencies and then the projects that use them.
So... I think a platform team can be good but how they build and manage these resources is really important.
Double edged sword.
Gratifying if succesful, however you never have that satisfaction of delivering direct value to the end customer.
You also need to be extremely effective knowing what to build.
It definitely takes a special kind of person and I personally would never do it again.
To be blunt: what would my ideal platform team look like? Couldn’t care less, im a person focused on delivering value to the end customer
Well I guess it depends what you call platform team, but I've worked in places where the whole workflow to develop an application was guided by a bunch of services. It was very useful. It drastically reduced support for the core developers
This ranged from SDK in a specific language, editor support and CI validation. On top of course of the services required to support these features
Platform teams vary from company to company. On the product side it meant not having to own the whole stack end to end, I could provision a service like Kafka or a sql dB without needing to worry about up time or replication. It reduced our scope and allowed us to focus more on what we actually wanted to deliver.
Currently on a platform team and it's focus is less on the infra but providing shared services that multiple teams might want like a communication service or an logging service but the goal is still the same to reduce the scope that other teams have by owning a shared service that multiple teams can use instead of independently deploying their own solutions
I work on Meta’s intellectual property platform. It’s fun. We get to integrate with all new Meta apps so we now early when something is cooking. We come in, consult on copyright concerns and drive the integration. Couldn’t ask for more.
I've worked on some fun things that were useful (making it super easy for other teams to run Batch jobs with next to no setup work).
I've also seen teams spend years and burn through millions of dollars in salary money to make a platform that got them a bunch of promos and was worse than the previous system.
I worked on a Platform team before. It can mean virtually anything at different companies, but for us it was about creating infrastructure SDK for self-service, automating new service deployment E2E, preparing libraries for devs etc. Definitely challenging.
- Provide CI/CD templates, take care of Cloud infrastructure, Observability systems, Messaging systems, provide general help and support
- You don't need to worry about infrastructure part, you can focus only on delivery.
- Combination of DevOps and Software Engineers.
They maintain shared services, like k8s clusters. They also build templates so we can quickly set up a new API etc. (including upgrading it, which is pretty cool). Then they're responsible for researching these solutions in general, like what is the recommended CICD pipeline, database, secrets rotation policy, etc.
Basically they let us focus more on the application business logic, and less on the problems duplicate across teams.
My ideal team would not reinvent the wheel, they'd leverage existing technology (like AWS for example), unless it makes sense to build something custom/in-house. Then they need to find the right balance on making decisions on their own vs crowdsourcing and accepting feedback. I understand they can't please everyone.
I worked on a data platform team. Built out the tooling for encryption, underlying DB ingestion, monitoring, specialized spark code that would map things to our namespace and abstract away a lot of the spark set up tasks.
Made it easy for our data analysts and data scientists to prep data for processing, and gave some good functionality for the product folks to investigate that data as well.
It was pretty cool stuff. Hard to see the impact any of that had on the end users, but it was obviously making the lives of our developers better.
I realize that I enjoy my job more when customer impact is easy to see… but I might consider moving to a platform team again in the future. But understanding the impact my work has is vital, and I think it can be harder to do that on a platform team.
Much of my career has been as a (usually sole) platform engineer for R&D (mostly computer vision) teams. It's pretty good, since you're not customer-facing in a sense, and you get to see how what you build eases the lives of your colleagues. It is challenging to keep researchers (especially if the manager is more of a researcher than an engineer) focused on what's important in a platform, like reliability, handling tech debt, architecture, etc. since a lot of their work is one-off, and even harder to get additional resources when you're not directly building the product.
ive worked as the lead of a platform team, serving about 60 devs.
i started out application side but then did a bunch of infrastructure work, which made me suitable for the position, as I understood both the development pain-points & the realities of the technologies we were using.
I recruited 3 other developers onto the platform team and we began building and delivering tooling for the remaining teams to simplify typical type ops work; creating new services, leveraging infrastructure, building, releasing and deploying code, setting up nightly build & test suites & creating and running unit tests, integration tests, and e2e tests, as well as test automation for our QA team.
we worked with typical devops tools, but often also worked at the code level if we thought of a library which would simplify common work across all teams. we did not manage anything like backstage.
while we did deliver on these things, in the end I disbanded the team and went back product side.
the problem platform teams end up in is they are way too far down the supply-chain to fix core issues. like "should we even be doing this" type issues. platform teams can easily end up laying down grease on the road to nowhere, and they often don't have the power to change direction.
in our case, we simplified creating new backend services. this massively backfired as the application teams built way too many small services which were very coupled. this resulted in complex and expensive operations in production, in debugging issues, in releasing, in testing.
we inadvertently created way more work for everyone by making something easier that never should have been done in the first place.
I think this is the ultimate trap platform teams end up in:
\* being a good platform team, we ask our developers, "what do you need?"
\* developers say "making new services is complicated"; so we simplify it
\* developers make many more services
\* complexity explosion
\* now developer are saying everything is too hard and there's endless platform work
\* we run around and try and figure out how to take all of these polyrepos and create some semblance of a release artifact from them and get them to prod without causing cascading failures
disillusioned with platform work, I moved into a position where I could say "no, you may not create more services". I felt my impact was infinitely larger than when I was automating work as platform team lead, because I could eliminate both the need for the work and the need for the automation of the work.
overall while i support having a small team who can focus on infrastructure related concerns, I don't like the concept of a "platform team" as I think it can easily lead to situations where the wrong things are accelerated.
To me, they're really intelligent. Architecting infrastructure for us developers because our main focus is the customer product, not infra. They help us deliver by already having jobs set and configured for us so we dont have to manage it ourselves and when we do upgrades we move along together. Like having good tools to use and test while I build out a functionality.
Down votes would input that that's not the case?
Would it be more accurate to say that their good at knowing ins and outs of programming(languages, trade offs, scaling etc.) and different architectures and best ways to put things together so that the system as a whole works better together?
Maybe someone could elaborate?
Maybe I misread the question of OP asking Platform engineers about them as oppose to how I feel about Platform engineers? Or maybe no one likes my response :(.
Either way, in my opinion, the platform team I interact with is super chill. Young and old, busting out dad jokes, and very knowledgeable in various programming languages and cloud architecture. I've only interacted with some for about a year now. They've got a lot of knowledge in infrastructure, gitlab, aws, programming, I mean you name it and they know. Every time I interact with them, they enjoy explaining the processes and walking me through their code or giving me basics in api development. It could be that it's my company culture too that it's like that lol cause from what I'm reading, it seems that many people either hate or love them.
I'm just a newbie back end developer and when working on some repo's, I collaborated with a few platform engineers in choosing a template appropriate for my repo for api deployments. I was working on a repo with a lot of old code written by previous contractors and instead of rewriting the jobs to my pipeline to cover some scanning scenarios, they already had a .yml template that came with all standard scans such as fuzz, dast, etc. I didn't have to individually define my env because I could set it and other variables all in the global variables and then enable or disable some of the jobs including linting, destroy jobs, logging status of all scans, deployments across route 53 if I needed that, deployment to aws regions, and so much more. If a job wasn't up to my liking, I could just disable it and plug in my own job inside it. To me in my eyes, it is a very easy template that I don't have to manage at all except on a bare minimum level.
In my experience it’s almost always nothing like what you describe though. A large group of multiple orgs who always want to break standards and ask for money and resources when they do. Sure. It’s a deficit of the 3+’companies I’ve experienced it
With - but the point is the nomenclature is so vague that it means nothing on its own.
Any time there was an issue say it was a product problem. Then Any time there was a platform issue they had agreed was platform - they would say “we need more money to support that. Until then it’s “product” despite having a staff and org so large they already took half our budget. Is that what you want to know? Does that help you???? Is this a shell game of responsibility that ends up with the same (but diminished) people owning the same shit they always did but at a higher amount of pressure?
Oh also we can’t backfill. Because of all the work that platform is now helping us with.
Favorite conversation: dba’s are now platform.
“Great! I’m on board they know best the maintenance and administration of databases. Now I need to hire developers that can work on some upcoming database changes!”
“No you can’t hire that. Dbas are platform.”
… so dbas aren’t going to work on application code or data models. Got a lot of middleware people. But dbas just want the install scripts. So now we’re down to one person planning all ddl changes for 20 stories for the next couple weeks. Seems like I have two groups profiting as long as we keep minimal resources putting in 60 hour weeks. Thanks all.
Avoid at all cost unless you are desperate for a job.
I have completely fucked up my career going down the "DevOps" and "Platform team" route.
It used to mean something and be valued on a team but anymore it is just IT work with a bunch of scripting.
It is below software engineering and hard to get back onto the programmer track.
I'm a platform engineer for a large enterprise and my entire job is to write custom kubernetes operators for orchestrating thousands of deployments.
I don't know if I'd call that scripting
Count your blessings IT hasn't come for you yet. They've been usurping these departments across the industry in recent years. Management doesn't know any different and there's tons of literature out there on platforms now and how it's super valuable and important and it's entirely operations work, bash and python scripts strung together being the closest they get to writing code
What is this comment saying lol.
I'm saying platforms at scale is not stringing scripts together, our backstage instance alone has 8 web devs dedicated to it.
I'm saying your platform team hasn't been brought under IT yet where it becomes all about standing up and configuring enterprise applications rather than writing software - you're writing software, but many of these teams are now just operations teams proclaiming to be dev and ops
We are in the infrastructure/operations org.
We run over 1000 services from 200+ teams, we definitely have a ton of ops work to support our scale but it's driven by an insistence on self service and automation.
I've actually been on a platform team before We did a few different things: - created shareable independently deployable services and libraries other teams could use for their products - had our own products that could be deployed to customers (internal and external) - trialed newer versions of frameworks and tooling - helped with integration of other teams products and our products, services, and libraries - worked on technical processes for deploying different products with clashing dependencies to a limited environment Were we perfect? No. Did we make mistakes? Many. Did we improve the development experience for other teams? I think so. We did remove a few large workloads by replacing the need for more devs with a toolimg that turned 2 weeks of work into 30 minutes for a non technical person. (Form building tool - very complex and non standard).
Can you discuss more about your work to help with integrations? Our team, which handles billing, has gradually been establishing ourselves as more of a platform team in the recent past. It feels like we’re on the same page between product and engineering about how our team should focus on billing workflows and leave features access to product dev teams. Of course, there’s a bunch of old code that definitely does not fit that model. I’d love to hear more about how y’all handled building tooling for product dev teams based on integrations.
For integrations with external data sources we made services or applications that pulled and pushed data where the integration point for other teams was consistent and well known. Specifically we pulled and pushed medical data from web, desktop, and JavaScript sources all with different formats, transformed it to the well known format so every team could interact with it using the same data format, and then made it available in a JavaScript API for use in various webpages. For internal data which was mostly in a form format we had various packages to handle display and interaction with the data in the form and data sources the form required and the webpage could provide. Not all applications could provide all data sources. Building the tool was creating a standalone form builder that could create reusable versioned forms the applications could use and render. There were client and server side packages to handle the various rendering requirements and data integrations. This really did cut multiple weeks into less than an hour. They were complex forms with considerable data population, validation, show/hide, logic For different environments the applications either needed to use a service or not. If none did then it was not deployed. We did have an auditing service that was deployed everywhere that the applications would send data to. The team I was on needed to use all of the tools we built so we built them as though we would have to fix them. We had some excellent testers that would try and break everything we did and they verified they still worked in isolation and in realistic environments before they got to prod. I believe we only had 3 prod incidents and they were because temporary fixes were not prioritized to be fixed by decision makers, or a deployment process was not followed by people outside the platform team. How did we deal with old code? If data version < new code version then use old code. There was a fair bit of version specific logic that needed to be preserved.
Thanks! Were the form builders used to generate mostly internal forms or were they used to generate forms included in the product? If the latter, did you have to limit the different UI/UX variants of how they could appear in the product?
The form builders were used for both internal and external forms. The customers did not use the form builder - supplied a spec and then a dedicated team handled building it. The team I was on did not care what was in the forms. We only cared about the functionality in the forms as far as we needed to implement and maintain the various packages and libraries to render the form. We did have tooling to "release" or promote the forms to the different environments. The variation to ui was styling which was handled by coordination with the design team so the correct css classes were attached in the correct places. Any ux provided by the form being rendered was limited only by the form config. I believe we just disallowed some specific complex form input types for certain environments.
My first job was on a platform team. Our main internal product was this sprawling framework for generating APIs and connecting to resources and such. After I left I realized they’d basically just rolled their own web framework that was much shittier than any open source project. My last project there was to start work on an internal observability system. At my next job they used new relic and I realized that project was just building a terrible New Relic lol
Every time I see a company reinventing the wheel, I chuckle at the thought of ever increasing number of poor engineers that would be banging their head against the wall for years to come.
The fact that people get away with this just shows that we don’t have too few engineers, we have too many. Enough to think we have time to reinvent things instead of using what exists.
There's a second problem here though where SaaS companies are jacking up their prices considerably
Who have too few who can do it *well*.
It isnt about reinventing the wheel. Many times, it is about consolidation. An org does NOT need 12 different implementation of an API gateway. Same with observability when one team uses Grafana, another use New Relic, and another uses DataDog. Another with Splunk, Nagios. All that adds up cost wise and is ineffecient. 1 or 2 is enough with some standardized governance. Building tooling so everyone can use one or two consistent, repeatable way is not reinvention.
Wish I wasn't late to this party, I can probably write a book on platform teams. At my current client I recently wrote a 5-page report on what is going wrong with their platform team and how to fix it. It makes perfect sense to have central teams with expertise that handle certain cross cutting concern in larger organizations. Deployments, Kubernetes cluster, Logging, etc. It is much more efficient to have everyone use more or less the same stuff instead of having them all invent their wheels poorly. However, *every* single platform team I have seen was mismanaged and pretty much all made the same mistake: a lack of product thinking. When you're a platform team, those other developers are basically your *customers* and the customer's opinion, simply, matters more than yours. That doesn't mean you have to follow all of them, but you most certainly should give a lot of weight to these opinions. But platform teams tend to consist of developers who like these technical challenges and generally dislike having to work 'for' other devs, especially if they have different opinions on stuff. So typical mistakes I see: * Not consulting with the software engineers they do work for on decisions they make. * Forcing certain tools onto devs from purely a cost perspective * Forcing certain tools/patterns onto devs from a 'security' perspective * Ignoring feedback that doesn't align with their view of the platform * Abstracting away 'complexity' by throwing away all flexibility of the cloud platform you're using. That's just a few examples which led me to believe that while platform teams can be a benefit, if they are managed poorly they can also be a massive detriment. The client I work for is so big that they have multiple platform teams that are separated in their own silos (kubernetes, CI/CD, messaging, logging) that don't really talk to each other. So secret management, which is a cross-cutting concern within a platform, is so poorly managed we need to move production credentials around by hand.
this is pretty much spot on, I have about 9yoe and about 5 of those have been on mobile native platform teams as engineer. I hated my previous manager attitude towards dealing with feature teams, he basically wanted to go to war with any proposal made by them instead of working with them to improve our workflows. Having feature teams as your clients means that you have to prioritize other's DX over hurt feelings. Some of the responsabilities I've had over the years: - everything CI/CD related - Release Management - Core libs for native (think networking, analytics, navigation, UI components for huge apps) - Build systems optimizations - Infra management - Helping teams automate workflows - Dealing with rare crashes / bugs that fall through the cracks (this is my favorite part, to get to see very rare issues and understand and fix them) - monitor key analytics to try to prevent fires
Exactly. It goes completely against the original notion of "DevOps"; putting Dev and Ops together in teams instead of having different silos makes things a lot more efficient. How the term DevOps got used by managers to make it a generalist job title is one of my biggest pet peeves.
Idunno where you heard managers made it a generalist title, over the past hand full of years I've seen it entirely usurped by IT so ops people get to claim they are devs without any idea how to design or build software. They strong scripts together to automate processes then declare they know how to build software. It'd be adorable if they didn't go around demanding people follow their standards and approaches. They should go back to managing the exchange server imo
> Idunno where you heard managers made it a generalist title, over the past hand full of years I've seen it entirely usurped by IT so ops people get to claim they are devs without any idea how to design or build software. The one does not exclude the other. > They should go back to managing the exchange server IMO IMHO this is quite disrespectful to a lot of ops people.
the only thing I would add is even when platform teams are working well, consulting with developers and trying to earnestly help, they can still cause more issues if they end up accelerating the progress of bad decisions made by technical leadership. for example, a product team might be assigned with any of the following tasks, which might be things both leadership and developers want. all of these are real examples from my time as a lead of a product team. * make it easier for dev teams to create new springboot microservices * add mongodb as a persistence layer option * introduce the means for a service can fetch from the persistence layer of another service to avoid unnecessary REST calls * to reduce data permission bugs, create a common authorization system that allows data-level permissioning for any persistence layer * provide common support for "live" database queries over websockets however, if any of these things are actually leading the team in the wrong direction, an effecient and motivated platform team can quickly roll out architectural anti-patterns which result in crippling the productivity of the entire software department. as examples of how the above backfired * devs create dozens of microservices for every little feature and now the product requires 200GB of memory to run and the average request response time is 5 seconds * mongodb is quickly & widely adopted. unfortunately, it doesn't support the kinds of joins needed, so now every PUT, PATCH, & DELETE to the application layer is a mess of updating the same data in multiple collections to have everything structured "just so" to get reasonable performance for the various GET requests we're supporting. thousands of hours go into making things work which would come out of the box with an RDBMS for free. * services can no longer be updated independently. each services persistence layers' schema is effectively public. changes to how data is stored in one service requires tracing out every other service which uses this data and updating them at the same time, and then repeating the process for those services. circular dependencies effectively prevent changes from being possible outright in some cases. * the common authorization abstraction does not sufficiently meet the performance or feature requirements of all app teams. features available which would allow teams to be successful are sealed off. accessing them requires introducing escape hatches which are more popular than the official interface. data permission bugs proliferate. * live database queries over websockets crush certain databases. it is complicated to implement. teams attempt to implement it for a long time. eventually, people implement polling to avoid performance concerns. this is deemed good enough for 99% of use-cases. the common abstraction only has 2 or 3 serious clients which each have their own unique performance characteristics. this results in them eventually deciding to implement their own websocket interfaces specialized in their own workloads. in my opinion, product teams are put in a really hard situation where they are not empowered to decide on the direction, only enable and accelerate what has already been decided. i much prefer a more standard ops / devops team which, in my experience, tend to work more closely with decision-makers early on in the design process.
What is the “platform team”? This literally could mean anything depending on the company.
At my company, it is two burned out dev ops guys and then four directors with “great ideas”.
The most toxic client I worked for had a 'platform architect' without any engineers to build the platform who was incompetent and also a complete asshole (there was a "we don't work with" club, it was that bad).
All he did was get in the way of progress of people with actual experience and engineering skills. One of his ideas (that we killed quickly) was that teams weren't allowed to use databases but everything should be on Kafka.
Didn’t you know, events scale but databases don’t! /s
I think they read a blog on event sourcing they didn't understand ;)
Types of databases or just databases in general?
In general. They read some "turning the database inside out" nonsense and felt that Kafka was the only database we should ever use.
oof
Yeah we basically told that dude to go pound sand. Weirdest most unprofessional person I ever worked with. In my very first meeting with him he was basically bullying our solution architect. I told him directly that he was being unprofessional and should use the weekend to reflect on what the heck was going on between the two of them and figure out a way to work together as adults. It was my first time ever doing something this direct. After I left he was made CTO of the company. Go figure. They're also constantly hiring. Guess why.
Fair question. To me, it's a team that provides a platform for the product teams to build upon. That would involve helping with infrastructure, scalability, observability and similar.
We call that devops
Nah DevOps is narrower, and involves less infra. I've met DevOps engineers who couldn't code at all, only knew how to use UI programs like Jenkins. You could never survive a platforms engineer job like that
DevOps is simply a culture principle where Dev and Ops are in the same team instead of different silo's, which makes communication much better and thus makes teams more efficient. So you're both wrong and that's a hill I'm going to die on ;)
your definition of devops is to "devops" as the agile manifestos is to "agile" :p
In some textbook, yeah. but in practice that's not really what it ends up being
yeah i’ve heard of “platform” meaning anything from “business logic of the core api that other teams call”, or IT, or local development support, or devops, or what it means at my place which is like app-side scalability (eg owning the code for how the application interacts with database and cloud services).
That’s literally what they are asking
When I was working on a platform team, it was basically building a self-service in-house AWS with services that developers can shop around and use in a standardize way. A private cloud with a lot of self-service , vetted services. We basically replicated many cloud-native service with tooling so a dev team can get whatever they need in an automated way. A lot of designing around how to scaffold things. If you ever needed anything, you go to a portal and can auto-provision services your app needs. Need to load test 100 concurrent users via load testing? Service Now, request the feature. Here are your endpoints, keys. And have a go at it. New hires, needing to run kubernetes locally? Again, here is a repo with all the scaffolding tooling to set up your local environment. Need to run a 4 node cluster in an air-gap environment, pull another repo. Create a ticket to get 4 servers and the IAAS tooling will create your cluster, your own gitlab instance, your own CICD orchestrator for your team. Basically help teams deliver quicker and more securely. If you came to me with an architecture diagram with needed guard rails, those items could be provisioned to your team's namespace. Like your own vault server. And we provide the code samples or help them wire their node/python/java app to use a FIPS server. And if they needed regulatory compliance, we have tooling that will enable encryption, auditing, and logging for 7 years. By just filling out annotations and variables in their manifest. So they can pass a compliance audit. That was was meant by building the platform. There was a lot of architecture work on building repeatable tooling in a way that scalfold things ad-hoc and scale. Without developers needed to know simple things like high-load , high transaction load testing. Just follow the framework and IAAS will spin up nodes to DDOS your app and measure your throughput and turn on your monitoring/observability if you needed it too. It had to be architected in a way, a new hire could build on top of that platform. So we had clearly defined standards and governance on creating new tooling that follow naming/style standards. And services had to be accessible via REST because those developers may want to do their own automation and enable/turn things they need. It cover very arcane things like ADA as well. Need your app to pass some ADA accessibility compliance? We had a service for that as well. It ran selenium, some commercial ADA testing tool and invoked via annotations in a deployment manifest. Some CxO/VP had a big budget and wanted AWS in-house. Great learning experience. And this also gave me very positive impression of Nordic country off-shoring. Those engineers from those Nordic/Slavic countries are profoundly good.
I just responded to someone on this thread about being a newbie developer (basically less than 2 years under my belt) and how the platform team made it super easy for me to essentially roll out features on top of their templates and whatever else they provide. When I was a new hire, I didn't need to learn about all those complex layers behind the tools for api development, thank God lol. Nice writeup by the way!
i was hired as an external developer for the new platform team of a big german enterprise. It was essentially just a way to keep these people busy. Someone up high had budget to spend and liked the idea of a platform team. It was meant to standardize basically everything within the giant company and educuate other teams. Where the teams range from "kubernet in the cloud" to "manually copy paste this folder via USB (no joke) onto the IIS running on this server". They also liked the idea of service / product discovery. What even exists within this giant company and how do we make sure someone on team X finds it and can assess whether it makes sense. I quit after a week. In theory nothing wrong with the idea or approach, but the thought of converting hundreds of developers and products in various stages of competency and legacy to "the platform" sounds horrible.
> Someone up high had budget to spend and liked the idea of a platform team. SOMETIMES this really sums it up, platform teams arise at times because someone has too much extra time and budget to burn. I've seen some become an elephant graveyard and where people coast while they get a promotion. > the idea of service / product discovery. lmao, can't believe this happens everywhere... the promised land of service and API dictionaries so people know what a specific service does... only for people not to know said dictionary exists and instead book another 1 hour meeting lmao, your comment hits hard
I remember hearing about service discovery conceptually over a decade ago and thinking it sounded clever but couldn't figure out how it would magically provide whatever services I needed. Turns out, for God's sake it's just DNS people. Fuck. Everyone needs to stop shopping this promised land magical idea around, it's just fucking DNS. Throw mesh networking in to give the network layer more intelligent configuration if you want, use some message bus pink Floyd bullshit if you want, but it's all so much more than needed in 99.9% of cases to simply say "Gotta go to auth.svc boss, where is it?" Fkn DNS knows.
It is a little bit more than DNS. For microservices in a container workflow, yeah, the automatic DNS registration and propagation is important. But service discovery can also be full searchable "Developer" storefronts that can search publish APIs. You build your microservice API, have some annotations, and a standard pathing to an OpenAPI/Swagger spec, it can publish all of that for you. Deploy CICD, the API has full documentation, searchable in a repo, users can register clients that get automatic approval to said APIs. With scoped access. E.G. Some get GET/POST/PUT while others only get GET. All based on annotation labels in a helm chart or docker-compose. That registers the DNS, publishes the documentation in a e-commerce, shippable, testable way. But I would like to be able shop for an Internal API that has say an inventory lookup. Test the all the HTTP methods within that portal, export the swagger, and register to use both GET/PUT. And have that all auto-provision with my own API gateway protected endpoint because it also provides transformation for legacy apps. And open up the routes for me. From just filling out variables in your repository.
Every platform team I've worked with ends up writing their own libraries and frameworks, and requires the whole company to use them. Usually their libs are wrappers around open source projects, with defaults supplied which are applicable for your specific company. While this can speed up development and create a central place to distribute important changes, it also is yet another abstraction layer that devs have to learn. And when devs inevitably need to use a feature of the underlying library that was not exposed in the wrapper, requiring more updates at the wrapper layer. I think it would be far more enabling for platform teams to share utilities to use alongside the open source frameworks, or plugins to those frameworks, rather than obfuscating wrappers that need constant maintenance.
Not platforms technically front end, but I've seen exactly where you described. Where someone promised the PO that building some common UI library would make the style consistent. They spent like a year building a shitty wrapper around an open source library. They set it up in like 2 of our 8 services , then claim victory and started pressuring other teams to use them. In half our services, they straight up did not work. In the rest, it was blocking all sorts of options in a way that's super overfitted towards the only two services they bothered to test. Me and several engineers/managers spent months fighting it until it was finally put in the ground
In my role I work on the front end design system, implement backend features, upgrade packages in our monorepo, standardize functions and code, maintain our eslint rules, act as a peer to devs, write documentation, etc. honestly I feel I am just person with an incredible amount of hats.
I was on an architecture team that provided (among other things) platform. We built out templates for different kinds of projects (angular application, bff web apis, core domain services apis, NService bus sagas, [Akka.NET](http://Akka.NET) applications etc.) that had shared plumbing baked in for whatever dependencies were typical of the use case including the terraform scripts to provision those dependencies (like databases, redis caches, Kafka topics, etc.). All the new projects used these templates to bootstrap and could get a shell up and deployed really quickly and then jump right into the business logic. We also built some specialized libraries for common functionality like Kafka pub/sub with and without streaming, clients/apis for interacting with various third party APIs etc. We did a lot of other things that were more about architecture than platform as well, but they're not really part of this discussion. It actually worked out really well because projects ended up relatively independent of each other, ie if there was functionality inside the templates we needed to update, teams could update existing projects on their schedule using the template as a reference and weren't strongly coupled. When we had to make updates to the actual shared libraries like the Kafka support libs, if it was a critical update we'd have to communicate with all the teams to do it but if it was non-critical people could do it at leisure. There was also an added benefit of making it easier for teams to swap members because the structure of their projects was all very similar. They'd need to learn the domain but not how that team structured APIs or service listener projects. At my current position, we have a lot of nuget packages that all the projects use - not built by a "platform team" but just people on our team, we're a much smaller .NET group - and it has been a complete clusterfuck whenever we need to upgrade version because we end up having to support multiple versions of these libraries when one team needs to upgrade a dependency to get a certain bit of functionality but another team was dependent on the previous version because the later version broke something else and it ends up limiting when we can fully upgrade the dependencies and then the projects that use them. So... I think a platform team can be good but how they build and manage these resources is really important.
That term seems too broad to mean the same thing for most people
Double edged sword. Gratifying if succesful, however you never have that satisfaction of delivering direct value to the end customer. You also need to be extremely effective knowing what to build. It definitely takes a special kind of person and I personally would never do it again. To be blunt: what would my ideal platform team look like? Couldn’t care less, im a person focused on delivering value to the end customer
Well I guess it depends what you call platform team, but I've worked in places where the whole workflow to develop an application was guided by a bunch of services. It was very useful. It drastically reduced support for the core developers This ranged from SDK in a specific language, editor support and CI validation. On top of course of the services required to support these features
Platform teams vary from company to company. On the product side it meant not having to own the whole stack end to end, I could provision a service like Kafka or a sql dB without needing to worry about up time or replication. It reduced our scope and allowed us to focus more on what we actually wanted to deliver. Currently on a platform team and it's focus is less on the infra but providing shared services that multiple teams might want like a communication service or an logging service but the goal is still the same to reduce the scope that other teams have by owning a shared service that multiple teams can use instead of independently deploying their own solutions
I work on Meta’s intellectual property platform. It’s fun. We get to integrate with all new Meta apps so we now early when something is cooking. We come in, consult on copyright concerns and drive the integration. Couldn’t ask for more.
I've worked on some fun things that were useful (making it super easy for other teams to run Batch jobs with next to no setup work). I've also seen teams spend years and burn through millions of dollars in salary money to make a platform that got them a bunch of promos and was worse than the previous system.
I worked on a Platform team before. It can mean virtually anything at different companies, but for us it was about creating infrastructure SDK for self-service, automating new service deployment E2E, preparing libraries for devs etc. Definitely challenging.
- Provide CI/CD templates, take care of Cloud infrastructure, Observability systems, Messaging systems, provide general help and support - You don't need to worry about infrastructure part, you can focus only on delivery. - Combination of DevOps and Software Engineers.
They maintain shared services, like k8s clusters. They also build templates so we can quickly set up a new API etc. (including upgrading it, which is pretty cool). Then they're responsible for researching these solutions in general, like what is the recommended CICD pipeline, database, secrets rotation policy, etc. Basically they let us focus more on the application business logic, and less on the problems duplicate across teams. My ideal team would not reinvent the wheel, they'd leverage existing technology (like AWS for example), unless it makes sense to build something custom/in-house. Then they need to find the right balance on making decisions on their own vs crowdsourcing and accepting feedback. I understand they can't please everyone.
I worked on a data platform team. Built out the tooling for encryption, underlying DB ingestion, monitoring, specialized spark code that would map things to our namespace and abstract away a lot of the spark set up tasks. Made it easy for our data analysts and data scientists to prep data for processing, and gave some good functionality for the product folks to investigate that data as well. It was pretty cool stuff. Hard to see the impact any of that had on the end users, but it was obviously making the lives of our developers better. I realize that I enjoy my job more when customer impact is easy to see… but I might consider moving to a platform team again in the future. But understanding the impact my work has is vital, and I think it can be harder to do that on a platform team.
Much of my career has been as a (usually sole) platform engineer for R&D (mostly computer vision) teams. It's pretty good, since you're not customer-facing in a sense, and you get to see how what you build eases the lives of your colleagues. It is challenging to keep researchers (especially if the manager is more of a researcher than an engineer) focused on what's important in a platform, like reliability, handling tech debt, architecture, etc. since a lot of their work is one-off, and even harder to get additional resources when you're not directly building the product.
ive worked as the lead of a platform team, serving about 60 devs. i started out application side but then did a bunch of infrastructure work, which made me suitable for the position, as I understood both the development pain-points & the realities of the technologies we were using. I recruited 3 other developers onto the platform team and we began building and delivering tooling for the remaining teams to simplify typical type ops work; creating new services, leveraging infrastructure, building, releasing and deploying code, setting up nightly build & test suites & creating and running unit tests, integration tests, and e2e tests, as well as test automation for our QA team. we worked with typical devops tools, but often also worked at the code level if we thought of a library which would simplify common work across all teams. we did not manage anything like backstage. while we did deliver on these things, in the end I disbanded the team and went back product side. the problem platform teams end up in is they are way too far down the supply-chain to fix core issues. like "should we even be doing this" type issues. platform teams can easily end up laying down grease on the road to nowhere, and they often don't have the power to change direction. in our case, we simplified creating new backend services. this massively backfired as the application teams built way too many small services which were very coupled. this resulted in complex and expensive operations in production, in debugging issues, in releasing, in testing. we inadvertently created way more work for everyone by making something easier that never should have been done in the first place. I think this is the ultimate trap platform teams end up in: \* being a good platform team, we ask our developers, "what do you need?" \* developers say "making new services is complicated"; so we simplify it \* developers make many more services \* complexity explosion \* now developer are saying everything is too hard and there's endless platform work \* we run around and try and figure out how to take all of these polyrepos and create some semblance of a release artifact from them and get them to prod without causing cascading failures disillusioned with platform work, I moved into a position where I could say "no, you may not create more services". I felt my impact was infinitely larger than when I was automating work as platform team lead, because I could eliminate both the need for the work and the need for the automation of the work. overall while i support having a small team who can focus on infrastructure related concerns, I don't like the concept of a "platform team" as I think it can easily lead to situations where the wrong things are accelerated.
To me, they're really intelligent. Architecting infrastructure for us developers because our main focus is the customer product, not infra. They help us deliver by already having jobs set and configured for us so we dont have to manage it ourselves and when we do upgrades we move along together. Like having good tools to use and test while I build out a functionality.
Down votes would input that that's not the case? Would it be more accurate to say that their good at knowing ins and outs of programming(languages, trade offs, scaling etc.) and different architectures and best ways to put things together so that the system as a whole works better together? Maybe someone could elaborate?
Maybe I misread the question of OP asking Platform engineers about them as oppose to how I feel about Platform engineers? Or maybe no one likes my response :(. Either way, in my opinion, the platform team I interact with is super chill. Young and old, busting out dad jokes, and very knowledgeable in various programming languages and cloud architecture. I've only interacted with some for about a year now. They've got a lot of knowledge in infrastructure, gitlab, aws, programming, I mean you name it and they know. Every time I interact with them, they enjoy explaining the processes and walking me through their code or giving me basics in api development. It could be that it's my company culture too that it's like that lol cause from what I'm reading, it seems that many people either hate or love them. I'm just a newbie back end developer and when working on some repo's, I collaborated with a few platform engineers in choosing a template appropriate for my repo for api deployments. I was working on a repo with a lot of old code written by previous contractors and instead of rewriting the jobs to my pipeline to cover some scanning scenarios, they already had a .yml template that came with all standard scans such as fuzz, dast, etc. I didn't have to individually define my env because I could set it and other variables all in the global variables and then enable or disable some of the jobs including linting, destroy jobs, logging status of all scans, deployments across route 53 if I needed that, deployment to aws regions, and so much more. If a job wasn't up to my liking, I could just disable it and plug in my own job inside it. To me in my eyes, it is a very easy template that I don't have to manage at all except on a bare minimum level.
In my experience it’s almost always nothing like what you describe though. A large group of multiple orgs who always want to break standards and ask for money and resources when they do. Sure. It’s a deficit of the 3+’companies I’ve experienced it With - but the point is the nomenclature is so vague that it means nothing on its own.
Im blessed to be working in a good company 🙏 ... until otherwise. Can i hear more horror stories from you? Lol
Any time there was an issue say it was a product problem. Then Any time there was a platform issue they had agreed was platform - they would say “we need more money to support that. Until then it’s “product” despite having a staff and org so large they already took half our budget. Is that what you want to know? Does that help you???? Is this a shell game of responsibility that ends up with the same (but diminished) people owning the same shit they always did but at a higher amount of pressure? Oh also we can’t backfill. Because of all the work that platform is now helping us with. Favorite conversation: dba’s are now platform. “Great! I’m on board they know best the maintenance and administration of databases. Now I need to hire developers that can work on some upcoming database changes!” “No you can’t hire that. Dbas are platform.” … so dbas aren’t going to work on application code or data models. Got a lot of middleware people. But dbas just want the install scripts. So now we’re down to one person planning all ddl changes for 20 stories for the next couple weeks. Seems like I have two groups profiting as long as we keep minimal resources putting in 60 hour weeks. Thanks all.
Avoid at all cost unless you are desperate for a job. I have completely fucked up my career going down the "DevOps" and "Platform team" route. It used to mean something and be valued on a team but anymore it is just IT work with a bunch of scripting. It is below software engineering and hard to get back onto the programmer track.
I'm a platform engineer for a large enterprise and my entire job is to write custom kubernetes operators for orchestrating thousands of deployments. I don't know if I'd call that scripting
Count your blessings IT hasn't come for you yet. They've been usurping these departments across the industry in recent years. Management doesn't know any different and there's tons of literature out there on platforms now and how it's super valuable and important and it's entirely operations work, bash and python scripts strung together being the closest they get to writing code
What is this comment saying lol. I'm saying platforms at scale is not stringing scripts together, our backstage instance alone has 8 web devs dedicated to it.
I'm saying your platform team hasn't been brought under IT yet where it becomes all about standing up and configuring enterprise applications rather than writing software - you're writing software, but many of these teams are now just operations teams proclaiming to be dev and ops
We are in the infrastructure/operations org. We run over 1000 services from 200+ teams, we definitely have a ton of ops work to support our scale but it's driven by an insistence on self service and automation.
it’s just product infra that create a wrapper around core infra to fit that specific products. pretty lame imo