Best practices are a set of methods or techniques that have been generally accepted as superior to other alternatives. Best practices are called this because the outcome that is produced by using them is better than those produced by using other methods. A best practice may be a feature of accredited management standards such as ISO 9000 and ISO 14001.
Google Cloud’s best practices are resources that Google has identified and recommends to customers who want to achieve the best possible cloud architecture and follow Google’s recommendations. Google has developed best practices by working with many customers and those repeatable best patterns have helped to ease initial cloud setup and speed up configuration and implementation.
We must ask ourselves one question – Should I always follow the best practices? There is no right or wrong answer to this question. Our answer is – It depends.
Following the best practices solely because somebody asked us to do so doesn’t make sense. Omitting a set of best practices or implementing only part of it is fine – we just need to make those decisions consciously and know what it means for us when we skip or apply different practices.
If you want to read more about Google Cloud’s best practices, visit the following links:
In the next section, we will dive into blueprints, which are one of the best ways to implement Google Cloud’s best practices and start the journey with Google Cloud.
We’ve covered the setup checklist and best practices of Google Cloud. All those steps bring us closer to the deployment of Google Cloud in a practical, secure, and well-designed way.
Fortunately for us, Google Cloud has prepared many different methods of implementation for its customers. A Google Cloud implementation blueprint is based on Google Cloud best practices. Again, you don’t need to follow all of them; you can choose parts that make the most sense for you and your organization:
- Kubernetes Resource Model (KRM) blueprints: KRM blueprints use Config Connector, part of Anthos Config Management, which allows us to deploy Google Cloud resources using the KRM. The KRM makes it easy to select resources with YAML or JSON declaratively.
To learn how to implement blueprints using the KRM, visit the following link – https://cloud.google.com/anthos-config-management/docs/concepts/blueprints#krm-blueprints.
- Terraform blueprints: For those who prefer to use Terraform and want to use HashiCorp Configuration Language (HCL) to deploy Google Cloud resources, this is also possible. Policies for Terraform blueprints are written as Open Policy Agent constraint templates. Terraform Validator enables client-side policy validation by converting Terraform plans into Cloud Asset Inventory asset metadata, then validates them with OPA policies. This allows the detection of misconfiguration earlier in the deployment pipeline.
To learn how to implement blueprints using Terraform and its HCL language, visit the following link – https://cloud.google.com/anthos-config-management/docs/concepts/blueprints#terraform-blueprints.
We continue our journey with Google Cloud. We started with a high-level overview of the best practices and then we moved on to implementation with various blueprints. In the next section, we will jump into planning compute resources.