feat: enable google site analytics

_config.yml

@@ -16,7 +16,7 @@ keywords: aws, xecuta, rpa, rpa-farm, terraform # add your own keywords or leave
 lang: en # the language of your site (for example: en, fr, cn, ru, etc.)
 icon: ⚛️ # the emoji used as the favicon (alternatively, provide image name in /assets/img/)
 
-url: https://fethiozdol.github.io # the base hostname & protocol for your site
+url: https://thisismypattern.com # the base hostname & protocol for your site
 baseurl: # the subpath of your site, e.g. /blog/. Leave blank for root
 last_updated: false # set to true if you want to display last updated in the footer
 impressum_path: # set to path to include impressum link in the footer, use the same path as permalink in a page, helps to conform with EU GDPR
@@ -118,12 +118,12 @@ contact_note: >
 
 # For Google Analytics, see https://support.google.com/analytics/answer/10447272?hl=en&ref_topic=14088998&sjid=5129943941510317771-SA#zippy=%2Cgoogle-sites
 # and follow the instructions for Google Sites. You will need to create a Google Analytics property and copy the Google tag ID.
-google_analytics: # your Google Analytics measurement ID (format: G-XXXXXXXXXX)
+google_analytics: G-BFVSGSW9BJ # your Google Analytics measurement ID (format: G-XXXXXXXXXX)
 cronitor_analytics: # cronitor RUM analytics site ID (format: XXXXXXXXX)
 pirsch_analytics: # your Pirsch analytics site ID (length 32 characters)
 
 # For Google Search Console, see https://support.google.com/webmasters/answer/9008080?hl=en#meta_tag_verification&zippy=%2Chtml-tag
-google_site_verification: # your google-site-verification ID (Google Search Console)
+google_site_verification: 5Lhp1lN5mNB84LS6y_8GsdoHcwSb29xxGr1LlOvbF5w # your google-site-verification ID (Google Search Console)
 bing_site_verification: # out your bing-site-verification ID (Bing Webmaster)
 
 # -----------------------------------------------------------------------------
@@ -417,10 +417,10 @@ lazy_loading_images: true # enables lazy loading of images (recommended)
 # Optional Features
 # -----------------------------------------------------------------------------
 
-enable_google_analytics: false # enables google analytics
+enable_google_analytics: true # enables google analytics
 enable_cronitor_analytics: false # enables cronitor RUM analytics
 enable_pirsch_analytics: false # enables Pirsch analytics (https://pirsch.io/)
-enable_google_verification: false # enables google site verification
+enable_google_verification: true # enables google site verification
 enable_bing_verification: false # enables bing site verification
 enable_masonry: true # enables automatic project cards arrangement
 enable_math: true # enables math typesetting (uses MathJax)

_posts/2024-07-01-ht-startup-w-devops-p01.md

@@ -21,36 +21,31 @@ related_posts: false
 
 # Foreword
 
-Perhaps it's the banking industry in which I started my IT career, but I've been obsessed with high speed and high quality software delivery ever since I took up platform engineering activities.
+Perhaps it's the banking industry in which I started my IT career, but I've been obsessed with high speed and high quality in software delivery ever since I took up platform engineering activities.
 
