------------------------------
Title: Landing Zone Technical Onboarding— the “How-To” (Google Cloud Adoption Series)
[content]
Welcome to the latest installment in the Google Cloud Adoption and Migration: From Strategy to Operation series.Previously, we covered the various considerations that are part of LZ design. In this part we’ll cover:Establishing your LZ Core Project Team.Establishing the support you need.Workshopping the design considerations.Agreeing and documenting your LZ design decisions in the LZ Design Document.Deploy!Technical Onboarding?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:Kick-off, scoping and planningUnderstanding organisational capability needsWorkshoppingImplementation (deployment)But before you can execute any steps, you’ll need a core project team.Establishing Your LZ Project TeamIf 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:Working through the various LZ design considerations that I have outlined in the previous few parts.Capturing your LZ design decisions.Deploying your LZ.What should this LZ core team look like? My recommendations are that you include the following: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.A project manager. For obvious reasons!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.)An SRE Lead. This person will be concerned with observability and embedding SRE best practice. They are likely a key member of the SRE Team, which may not yet formally exist.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.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.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.Which brings us on to…SupportAgain: 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 Google Cloud Partner 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:A Google Cloud Architect who is an expert in Google Cloud and LZ design.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.DevOps engineering capability, to either build and deploy your IaC, or to support and guide your own Platform Team.Additionally, such a partner can assist you to:Build your CCoE capability.Build your Platform Team.Build your SRE capability.Execute an initial migration PoC.Help you build an application migration factory team.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 EPAM 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!EPAM — A Google premier partnerThey 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!EPAM’s credentialsI’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 connect with me directly.WorkshopsTried-and-TestedNow 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:Initiation: LZ goals; current state; overall project scope; confirming roles and responsibilities; ways-of-working.Identity and Access Management: IAM; roles; master IdP decisions; Google Workspace superadmins; Google Cloud org admins; other groups; IdP integration; SSO and MFA.Resource Hierarchy and Management: org and folder structure; org policies; tenants and project factory principles; environments and sandboxes.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.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.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.Billing and Cost Optimisation: billing roles; tenant/project cost visibility; billing exports; project budgets; sandbox budgets; budget alerts; labelling strategy and standards.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.)So, that’s eight workshops with the core LZ team, and you can bring in specialists as required.Documenting Your LZ DesignAs 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:Introduction and scope of the solution.A summary of all design decisions. These should point to the relevant sections in the document.Sections corresponding to each of the workshops.Deploy!I’m going to cover this in the next installment!Before You GoPlease share this with anyone that you think will be interested. It might help them, and it really helps me!Please give me claps! You know you clap more than once, right?Feel free to leave a comment 💬.Follow and subscribe, so you don’t miss my content. Go to my Profile Page, and click on these icons:Follow and SubscribeLinksLanding Zones on Google Cloud: What It Is, Why You Need One, and How to Create OneGoogle Cloud PartnersEPAMGoogle Cloud Architecture FrameworkEnterprise Foundations BlueprintSeries NavigationSeries overview and structureOrg change, upskilling and CCoE EstablishmentSRE best practicePrevious: Design your Landing Zone — Design Considerations Part 4: IaC, GitOps and CI/CDNext: Technical Onboarding and Landing Zone DeploymentLanding Zone Technical Onboarding— the “How-To” (Google Cloud Adoption Series) was originally published in Google Cloud - Community on Medium, where people are continuing the conversation by highlighting and responding to this story.
[/content]

Author: Dazbo (Darren Lester)
PublishedDate: 2024-04-15
Category: Blogs
NewsPaper: Google Cloud - Medium
Tags: technical-design, google-cloud-platform, google-cloud-partner, landingzone, project-team