Skip to content

> Hello, World! I am

Muyideen Morenigbade

Cloud Platform & DevOps Engineer

I design and automate reliable cloud platforms across Azure and AWS using Terraform, Kubernetes and GitOps.

  • Cloud Infrastructure
  • Kubernetes
  • Platform Engineering
  • Infrastructure as Code
  • DevOps
Muyideen Morenigbade

Engineering impact

What the work changed

Faster deployments
End-to-end CI/CD pipelines on GitHub Actions and Azure DevOps.
Less manual provisioning
Environments built from Terraform and ARM Templates across Azure and AWS.
Lower cloud spend
Azure Advisor rightsizing, Reserved Instances and automated shutdown schedules.
Sustained availability
Azure Monitor, Prometheus and Grafana with proactive alerting.

# from roles at Perizer and Teknowledge — see Experience below

Selected work

Case study 01

Darey.io Cloud & DevOps Labs

Source
cloud-devops-labs.arch

Problem

Bootcamp work usually leaves a portfolio with either a wall of disconnected exercises or one polished project that hides how the fundamentals underneath it were actually learned — no way for a reviewer to see the progression from a Linux shell to a deployed system.

Solution

49 numbered labs, grouped by domain in the repository's own learning path — Linux and shell scripting, then core AWS services, Docker, Jenkins/GitHub Actions CI, Kubernetes fundamentals, Terraform and Ansible — closing in two capstones: a Terraform-provisioned WordPress stack on AWS (VPC, RDS, EFS, ALB, ASG) and cluster observability via Prometheus.

Engineering decisions

  • Each lab is its own directory with its own working code, not a written summary of what was done — the shell scripts, Terraform configs and Ansible playbooks run as committed.
  • The AWS capstone splits infrastructure into a dedicated VPC, RDS and EFS rather than one flat template — the same separation of concerns that shows up in the projects below.
  • Terraform work builds toward a reusable EC2 and security-group module rather than stopping at one-off resource blocks.
  • Monitoring is set up twice — Node Exporter on a bare Linux host, then as a Kubernetes DaemonSet — so the same tool is exercised in both environments it actually runs in.
LinuxBashAWSDockerKubernetesTerraformAnsiblePrometheusGitHub Actions

Case study 02

Multi-Cloud Terraform Module Library

Source
terraform-modules-and-pipelines.arch

Problem

Infrastructure code and the pipeline that runs it usually get rewritten per repository. Each copy drifts — a different module layout, a different set of workflow steps, and its own way of authenticating to the cloud.

Solution

One repository holding eighteen Terraform modules across Azure, AWS and GCP, published alongside the automation that consumes them: composite actions for cloud login and fmt/validate, and callable plan/apply/destroy workflows other repositories reference by tag.

Engineering decisions

  • Cloud login is a composite action, so OIDC federation is configured once and inherited — consuming repositories store no long-lived cloud credentials.
  • plan, apply and destroy are `workflow_call` workflows rather than copied YAML, so a fix to the pipeline reaches every repository that references it.
  • Consumers pin a tag rather than tracking the default branch, so a module change never lands in someone else’s apply unannounced.
  • Dependabot watches the action and provider versions the modules pin, so upgrades arrive as reviewable pull requests.
TerraformGitHub ActionsAzureAWSGCPOIDCDependabot

Case study 03

Kubernetes WebApp Operator

Source
python-kubernetes-operator.arch

Problem

Running an application on Kubernetes means keeping a Deployment, a Service and an HPA in step by hand. One idea — "this app, at this size" — spread across three manifests that drift apart.

Solution

A WebApp custom resource plus a kopf controller that reconciles it into those three objects, validates the spec before it is ever stored, and writes observed health back to the resource status.

Engineering decisions

  • The CRD carries an OpenAPI schema, so an invalid spec is rejected by the API server rather than crashing the controller at reconcile time.
  • Child objects are created with owner references, so deleting a WebApp garbage-collects its Deployment, Service and HPA without the controller being involved.
  • A kopf timer re-reads pod health on an interval and syncs it to `status`, so the resource stays truthful between watch events.
  • RBAC is scoped to the resources the controller actually touches rather than granted cluster-admin.
  • pytest runs with coverage in CI before the image is built and published.
PythonkopfKubernetesCRDsRBACDockerpytestGitHub Actions

Case study 04

AKS GitOps Pipeline

Source

Problem

A pipeline that ends in `kubectl apply` has to hold cluster credentials, and it leaves the cluster’s real state undocumented — what is running is whatever the last job happened to do.

Solution

Terraform provisions AKS and its supporting resources. CI builds and pushes the image, rewrites the tag in the manifest and commits it; ArgoCD sees the commit and applies it.

