ok I know there are a lot of #DevOps #SRE and #FrontEnd people on here these days so I'm hoping that I get a few good answers around this:
What do you call a team that is focused on the web side of the platform? My team is focused on the meta structure of a large web app and responsible for the overall "web platform" (how it builds, perf, monitoring) choices.
We're definitely not the SRE team, but we're also not a traditional product team. What would you call us?
@mahmoudajawad I have purposely not shared what we call ourselves named us because I don't want to bias any answers but I can share that I lovingly refer to us as "Team Platypus" 😄
@mcneely I see what you did there 😄
@mcneely web platform team sounds appropriate to me
@mcneely This is a good question. Our front-end team is normally distinguished as being the App Developers (as opposed to the Infra team)
@mcneely Why do you think it's not SRE?
@MALPI we think in JavaScript not Go 😉
We have a separate SRE team who manages K8s and does all of the things that are traditionally associated with SRE work.
@mcneely I think it shouldn't be a matter of the Language you are using. I would consider the team that is managing #kubernetes a platform team. Whereas you are maintaining your product. But there is nothing that speaks against having embedded #SRE within the Teams or?
@MALPI yes that was exactly what I had said about #kubernetes. If we aren't managing it feels wrong to call us a platform team. It's a large product so there's a bunch of teams all doing their own thing. We're like the "meta" product team.
There are no SREs embedded with us but organizationally were with the SREs not the other product teams (I think). So we get a lot of crossover work with them just to keep things confusing 😁
@mcneely @MALPI of course, if your product management does a good job prioritizing reliability projects (including refactoring, tech debt reduction, toil automation) over new features for customers, then yes, this conflict probably doesn't exist. But more commonly it's product management's job not to do this. And in those cases it helps reliability if SREs are a separate, independent organization, working very closely with the product team but ultimately pursuing different goals.
@mcneely if it's "web based" does that mean it's hosted on cloud resources? It would be cloud engineering if you're in charge of managing what resources are used and how they are deployed for the web service. But if you are more about app deployment lifecycle you could just say you're web DevOps. Or if you're responsible for a specific backend or frontend service, that's probably your team. If you do it all, then you're some type of convoluted hybrid... Like a platypus
@marcus_thesmith so far the only clear line that I can really articulate is that we don't touch anything after the BFF (Backend for FrontEnd). I guess thinking about it we're responsible for all the public resources that users interact with.
We are not "really" responsible for the hosting or deployment per se but we do manage those build processes that create the deployed artifacts.
@mcneely interesting one. Replying to follow answers.