[MUSIC] Once you've established some key practices and have begun training and hiring for the SRE role in your organization, you can start thinking about how to implement your SRE team. This implementation can, and will look different depending on the size of your organization, and where you are on your SRE journey. In this video, we'll give you an overview of the different types of implementations, and the benefits, and disadvantages of each. We've categorized the recommended implementations into six different categories. Kitchen sink or everything SRE, infrastructure, tools, product/application, embedded, and consulting. The first is kitchen sink or everything SRE. Scope is usually unbounded with this type of team. If you've never created an SRE team, this is a good place to start. We recommend this approach for organizations that have few applications and user journeys. Where the scope is small enough that only one team is necessary, but a dedicated SRE team is needed in order to implement its practices. There are several benefits to kitchen sink implementation. There are no coverage gaps between SRE teams given that only one team is in place. It's easy to spot patterns and draw similarities between services and projects. SREs tend to act as glue between disparate developer teams, creating solutions at a distinct pieces of software. There are also several disadvantages. There's usually a lack of an SRE team charter, or the charter states that everything in the company can be in scope, running the risk of overloading team. As the company and system complexity grows, the team tends to move from having a deep positive impact on everything, to making more shallow contributions. And issues involving a team may negatively impact your entire business. The second implementation, is infrastructure. This type of team focuses on behind the scenes tasks, that help make other team's jobs easier and faster. They work on maintaining shared services and components related to infrastructure, versus an SRE team dedicated to working on services related to products, like customer facing code. We recommend this implementation for a company with several development teams since they probably need to staff an infrastructure team to define common standards and practices. It is common for large companies to have both an infrastructure DevOps team and SRE team, where the DevOps team focuses on features, and SRE focuses on reliability. A benefit of the infrastructure implementation is that it allows product developers to use DevOps practices to maintain user facing products, without divergence in practice across the business. Additionally, SREs can focus on providing a highly reliable infrastructure. They will often define production standards as code, and work to smooth out any sharp edges to greatly simplify things for the product developers running their own services. However, there are some disadvantages. Depending on the scope of infrastructure, issues involving such a team may negatively impact your entire business. Similar to an everything SRE team implementation. Lack of direct contact with your company's customers can lead to a focus on infrastructure improvements, that are not necessarily tied to the customer experience. As the company and system complexity grows, you may be required to split infrastructure teams, which can lead to duplication of base infrastructure, or divergence of practices between teams. Which is inefficient and limits knowledge sharing and mobility. Third is a tools-focused SRE team. This type of SRE team tends to focus on building software to help their developer counterparts measure, maintain, and improve system reliability or other aspects of SRe work, such as capacity planning. A tooling SRE team risks solving the wrong problems for the business. So it needs to stay aware of the practical problems frontline reliability teams are addressing. This kind of team is recommended for any organization that needs a highly specialized reliability-related tooling. The benefits and disadvantages of infrastructure in tools SRE teams tend to be similar. Additional disadvantages for tools teams include, ensuring that the team doesn't unintentionally turn into an infrastructure team and vice vasa. Running the risk of an increase of toil and overall workload. This is usually contained by establishing a team charter that business leaders approve. The next implementation is product/application. This kind of SRE team works to improve the reliability of a critical application or business area. We recommend this implementation for organizations that already have a kitchen sink, infrastructure, or tools-focused SRE team, and have a key user facing application with high reliability needs. Having each of these aspects, justifies the relatively large expense of a dedicated set of SREs. The benefit of this approach, is that it provides a clear focus for the team's effort, and creates a clear link between business priorities and where the team spends effort. The disadvantage is that as the company and system complexity grow, the organization will require new product application teams. As with an infrastructure team, the focus of each team can lead to duplication of base infrastructure or divergence of practices which is inefficient and limits knowledge sharing immobility. The fifth type of SRE team implementation is an embedded team. This team has SREs embedded with their developer counterparts, usually one developer team in scope. And embedded SRP usually shares an office with a developer, but the embedded arrangement can be remote. The work relationship between the embedded SREs and developers tends to be project or time-bounded. During embedded engagements, the SREs are usually very hands-on, performing work like changing code, and configuration of the services and scope. We recommend this implementation to either start an SRE function, or scale another implementation. This model is useful when you've had a project or team that needs SRE for a period of time. This type of team can also augment the impact of the tools or infrastructure team by driving adoption. A benefit of an embedded SRE team is that focused SRE expertise can be directed to specific problems or teams. It also allows side-by-side demonstration of SRE practices, which can be a very effective teaching method. Disadvantages are that it may result in a lack of standardization between teams, or divergence in practice. And SREs may not have the chance to spend time with peers to mentor them. Our last recommended SRE implementation is consulting. This implementation is very similar to embedded implementation. The difference is that consulting SREs are less hands-on. These SRE's tend to avoid changing customer code and configuration of the services and scope. However, they may write code and configuration to build and maintain tools for themselves or their developer counterparts. Which is a hybrid of the consulting and tools-focused SRE role. We recommend waiting to staff a dedicated SRE team of consultants, until your organization, or complexity is considered to be large. And when demands have outgrown what can be supported by existing SRE team implementations. We also recommend staffing one or two part-time consultants before you staff your first SRE team. The benefit of a consulting SRE team is that it can help with additional scaling of an existing SRE team's positive impact, by being decoupled from directly changing code and configuration. The disadvantage is that consultants may lack sufficient context to offer useful advice. Additionally, a common risk for consulting SRE teams is being perceived as hands-off. Given that they typically don't change code and configuration, even though they are capable of having indirect technical impact. Do one or any of these SRE team implementations resonate or appeal to you for your organization? Remember that it's important to assess your organization's maturity for SRE adoption, and identify areas for training before creating your first SRE team. In the next and final video, you'll learn how Google can help your organization get started with SRE.