Engineering decisions

  • The pipeline’s last step is a git commit, not a cluster call — CI never holds kubectl credentials.
  • The deployed tag is a line in a committed manifest, so cluster state is readable from the repository and a rollback is a git revert.
  • Application secrets come from Key Vault rather than pipeline variables.
  • The cluster is composed from Terraform modules rather than one flat root configuration, so environments differ by inputs instead of by copies.
TerraformKubernetesAzureArgoCDDockerKey VaultGitHub Actions

Case study 05

EKS GitOps Pipeline

Source

Problem

The same GitOps question on AWS, where cluster identity is a set of IAM roles rather than a managed identity — and where getting those roles wrong is the usual reason a cluster half-works.

Solution

Terraform builds the EKS cluster and its IAM roles as separate modules, and a containerised Django application is delivered through an ArgoCD sync manifest rather than applied by hand.

Engineering decisions

  • EKS and IAM are separate modules, so node and service-account roles can be reviewed on their own instead of buried in the cluster definition.
  • Delivery is an ArgoCD sync manifest, so the pipeline stops at the registry and the cluster pulls its own changes.
  • The workload is a real containerised Django app rather than a placeholder image, so the build and rollout paths are actually exercised.
TerraformKubernetesAWSEKSArgoCDIAMDocker

More infrastructure builds

8 repositories

Experience

Cloud/DevOps Engineer

Perizer2025 – present

Key impact

  • Led design and implementation of end-to-end CI/CD pipelines using GitHub Actions and Azure DevOps, reducing deployment times by 60%.
  • Automated infrastructure provisioning with Terraform and ARM Templates across Azure and AWS, eliminating manual configuration drift.
  • Built and managed containerised workflows using Docker and Kubernetes (AKS/EKS), improving platform reliability and fault tolerance.
  • Implemented monitoring and alerting using Azure Monitor, Prometheus, and Grafana, maintaining 99.9% service availability.
  • Enforced cloud security through Azure Policy, RBAC, and automated compliance checks, reducing audit findings.

GitHub ActionsAzure DevOpsTerraformARM TemplatesAzureAWSDockerAKSEKSAzure MonitorPrometheusGrafanaAzure PolicyRBAC

Azure Cloud Support Engineer

Teknowledge2023 – 2026

Key impact

  • Designed and deployed scalable cloud environments using Terraform IaC, reducing manual provisioning time by 40%.
  • Hardened cloud environments with Azure Policy and RBAC, ensuring 100% compliance with ISO 27001 standards.
  • Built and maintained Azure DevOps YAML pipelines for automated CI/CD, enabling daily production deployments with zero downtime.
  • Implemented Azure Monitor and Log Analytics with custom dashboards and proactive alerting, achieving 99.99% uptime.
  • Reduced monthly cloud spend by 30% through Azure Advisor recommendations, Reserved Instances, and automated shutdown schedules.

TerraformAzureAzure DevOpsAzure PolicyRBACISO 27001Azure MonitorLog AnalyticsAzure AdvisorReserved Instances

Technical Arsenal

cloud: Cloud

AWSAzureGCPDigitalOcean

containers: Containers

KubernetesDockerArgoCDAKSEKS

iac: IaC

TerraformARM TemplatesCloudFormation

ci_cd: CI/CD

GitHub ActionsAzure DevOpsJenkinsCircleCI

observability: Observability

PrometheusGrafanaAzure MonitorCloudWatchNew Relic

scripting: Scripting

PythonPowerShellBashYAML

security: Security

Azure PolicyRBACIAMMFAMicrosoft Entra

networking: Networking

DNSVPNLoad BalancingWAFFirewallsVNet

Education

Infrastructure

This portfolio is infrastructure too.

I didn’t just build a website. I built and automated the infrastructure behind it — Terraform, GitHub Actions, OIDC and Azure — and it deploys itself on every push to main.

Infrastructure as code
Terraform provisions every Azure resource, with remote state in a storage account.
CI/CD
GitHub Actions plans and applies on push to main, then uploads the built site.
Authentication
OIDC federated identity — no long-lived Azure credentials stored as repository secrets.
Hosting
Azure Static Web Apps, serving HTML prerendered at build time for every route.
Visitor counter
A managed Function increments a row in Azure Table Storage and returns the total.

Live

45d10:40:56

since the first deploy

Azure Static Web Apps · since 2026-07-03

Visitors

Visitor count unavailable

count unavailable

Azure Table Storage

Read the architecture

~/muyideen · contactopen to work

Let’s build reliable infrastructure.

Open to Cloud, DevOps and Platform Engineering roles. Email is the fastest way to reach me.

Get in touch