This message was deleted.

Missing from the list is also overall ownership of the AWS (or other cloud provider) account, tag taxonomy, IAM permissions, etc

yeah, that sounds about right.

In my current very small org, we also have API Platform that takes provides the API tooling, styleguides, governance, etc. for both internal and external communication

In addition to what was laid out in previous responses, we also have a team dedicated to our backstage & CLI tools.

Actually very interesting question @Jared Wolinsky . I am curios about how enterprises using hybrind arch divide their teams. Like, how the physical hardware and the datacenter operation, is attacher or unattached from the software and orchestration, virtualuzation and automation.

@Tracy Kropp - by backstage, do you mean the developer portal or just general backend work?

@Kashmira Patel, I mean the developer portal.

@Kashmira Patel thanks! What’s involved in the microservices platform? Tooling around building microservices (e.g. service templates)? Or is it more the actual orchestration/monitoring/etc. (e.g. k8s/ecs)? And if it’s not the latter, I assume that is part of the software delivery team?

service templates, and basic “plumbing” - integrating with logging, monitoring, ci/cd pipelines, containerization, tagging. Basically adding in company standards and getting the service deployment ready.

Here we have this org • Platform development core ( building the internal developer portal back/front) • Delivery ( with all the ci CD, registry, artifacts, etc ) • Off platform (building tools for standardize Iac tools for the BU that choose to go outside the platform ) • Services ( a group of people building standardized services like caches, database, distributed locks, streams, etc that will be cloud agnostic for the developers ) • Compute, administrating k8s and ec2 • Infrastructure • Observability

@Rodrigo Amaro how big is the org?

@Jared Wolinsky 13k developers , 600 on cloud and platform I think, I don't have the actual numbers

Thanks!

But I'm very interested in how other orgs divide their responsabilities. I'm working on the networking and security part of the platform, but i feel we need some kind of solutions architecture. The problem here is we have several teams, but without any specialist on cloud on each one

My team is less than 10% the size of that 600, but we created an Enablement team to focus entirely on building a cohesive picture of the platform capabilities, develop onboarding and training programs, great user facing documentation, and work directly with teams to advise

@Jared Wolinsky what are the main platform capabilities your team supports?

In addition to Enablement, I landed on 4 teams aligned around functional areas or parts of the developer workflow: Cloud Foundation (overall AWS account structure and provisioning, networking, security/IAM, etc.), Developer Experience (service catalog/portal, overall local dev experience incl. build and test tooling and reference implementations, service templating), Delivery (CI/CD strategy and shared GH Actions, IaC strategy and shared CDK constructs, container orchestration and tooling), Observability (infra monitoring/APM/tracing/log aggregation tooling, dashboard templates, incident management tooling and processes)

This is great! Which team handles API gateway? I feel it straddles both devex and networking

We actually have a team outside my org in the product eng org that owns edge services/api gateway

Does seem like a platform candidate, right? Ours is managed by the dev ex team since they work very closely with app developers and provide API governance

Hey Guys - Great thread ....wondering how do you see Network Engineering and Security Engineering fall into the Platform Team ?

In our company, old days we had networking and security separated from platform, that was because for example we have fulfillments , warehouses, offices etc that need a cross networking teams. Right now we are facing a huge platform increment and we found the opportunity to add a minor networking team just for the platform due his special size (X00.000 ec2 instances, and a lot of k8s clusters ). Same case with security, cross teams wasn't enough and we star thinking how we can adopt platform specialist on security as well.

Similar here. There are network eng and security teams that are peer orgs of platform, but our cloud foundation team partners with them on networking and security inside the cloud platform

Makes sense…thanks. Is it fair to say then …if you’re a cloud/multi-cloud only company - its more logical to put network engineering into Platform I think…Security may still be part of InfoSec team …long term?

Seems fair as a general statement. Obviously the size of the company plays a factor but if the only networking that needs to be done is in the cloud platform that the platform team owns, save for maybe office connectivity, I could see it making more sense as part of the same org.

Agree with Jared. With more complicated networking needs (multiple BUs with different needs , acquisitions that need a stop gap measure, etc) a separate NetEng team might be warranted to keep the cloud team from drowning only in network related work.