Editing article

Title

Summary

Content

Welcome to the latest installment in the <a href="https://medium.com/google-cloud/google-cloud-adoption-for-the-enterprise-from-strategy-to-operation-part-0-overview-9091f5a1ddfc">Google Cloud Adoption and Migration: From Strategy to Operation</a> series.Previously, we covered the various considerations that are part of LZ design. In this part we’ll cover:<ul><li>Establishing your LZ Core Project Team.</li><li>Establishing the support you need.</li><li>Workshopping the design considerations.</li><li>Agreeing and documenting your LZ design decisions in the LZ Design Document.</li><li>Deploy!</li></ul><h3>Technical Onboarding?</h3>Google refers to the overall process of setting up a Cloud environment as “Technical Onboarding”. Historically it was referred to as “Cloud Foundation”. It includes:<ol><li>Kick-off, scoping and planning</li><li>Understanding organisational capability needs</li><li>Workshopping</li><li>Implementation (deployment)</li></ol>But before you can execute any steps, you’ll need a core project team.<h3>Establishing Your LZ Project Team</h3>If you’re working through the process of designing your LZ, then it’s probably fair to say that your maturity with Google Cloud is quite low. If you were mature in Google Cloud, you’d already have your well-designed LZ! So the first thing you’ll need to do is establish the core LZ project team, who will be responsible for:<ul><li>Working through the various LZ design considerations that I have outlined in the previous few parts.</li><li>Capturing your LZ design decisions.</li><li>Deploying your LZ.</li></ul>What should this LZ core team look like? My recommendations are that you include the following:<ul><li>A lead cloud architect. This needs to be someone who fully understands cloud, and your organisation’s cloud strategy. Possibly, they were the enterprise cloud architect who created the organisation’s cloud strategy in the first place. This person will ultimately own the technical deliverables, and have the final say on the design decisions.</li><li>A project manager. For obvious reasons!</li><li>A Platform / DevOps Lead. This is someone who has a strong understanding of Google Cloud, DevOps, and Terraform IaC. This person will ultimately be responsible for deployment of the LZ. They are likely also a key member of the Cloud Platform Team, which may not yet formally exist at this point in the journey. (And it is likely that this person will be a pivotal member of the new Cloud Platform Team.)</li><li>An SRE Lead. This person will be concerned with observability and embedding <a href="https://medium.com/@derailed.dash/google-cloud-adoption-site-reliability-engineering-sre-and-best-practices-for-sli-slo-sla-6670c864c96b">SRE best practice</a>. They are likely a key member of the SRE Team, which may not yet formally exist.</li><li>A network architect. Someone who understands your existing network topology, switching and routing, and your network strategy. This person will be well placed to describe the options and constraints, particularly when agreeing hybrid connectivity, DNS options, etc.</li><li>A security architect. Someone who understands the organisational security requirements, as well as existing capabilities and use cases for technologies like firewalls, IDS/IPS, WAF, and proxies. They will also be aware of the security strategy.</li><li>Google Cloud SMEs. You need a some Google Cloud specialists who collectively have strong knowledge and experience of Google Cloud LZs, and of all the products and services that are fundamental the LZ, such as IAM, networking, GKE, monitoring and alerting, etc.</li></ul>Which brings us on to…<h3>Support</h3><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/0*iwfCzdjGNwy9VRke" /></figure>Again: if you’re in the process of designing and building your LZ, it’s quite likely that your organisation doesn’t yet have the necessary expertise and experience to design and deploy the LZ. You’re going to need some help.For this, I would recommend engaging with Google, or with a <a href="https://cloud.google.com/find-a-partner/">Google Cloud Partner</a> that offers a Landing Zone design and build service. During the LZ design and build phase, you can supplement your internal team with all the expertise (and experience) that you need. For example, the Google Cloud partner can supply you with:<ul><li>A Google Cloud Architect who is an expert in Google Cloud and LZ design.</li><li>Additional experts who can handle any specific queries that the architect doesn’t have the answers to. These additional resources could be deployed into your core team, or simply be available as “background resources” that your partner can tap into.</li><li>DevOps engineering capability, to either build and deploy your IaC, or to support and guide your own Platform Team.</li></ul>Additionally, such a partner can assist you to:<ul><li>Build your <a href="https://medium.com/@derailed.dash/google-cloud-adoption-organisational-change-capabilities-upskilling-and-cloud-centre-of-15bc49ae7ae6">CCoE capability</a>.</li><li>Build your Platform Team.</li><li>Build your <a href="https://medium.com/@derailed.dash/google-cloud-adoption-site-reliability-engineering-sre-and-best-practices-for-sli-slo-sla-6670c864c96b">SRE capability</a>.</li><li>Execute an initial migration PoC.</li><li>Help you build an application migration factory team.</li></ul>The partner can advise on organisational structure, provide resource augmentation until your organisation is self sufficient, and help upskill your internal staff.It would be remiss of me not to mention <a href="https://www.epam.com/?gad_source=1&amp;gclid=Cj0KCQjwlN6wBhCcARIsAKZvD5h7jf_UxQE04IrMPl5G9rxYkX2YhMjUgUVU_jPCnO9AWjz9fnPgXLkaAiX0EALw_wcB">EPAM</a> at this stage, because a) they are a Google Cloud Premier Partner that offers such a service; and b) I happen to work for them!<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/0*az-PumqTxzgAcYpE.png" /><figcaption>EPAM — A Google premier partner</figcaption></figure>They are multinational, with around 50000 engineers and consultants. They have over 1200 Google Cloud certified experts, and they have won Google Cloud Partner of the Year in 2018, 2023 and 2024!<figure><img alt="" src="https://cdn-images-1.medium.com/max/868/1*gv58BYiOq362nTAF4flxgQ.png" /><figcaption>EPAM’s credentials</figcaption></figure>I’ve worked with a lot of consultancies over my career (though typically, as the client), and I can honestly say: EPAM are the gold standard.If you do want to engage with EPAM, you can reach out through the link above, or you can <a href="https://github.com/derailed-dash">connect with me directly</a>.<h3>Workshops</h3><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/0*RejtZ3_J4Zzn-rtG.jpg" /><figcaption>Tried-and-Tested</figcaption></figure>Now you’ve got your project team and engaged with the support you need, it’s time to crack on with some workshops!Google’s tried-and-tested approach is to hold a series of workshops, aligned to the various LZ design considerations that I’ve previously covered. (Google Cloud partners will typically use a similar approach.) I would recommend a 2 hour workshop for each of the following topics:<ul><li>Initiation: LZ goals; current state; overall project scope; confirming roles and responsibilities; ways-of-working.</li><li>Identity and Access Management: IAM; roles; master IdP decisions; Google Workspace superadmins; Google Cloud org admins; other groups; IdP integration; SSO and MFA.</li><li>Resource Hierarchy and Management: org and folder structure; org policies; tenants and project factory principles; environments and sandboxes.</li><li>Network and Security: hybrid connectivity; shared VPC topology; VPC-SC; firewall; ingress and egress (including Internet connectivity) patterns; current network/appliance considerations; DDoS and WAF (e.g. with Cloud Armor); DNS; DR and region considerations; org policies revisit.</li><li>Compute and GKE: GKE strategy; multitenant cluster design; fleet design; GKE address ranges; release channels; Workload Identity Federation; Anthos service mesh; IaaS OS management and upgrade/patching strategy.</li><li>Operations and Visibility: monitoring, logging and alerting; predefined and custom dashboards; metrics, including GKE and Istio metrics, and Ops Agent; metrics scope (aggregation and isolation) design; SIEM considerations; audit logging; network service logging; logging aggegration and organisational log sinks; log archiving and exports; integration with other operations software (e.g. on-prem); SRE considerations.</li><li>Billing and Cost Optimisation: billing roles; tenant/project cost visibility; billing exports; project budgets; sandbox budgets; budget alerts; labelling strategy and standards.</li><li>Automation, GitOps and Foundation Enablement: IaC, GitOps and CI/CD; LZ IaC frameworks and accelerators (e.g. Google Fabric FAST and Google CFT); IaC policy enforcement; project factory; tenant onboarding processes and support. (I’m going to cover tenant enablement later in the series.)</li></ul>So, that’s eight workshops with the core LZ team, and you can bring in specialists as required.<h3>Documenting Your LZ Design</h3>As you progress through the workshops, document the design decisions as you go. Capture your overall design and decisions in an artefact that Google calls the LZ Technical Design Document (TDD).This doc should include:<ul><li>Introduction and scope of the solution.</li><li>A summary of all design decisions. These should point to the relevant sections in the document.</li><li>Sections corresponding to each of the workshops.</li></ul><h3>Deploy!</h3>I’m going to cover this in the next installment!<h3>Before You Go</h3><ul><li>Please share this with anyone that you think will be interested. It might help them, and it really helps me!</li><li>Please give me claps! You know you clap more than once, right?</li><li>Feel free to leave a comment 💬.</li><li>Follow and subscribe, so you don’t miss my content. Go to my <a href="https://medium.com/@derailed.dash">Profile Page</a>, and click on these icons:</li></ul><figure><img alt="" src="https://cdn-images-1.medium.com/max/163/0*fF62z2-FT03ui0O5.png" /><figcaption>Follow and Subscribe</figcaption></figure><h3>Links</h3><ul><li><a href="https://medium.com/google-cloud/landing-zones-on-google-cloud-b42b08e1abaa">Landing Zones on Google Cloud: What It Is, Why You Need One, and How to Create One</a></li><li><a href="https://cloud.google.com/find-a-partner/">Google Cloud Partners</a></li><li><a href="https://www.epam.com/?gad_source=1&amp;gclid=Cj0KCQjwlN6wBhCcARIsAKZvD5h7jf_UxQE04IrMPl5G9rxYkX2YhMjUgUVU_jPCnO9AWjz9fnPgXLkaAiX0EALw_wcB">EPAM</a></li><li><a href="https://cloud.google.com/architecture/framework">Google Cloud Architecture Framework</a></li><li><a href="https://cloud.google.com/architecture/security-foundations">Enterprise Foundations Blueprint</a></li></ul><h3>Series Navigation</h3><ul><li><a href="https://medium.com/google-cloud/google-cloud-adoption-for-the-enterprise-from-strategy-to-operation-part-0-overview-9091f5a1ddfc">Series overview and structure</a></li><li><a href="https://medium.com/@derailed.dash/google-cloud-adoption-organisational-change-capabilities-upskilling-and-cloud-centre-of-15bc49ae7ae6">Org change, upskilling and CCoE Establishment</a></li><li><a href="https://medium.com/@derailed.dash/google-cloud-adoption-site-reliability-engineering-sre-and-best-practices-for-sli-slo-sla-6670c864c96b">SRE best practice</a></li><li>Previous: <a href="https://medium.com/google-cloud/design-your-landing-zone-design-considerations-part-4-iac-gitops-and-ci-cd-google-cloud-ae3f533c6dbd">Design your Landing Zone — Design Considerations Part 4: IaC, GitOps and CI/CD</a></li><li>Next: Technical Onboarding and Landing Zone Deployment</li></ul><img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=9b7ba8710e83" width="1" height="1" alt=""><hr><a href="https://medium.com/google-cloud/landing-zone-technical-onboarding-the-how-to-google-cloud-adoption-series-9b7ba8710e83">Landing Zone Technical Onboarding— the “How-To” (Google Cloud Adoption Series)</a> was originally published in <a href="https://medium.com/google-cloud">Google Cloud - Community</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