-Like at any startup, there are few people writing code, and it may be OK for some to leave software delivery disorganized. Not for us.
-
-We build multiple SaaS for businesses at [Xecuta](https://www.xecuta.co.uk) and it was obvious from day 0 that we had to set our solid architecture principles.
-
-It may be our early days, but our architecture principles have already given us the confidence in managing AWS resources effectively.
+We build multiple SaaS for businesses at [Xecuta](https://www.xecuta.co.uk). We have only few people writing code, like at any startup, but it was not OK for us to leave software delivery disorganized. It may be our early days, but our architecture principles have already given us the confidence in managing AWS resources effectively.
 
 In the first part of this series, I'll talk about our architecture principles and our design thinking which led us to organize our AWS environments and choose tools and services.
 
 ## Xecuta's Architecture Principles
 
-Here's our 10 architecture principles that we agreed before we wrote our first line of code.
+Here's our 10 architecture principles that we agreed before we wrote first line of code.
 
-1. Build cloud-native and serverless architectures, because we want maximum agility and minimum OpEx from day 0 with a near-linear trajectory for OpEx:Revenue ratio at short-to-medium long term.
-2. Build services powered by Amazon Web Services (AWS), because they provide the best public cloud services around cloud-native and serverless architectures.
-3. Organize our AWS environment using AWS Organizations and adopt AWS recommended [Basic Organization with infrastructure services](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/basic-organization.html#basic-organization-with-infrastructure-services) pattern
+1. Build cloud-native and serverless architectures, because we want maximum agility and minimum OpEx from day 0 with a near-linear trajectory for OpEx:Revenue ratio at short-to-medium long term
+2. Build services powered by Amazon Web Services (AWS), because they provide the best public cloud services around cloud-native and serverless architectures
+3. Organize our AWS environment using AWS Organizations
+   - We adopted AWS recommended [Basic Organization with infrastructure services](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/basic-organization.html#basic-organization-with-infrastructure-services) pattern
 4. Use infrastructure-as-code for not only anything-on-cloud, but also to provision and manage
-
-- AWS accounts
-- Git repositories
-- CI/CD pipelines
-
+   - AWS accounts
+   - Git repositories
+   - CI/CD pipelines
 5. Security from day 0
    - Use SSO to access anything
    - Use free or low-cost security services where possible
 6. Use Open Source Software from day 0
 7. KISS (Keept It Simple, Stupid)
 8. Adopt [The Twelve-Factor App](https://12factor.net/) methodology
-9. Continuous Delivery from day 0
+9.  Continuous Delivery from day 0
    - Use Static Code Analysis from day 0
    - Adopt [trunk-based development](https://trunkbaseddevelopment.com/) with branch-to-release strategy
    - Multi git-repo strategy with isolated and independent CI/CD pipelines
@@ -60,7 +55,7 @@ Here's our 10 architecture principles that we agreed before we wrote our first l
     - Use automation for semantic versioning and generating CHANGELOG
     - Use package managers like npm or pip to manage code dependencies
 
-> Re: #3: You may want to look at [Basic organization with CI/CD as a separate function](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/basic-organization.html#basic-organization-with-cicd-as-a-separate-function) as well, but we decided to make Infrastructure OU enclose Deployments OU for simplicity.
+> Re: principle #3: You may want to look at [Basic organization with CI/CD as a separate function](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/basic-organization.html#basic-organization-with-cicd-as-a-separate-function) as well, but we decided to make Infrastructure OU enclose Deployments OU for simplicity.
 
 ## How it's going so far
 
@@ -80,8 +75,8 @@ At the time of writing, Xecuta has:
   - Policy-as-code for infrastructure-as-code
 - 7,000+ lines of all code
 
-> We are just 1 full-time and 1 part-time developers \
-> AND AWS bill for **non-workload OUs** last month was only **$19.90**
+> We are just 1 full-time and 1 part-time developers. \
+> AWS bill for **non-workload OUs** last month was only **$19.90**.
 
 ---
 
@@ -93,7 +88,7 @@ Assume we have a single AWS account, which becomes our AWS Organizations managem
 
 With respect to our principles #3 and #4, we want all organization OUs and member accounts to be managed by infrastructure-as-code.
 
-For this purpose, we have 2 single infrastructure-as-code Git repositories:
+We have 2 single infrastructure-as-code Git repositories for this purpose:
 
 - AWS Accounts Management
 - Git repositories Management
@@ -168,7 +163,7 @@ Assume we have a CRM system, in which Customer Service exposes an API for our we
 
 In another scenario, we may want to have a centralised Email microservice in our Core Services, and we'd like it to use SES identity domain, which is environment-agnostic therefore managed outside our workloads, in our Shared Services.
 
-In short, resources can be both intra-workload and inter-workload dependencies.
+In short, AWS resources can be intra-workload or inter-workload dependencies, or both.
 
 ```mermaid
 flowchart TD
@@ -199,7 +194,7 @@ classDef cmp color:#fff, fill:#b509ac, stroke:#303;
 
 ---
 
-## Inter-Workload and Intra-Workload Resource Dependencies
+## Inter-Workload and Intra-Workload Dependencies in Infrastructure-as-Code
 
 Terraform has quickly become the de-facto in infrastructure-as-code but it does not fill the gap between _infrastructure_ and _application code_, and that's expected, because it's not designed for software development.
 
@@ -209,7 +204,7 @@ Whilst this approach has its many pros, there are some important drawbacks of us
 
 1. Import & Export functionality in CloudFormation creates physical dependencies between CloudFormation stacks, and this may cause human interventions during major refactoring activities. Imagine logging into prod environment and deleting CloudFormation stacks manually. That's not going to work for us.
 2. Cloud Development Kits like AWS CDK have brought the power of programming languages into infrastructure-as-code, enabling full stack engineering and rapid software development. Enterprises can produce reusable and modular CDK modules as `npm`, `pip`, or `go` packages, but there aren't many reusable CDK modules available in the wider community, whereas there are many production-ready modules available in Terraform today.
-3. This is my personal opinion and I'm sure many of you will disagree with this, but Id don't buy into using programming languages for infrastructure-as-code. Although I've been using AWS CDK for my other projects lately, I'm still an advocate of using more limited and strict languages like YAML for infrastructure-as-code. I believe "The best code is no code at all" is true for infrastructure-as-code. Even the simplest programming language brings some complexity overhead; you need more knowledge to write good code in a programming language and you also need to perform maintenance for runtime environment upgrades. With HCL or YAML, there is not much of a major room for any runtime upgrades or weird runtime errors or any unintended behaviours.
+3. This is my personal opinion and I'm sure many of you will disagree with this, but I don't buy into using programming languages for infrastructure-as-code. Although I've been using AWS CDK for my other projects lately, I'm still an advocate of using more limited and strict languages like YAML for infrastructure-as-code. I believe "The best code is no code at all" is true for infrastructure-as-code. Even the simplest programming language brings some complexity overhead; you need more knowledge to write good code in a programming language and you also need to perform maintenance for runtime environment upgrades. With HCL or YAML, there is not much of a major room for any runtime upgrades or weird runtime errors or any unintended behaviours.
 
 Third is a personal opinion. We could have lived with the first drawback, but the second one is the deal breaker. We're quite limited on resources (people and time); we can't maintain 1000s of lines of infrastructure-as-code to reinvent the wheel.
 
@@ -236,13 +231,12 @@ Obviously, Terraform would not be good enough on its own for software developmen
 
 Thanks to trunk based development, strict conventional commits and automated semantic versioning, our builds produce immutable builds that we build once and deploy many. CD pipelines understand the target environment from the artefact version and perform Terraform plan & apply, which actually does CloudFormation stack create/update in the background.
 
-Finally, if the Workload Infra Base gets very big, we can split into 2 or more repositories and orchestrate their deployments using [Terragrunt](https://terragrunt.gruntwork.io/).
-
-We were quite happy with our experiment and decided to follow this pattern in building SaaS at Xecuta. I understand our approach may seem too complex or unnecessary for some, but again, best out of two worlds!
+Finally, if the Workload Infra Base gets very big, we can segregate into 2 or more repositories and orchestrate their delivery using [Terragrunt](https://terragrunt.gruntwork.io/).
 
+We were quite happy with our experiment and decided to follow this pattern in building SaaS at Xecuta. I understand our approach may seem too complex or unnecessary for some, but again, best out of two worlds:
 - Thanks to Terraform, we are able to reuse terraform modules produced by the community and this keep LoC of our infrastructure-as-code low
 - Thanks to AWS SAM, we can develop and test locally
-- And we can manage inter-workload and intra-workload dependencies in a consistent and reliable manner
+- We can manage inter-workload and intra-workload dependencies in a consistent and reliable way
 
 I hope you enjoyed my first blog post about Workload Infra Base pattern with hybrid implementation using AWs SAM and Terraform.