{"id":241,"date":"2022-04-19T22:39:00","date_gmt":"2022-04-19T12:39:00","guid":{"rendered":"https:\/\/sysmit.com\/cf22\/?p=241"},"modified":"2024-01-01T12:26:21","modified_gmt":"2024-01-01T02:26:21","slug":"evolution-of-cloud-infrastructure-teams","status":"publish","type":"post","link":"https:\/\/sysmit.com\/cf22\/evolution-of-cloud-infrastructure-teams\/","title":{"rendered":"How cloud infrastructure teams evolve – from start to maturity"},"content":{"rendered":"\n

I recently read a post by Will Larson, who started SRE at Uber. The post is called the Trunks and branches model for scaling infrastructure organizations<\/a>. <\/em><\/p>\n\n\n\n

Several passages in the post covered how infrastructure teams can evolve from the startup phase. I felt it would be easier to comprehend the dense-and-rich advice with a visual summary. <\/p>\n\n\n\n

Check out what I put together below. <\/p>\n\n\n\n

\"Overview<\/figure>\n\n\n

Explanation of the visual summary of cloud infrastructure teams <\/h2>\n\n\n

The key premise of Will Larson’s trunks and branches<\/em> model is that infrastructure teams evolve from starting up i.e. early-stage to a usually chaotic growth phase and finally to mature & stable.<\/p>\n\n\n\n

Let’s start from the very beginning.<\/p>\n\n\n

Early-stage cloud infrastructure teams<\/h3>\n\n\n

The typical cloud infrastructure initiative starts with one team that handles almost everything<\/strong>. Rarely does a full-blown investment into multiple teams occur from the outset.<\/p>\n\n\n\n

The work at this early stage is mostly generalist in nature<\/strong>. It may include platform work like provisioning virtual machines on AWS, Azure, GCP, or other cloud providers. <\/p>\n\n\n\n

It may also include reactive work like an incident response when outages occur.<\/p>\n\n\n\n\n

Growth phase cloud infrastructure teams<\/h3>\n\n\n

Prickly problems will start to emerge across the entire infrastructure footprint as the cloud service serves more users or hosts more resource-intensive applications. <\/strong><\/p>\n\n\n\n

The original team handling the overall system might not have the mental bandwidth or requisite skills to resolve these emerging issues. It’s sometimes the case that early trunk teams are proficient at handling only the core AWS or GCP, or Azure services.<\/p>\n\n\n\n

Let’s use AWS as an example. A trunk team might know how to run core services like EC2 instances with S3 storage and VPC. This team may be known in some organizations as the platform team.<\/em><\/p>\n\n\n\n

Anything beyond that will pose a challenge or even be impossible for them.<\/p>\n\n\n\n

As software services evolve in complexity, their data may need to be stored in distributed databases. Distributed databases comprise a complex software architecture.<\/p>\n\n\n\n

In addition, AWS alone has a suite of 200+ services to serve specific use cases, most of which would be beyond the scope of a generalist trunk team.<\/p>\n\n\n\n

During this chaotic growth phase, managers responsible for cloud infrastructure may add branch teams to the main trunk. <\/p>\n\n\n\n

The aim would be to have branch teams solve specialized problems<\/strong> like implementing more cloud services, supporting trickier architectures, unclogging internal workflows, and handling recurring outages. <\/p>\n\n\n\n

Site Reliability Engineers are well-placed to support engineers doing this kind of work. After all, effectiveness in this area will likely translate to better software performance and reliability.<\/p>\n\n\n\n

Branch teams may specifically own a sliver of the entire cloud architecture e.g. storage, compute, chaos, and performance management.<\/p>\n\n\n

Stable and mature infrastructure teams<\/h3>\n\n\n

The final mature stage is arguably the goal for organizations managing cloud deployments. Its stable nature implies a degree of predictability and stress mitigation. <\/p>\n\n\n\n

At this point, the cloud infrastructure serves a complex software system with 100s to 1000s of services. <\/p>\n\n\n\n

There will be many branch teams to handle specialized and long-range issues. They possess specialized knowledge to identify which of today’s minor problems will become tomorrow’s big problems.<\/p>\n\n\n\n

Site Reliability Engineers are well-placed to work at this phase because they are specialists in handling complex software systems across several branches. <\/p>\n\n\n\n

A mature cloud infrastructure organization will have the thinnest possible trunk of non-specialist infrastructure engineers. There may be occasions where branch team engineers rotate in-and-out-of trunk teams<\/strong> on temporary assignments. <\/p>\n\n\n\n

Keep in mind that their level of ability means that branch teams don’t routinely participate in the “trunk team” type of work of service provisioning or out-of-hours incident response.<\/p>\n\n\n\n

Branch team members out on rotation can use this opportunity to identify issues that can be resolved with their specialist expertise.<\/p>\n\n\n

Conclusion<\/h2>\n\n\n

I hope the visual summary and its explanation have given you clarity on how cloud infrastructure teams can evolve from startup to maturity.<\/p>\n","protected":false},"excerpt":{"rendered":"

I recently read a post by Will Larson, who started SRE at Uber. The post is called the Trunks and branches model for scaling infrastructure organizations. Several passages in the post covered how infrastructure teams can evolve from the startup phase. I felt it would be easier to comprehend the dense-and-rich advice with a visual […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[60,29,4],"tags":[41,13,7],"_links":{"self":[{"href":"https:\/\/sysmit.com\/cf22\/wp-json\/wp\/v2\/posts\/241"}],"collection":[{"href":"https:\/\/sysmit.com\/cf22\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/sysmit.com\/cf22\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/sysmit.com\/cf22\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/sysmit.com\/cf22\/wp-json\/wp\/v2\/comments?post=241"}],"version-history":[{"count":23,"href":"https:\/\/sysmit.com\/cf22\/wp-json\/wp\/v2\/posts\/241\/revisions"}],"predecessor-version":[{"id":6306,"href":"https:\/\/sysmit.com\/cf22\/wp-json\/wp\/v2\/posts\/241\/revisions\/6306"}],"wp:attachment":[{"href":"https:\/\/sysmit.com\/cf22\/wp-json\/wp\/v2\/media?parent=241"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/sysmit.com\/cf22\/wp-json\/wp\/v2\/categories?post=241"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/sysmit.com\/cf22\/wp-json\/wp\/v2\/tags?post=241"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}