Author

Link

Published date

Image url

Feed url

Guid

Hidden blurb

--- !ruby/object:Feedjira::Parser::RSSEntry
title: Landing Zone Technical Onboarding— the “How-To” (Google Cloud Adoption Series)
published: 2024-04-15 08:06:46.000000000 Z
categories:
- technical-design
- google-cloud-platform
- google-cloud-partner
- landingzone
- project-team
url: https://medium.com/google-cloud/landing-zone-technical-onboarding-the-how-to-google-cloud-adoption-series-9b7ba8710e83?source=rss----e52cf94d98af---4
entry_id: !ruby/object:Feedjira::Parser::GloballyUniqueIdentifier
 is_perma_link: 'false'
 guid: https://medium.com/p/9b7ba8710e83
carlessian_info:
 news_filer_version: 2
 newspaper: Google Cloud - Medium
 macro_region: Blogs
content: "Welcome to the latest installment in the <a href=\"https://medium.com/google-cloud/google-cloud-adoption-for-the-enterprise-from-strategy-to-operation-part-0-overview-9091f5a1ddfc\">Google
 Cloud Adoption and Migration: From Strategy to Operation</a> series.Previously,
 we covered the various considerations that are part of LZ design. In this part we’ll cover:<ul><li>Establishing
 your LZ Core Project Team.</li><li>Establishing the support
 you need.</li><li>Workshopping the design considerations.</li><li>Agreeing
 and documenting your LZ design decisions in the LZ Design
 Document.</li><li>Deploy!</li></ul><h3>Technical Onboarding?</h3>Google
 refers to the overall process of setting up a Cloud environment as “Technical
 Onboarding”. Historically it was referred to as “Cloud Foundation”.
 It includes:<ol><li>Kick-off, scoping and planning</li><li>Understanding organisational
 capability needs</li><li>Workshopping</li><li>Implementation (deployment)</li></ol>But
 before you can execute any steps, you’ll need a core project team.<h3>Establishing
 Your LZ Project Team</h3>If you’re working through the process of designing your
 LZ, then it’s probably fair to say that your maturity with Google Cloud is quite
 low. If you were mature in Google Cloud, you’d already have your well-designed LZ!
 So the first thing you’ll need to do is establish the core LZ project team,
 who will be responsible for:<ul><li>Working through the various LZ design considerations
 that I have outlined in the previous few parts.</li><li>Capturing your LZ design
 decisions.</li><li>Deploying your LZ.</li></ul>What should this LZ core
 team look like? My recommendations are that you include the following:<ul><li>A
 lead cloud architect. This needs to be someone who fully understands
 cloud, and your organisation’s cloud strategy. Possibly, they were the enterprise
 cloud architect who created the organisation’s cloud strategy in the first place.
 This person will ultimately own the technical deliverables, and have the final say
 on the design decisions.</li><li>A project manager. For obvious reasons!</li><li>A
 Platform / DevOps Lead. This is someone who has a strong understanding
 of Google Cloud, DevOps, and Terraform IaC. This person will ultimately be responsible
 for deployment of the LZ. They are likely also a key member of the Cloud
 Platform Team, which may not yet formally exist at this point in the
 journey. (And it is likely that this person will be a pivotal member of the
 new Cloud Platform Team.)</li><li>An SRE Lead. This person will
 be concerned with observability and embedding <a href=\"https://medium.com/@derailed.dash/google-cloud-adoption-site-reliability-engineering-sre-and-best-practices-for-sli-slo-sla-6670c864c96b\">SRE
 best practice</a>. They are likely a key member of the SRE Team,
 which may not yet formally exist.</li><li>A network architect.
 Someone who understands your existing network topology, switching and routing, and
 your network strategy. This person will be well placed to describe the options and
 constraints, particularly when agreeing hybrid connectivity, DNS options, etc.</li><li>A
 security architect. Someone who understands the organisational
 security requirements, as well as existing capabilities and use cases for technologies
 like firewalls, IDS/IPS, WAF, and proxies. They will also be aware of the security
 strategy.</li><li>Google Cloud SMEs. You need a some Google Cloud
 specialists who collectively have strong knowledge and experience of Google Cloud
 LZs, and of all the products and services that are fundamental the LZ, such as IAM,
 networking, GKE, monitoring and alerting, etc.</li></ul>Which brings us on to…<h3>Support</h3><figure><img
 alt=\"\" src=\"https://cdn-images-1.medium.com/max/1024/0*iwfCzdjGNwy9VRke\" /></figure>Again:
 if you’re in the process of designing and building your LZ, it’s quite likely that
 your organisation doesn’t yet have the necessary expertise and experience to design
 and deploy the LZ. You’re going to need some help.For this, I would recommend
 engaging with Google, or with a <a href=\"https://cloud.google.com/find-a-partner/\">Google
 Cloud Partner</a> that offers a Landing Zone design and build service.
 During the LZ design and build phase, you can supplement your internal team with
 all the expertise (and experience) that you need. For example, the Google Cloud
 partner can supply you with:<ul><li>A Google Cloud Architect
 who is an expert in Google Cloud and LZ design.</li><li>Additional experts
 who can handle any specific queries that the architect doesn’t have the answers
 to. These additional resources could be deployed into your core team, or simply
 be available as “background resources” that your partner can tap into.</li><li>DevOps
 engineering capability, to either build and deploy your IaC, or to support
 and guide your own Platform Team.</li></ul>Additionally, such a partner can assist
 you to:<ul><li>Build your <a href=\"https://medium.com/@derailed.dash/google-cloud-adoption-organisational-change-capabilities-upskilling-and-cloud-centre-of-15bc49ae7ae6\">CCoE
 capability</a>.</li><li>Build your Platform Team.</li><li>Build your <a href=\"https://medium.com/@derailed.dash/google-cloud-adoption-site-reliability-engineering-sre-and-best-practices-for-sli-slo-sla-6670c864c96b\">SRE
 capability</a>.</li><li>Execute an initial migration PoC.</li><li>Help you build
 an application migration factory team.</li></ul>The partner can advise on organisational
 structure, provide resource augmentation until your organisation is self sufficient,
 and help upskill your internal staff.It would be remiss of me not to mention
 <a href=\"https://www.epam.com/?gad_source=1&amp;gclid=Cj0KCQjwlN6wBhCcARIsAKZvD5h7jf_UxQE04IrMPl5G9rxYkX2YhMjUgUVU_jPCnO9AWjz9fnPgXLkaAiX0EALw_wcB\">EPAM</a>
 at this stage, because a) they are a Google Cloud Premier Partner
 that offers such a service; and b) I happen to work for them!<figure><img alt=\"\"
 src=\"https://cdn-images-1.medium.com/max/1024/0*az-PumqTxzgAcYpE.png\" /><figcaption>EPAM — A
 Google premier partner</figcaption></figure>They are multinational, with around
 50000 engineers and consultants. They have over 1200 Google Cloud certified experts,
 and they have won Google Cloud Partner of the Year in 2018, 2023
 and 2024!<figure><img alt=\"\" src=\"https://cdn-images-1.medium.com/max/868/1*gv58BYiOq362nTAF4flxgQ.png\"
 /><figcaption>EPAM’s credentials</figcaption></figure>I’ve worked with a lot
 of consultancies over my career (though typically, as the client), and I can honestly
 say: EPAM are the gold standard.If you do want to engage
 with EPAM, you can reach out through the link above, or you can <a href=\"https://github.com/derailed-dash\">connect
 with me directly</a>.<h3>Workshops</h3><figure><img alt=\"\" src=\"https://cdn-images-1.medium.com/max/1024/0*RejtZ3_J4Zzn-rtG.jpg\"
 /><figcaption>Tried-and-Tested</figcaption></figure>Now you’ve got your project
 team and engaged with the support you need, it’s time to crack on with some workshops!Google’s
 tried-and-tested approach is to hold a series of workshops, aligned to
 the various LZ design considerations that I’ve previously covered. (Google Cloud
 partners will typically use a similar approach.) I would recommend a 2 hour workshop
 for each of the following topics:<ul><li>Initiation: LZ goals;
 current state; overall project scope; confirming roles and responsibilities; ways-of-working.</li><li>Identity
 and Access Management: IAM; roles; master IdP decisions; Google Workspace
 superadmins; Google Cloud org admins; other groups; IdP integration; SSO and MFA.</li><li>Resource
 Hierarchy and Management: org and folder structure; org policies; tenants
 and project factory principles; environments and sandboxes.</li><li>Network
 and Security: hybrid connectivity; shared VPC topology; VPC-SC; firewall;
 ingress and egress (including Internet connectivity) patterns; current network/appliance
 considerations; DDoS and WAF (e.g. with Cloud Armor); DNS; DR and region considerations;
 org policies revisit.</li><li>Compute and GKE: GKE strategy; multitenant
 cluster design; fleet design; GKE address ranges; release channels; Workload Identity
 Federation; Anthos service mesh; IaaS OS management and upgrade/patching strategy.</li><li>Operations
 and Visibility: monitoring, logging and alerting; predefined and custom
 dashboards; metrics, including GKE and Istio metrics, and Ops Agent; metrics scope
 (aggregation and isolation) design; SIEM considerations; audit logging; network
 service logging; logging aggegration and organisational log sinks; log archiving
 and exports; integration with other operations software (e.g. on-prem); SRE considerations.</li><li>Billing
 and Cost Optimisation: billing roles; tenant/project cost visibility; billing
 exports; project budgets; sandbox budgets; budget alerts; labelling strategy and
 standards.</li><li>Automation, GitOps and Foundation Enablement:
 IaC, GitOps and CI/CD; LZ IaC frameworks and accelerators (e.g. Google Fabric FAST
 and Google CFT); IaC policy enforcement; project factory; tenant onboarding processes
 and support. (I’m going to cover tenant enablement later in the series.)</li></ul>So,
 that’s eight workshops with the core LZ team, and you can bring in specialists as
 required.<h3>Documenting Your LZ Design</h3>As you progress through the workshops,
 document the design decisions as you go. Capture your overall design and decisions
 in an artefact that Google calls the LZ Technical Design Document (TDD).This
 doc should include:<ul><li>Introduction and scope of the solution.</li><li>A
 summary of all design decisions. These should point to the relevant sections in
 the document.</li><li>Sections corresponding to each of the workshops.</li></ul><h3>Deploy!</h3>I’m
 going to cover this in the next installment!<h3>Before You Go</h3><ul><li>Please
 share this with anyone that you think will be interested. It might help
 them, and it really helps me!</li><li>Please give me claps! You
 know you clap more than once, right?</li><li>Feel free to leave a comment \U0001F4AC.</li><li>Follow
 and subscribe, so you don’t miss my content. Go to my <a href=\"https://medium.com/@derailed.dash\">Profile
 Page</a>, and click on these icons:</li></ul><figure><img alt=\"\" src=\"https://cdn-images-1.medium.com/max/163/0*fF62z2-FT03ui0O5.png\"
 /><figcaption>Follow and Subscribe</figcaption></figure><h3>Links</h3><ul><li><a
 href=\"https://medium.com/google-cloud/landing-zones-on-google-cloud-b42b08e1abaa\">Landing
 Zones on Google Cloud: What It Is, Why You Need One, and How to Create One</a></li><li><a
 href=\"https://cloud.google.com/find-a-partner/\">Google Cloud Partners</a></li><li><a
 href=\"https://www.epam.com/?gad_source=1&amp;gclid=Cj0KCQjwlN6wBhCcARIsAKZvD5h7jf_UxQE04IrMPl5G9rxYkX2YhMjUgUVU_jPCnO9AWjz9fnPgXLkaAiX0EALw_wcB\">EPAM</a></li><li><a
 href=\"https://cloud.google.com/architecture/framework\">Google Cloud Architecture
 Framework</a></li><li><a href=\"https://cloud.google.com/architecture/security-foundations\">Enterprise
 Foundations Blueprint</a></li></ul><h3>Series Navigation</h3><ul><li><a href=\"https://medium.com/google-cloud/google-cloud-adoption-for-the-enterprise-from-strategy-to-operation-part-0-overview-9091f5a1ddfc\">Series
 overview and structure</a></li><li><a href=\"https://medium.com/@derailed.dash/google-cloud-adoption-organisational-change-capabilities-upskilling-and-cloud-centre-of-15bc49ae7ae6\">Org
 change, upskilling and CCoE Establishment</a></li><li><a href=\"https://medium.com/@derailed.dash/google-cloud-adoption-site-reliability-engineering-sre-and-best-practices-for-sli-slo-sla-6670c864c96b\">SRE
 best practice</a></li><li>Previous: <a href=\"https://medium.com/google-cloud/design-your-landing-zone-design-considerations-part-4-iac-gitops-and-ci-cd-google-cloud-ae3f533c6dbd\">Design
 your Landing Zone — Design Considerations Part 4: IaC, GitOps and CI/CD</a></li><li>Next:
 Technical Onboarding and Landing Zone Deployment</li></ul><img src=\"https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=9b7ba8710e83\"
 width=\"1\" height=\"1\" alt=\"\"><hr><a href=\"https://medium.com/google-cloud/landing-zone-technical-onboarding-the-how-to-google-cloud-adoption-series-9b7ba8710e83\">Landing
 Zone Technical Onboarding— the “How-To” (Google Cloud Adoption Series)</a> was originally
 published in <a href=\"https://medium.com/google-cloud\">Google Cloud - Community</a>
 on Medium, where people are continuing the conversation by highlighting and responding
 to this story."
rss_fields:
- title
- published
- categories
- url
- entry_id
- content
- author
author: Dazbo (Darren Lester)

Language

Active

Ricc internal notes

Ricc source

Show this article Back to articles