# Alex Khaerov — full site content > Alex Khaerov — technology leader building cloud platforms, developer infrastructure, and engineering teams at scale. Director, Head of GTIS Cloud at Prudential plc, Singapore. This document concatenates every page of https://hayorov.me/ as Markdown (31 pages, generated 2026-10-04). Each page starts with a horizontal rule, an HTML comment holding its canonical URL, and a metadata list. A shorter index lives at https://hayorov.me/llms.txt; structured data endpoints are described at https://hayorov.me/ai/. # Part 1 — Pages --- # About Me - URL: https://hayorov.me/about/ - Markdown: https://hayorov.me/about/index.md - JSON: https://hayorov.me/about/index.json - Published: 2021-07-03 - Updated: 2026-10-04 > Alex Khaerov — technology leader with 15+ years in cloud infrastructure, platform engineering, and AI-driven automation. Director, Head of GTIS Cloud at Prudential plc, Singapore. Guest lecturer, speaker, patent holder, open-source contributor. Technology leader with 15+ years building cloud infrastructure, developer platforms, and engineering organizations. I specialize in large-scale distributed systems, cloud-native architectures, and AI-driven automation — with a focus on turning platform engineering into a competitive advantage. I lead global teams, ship self-service infrastructure platforms, and bridge the gap between technical execution and business outcomes. Holder of 3 US patents in cloud integration, active open-source contributor, and a regular speaker at international conferences. ## ⭐️ Core Competencies - **Cloud Infrastructure & Platform Engineering** – Designing and operating multi-region cloud foundations, networking, and developer platforms. - **AI-Driven Automation & GenAI** – Applying AI/ML to infrastructure operations, cost optimization, and self-service workflows. - **Engineering Leadership** – Building and scaling global engineering teams with strong DevOps culture and delivery discipline. - **Strategy & Business Alignment** – Connecting infrastructure investments to measurable business outcomes and competitive differentiation. - **Cloud-Native Architecture** – Kubernetes, IaC, multi-cloud, SaaS/PaaS/IaaS design with resilience and security built in. ## 👔 Professional Experience - **Director, Head of GTIS Cloud** [Prudential plc](https://www.prudential.com.sg/), Singapore\ _Dec 2019 – Present_\ I lead multi-cloud infrastructure, AI platforms, and developer experience across 12 Asia-Africa markets at Prudential plc. My responsibilities span platform engineering, Internal Developer Platforms (IDPs), cloud governance, and engineering culture at Fortune 500 scale. Key achievements include architecting the Prudential Global AI Lab infrastructure (2024) in partnership with Google Cloud and Singapore MDDI, establishing unified developer platforms serving 15,000+ employees, and maintaining 99.85% platform availability while optimizing infrastructure costs by 15%. I serve as HashiCorp Customer Advisory Board (E-CAB) Singapore representative and Google Cloud Innovators member, bridging industry advisory roles with hands-on platform engineering leadership. Additionally, I contribute as a guest lecturer in platform engineering and cloud architecture, connecting Fortune 500 practice with academic computing programs. - **Software Engineering Manager** [Chainstack](https://chainstack.com) ([Acronis'](https://acronis.com) spinoff), Singapore\ _Sep 2018 – Dec 2019_\ I had the unique opportunity to shape the direction of a nascent engineering team focused on infrastructure-intensive cloud services for digital ledger technology. My responsibilities ranged from talent acquisition and team management to the strategic planning and execution of our technology road map. I successfully assembled and led a high-performing global engineering team, guided by the principles of cloud-native and micro service-oriented platform architecture. We worked in close collaboration with product managers and owners to align our technical initiatives with the company's strategic priorities. Over a span of just 9 months, we successfully brought our vision to life by releasing the first version of the service. This accomplishment was a testament to our effective teamwork, meticulous attention to core architecture, and close collaboration with early adopters, ensuring their needs and feedback were integrated into our development process. Through this role, I honed my ability to work under pressure and deliver exceptional results within tight deadlines. I was instrumental in driving the projects from conception to successful launch, proving my capacity to operate strategically, shape robust technology solutions, and contribute significantly to the company's growth plans. In essence, I led from the front, uniting leadership skills, technical expertise, and strategic foresight to achieve remarkable results. - **Software Engineering Manager** Ingram Micro Cloud, Irvine, CA\ _Dec 2015 – Sep 2018_\ I oversaw both the technical and operational aspects of a dynamic Software Development Unit consisting of approximately 35 developers across three teams, including one remote. My day-to-day responsibilities encompassed comprehensive project management – from planning and architectural design to execution of development projects in coordination with program managers and various other departments. I was deeply involved in the technical aspects, participating in code reviews and acceptance testing to ensure the delivery of high-quality software solutions. Despite an intensive meeting schedule, which covered everything from ongoing projects to new initiatives and ideation sessions, I was able to maintain a keen focus on strategic execution and team productivity. I was at the helm of a talented software development team dedicated to designing, developing, and implementing the APS Connect service. Our technology stack included Python/Django-Flask, JS/Vue-Angular, and we leveraged the capabilities of cloud hosting in GCP/AWS. Throughout my tenure, I effectively combined leadership skills, technical acumen, and strategic planning to drive progress, innovation, and team growth. - **DevOps Manager & Sr. Software Developer** [Parallels](https://parallels.com), Moscow, Russia\ _May 2011 – Dec 2015_\ I had the unique opportunity to work on the Parallels Business Automation product. In my dual role, I led a multi-disciplinary team of engineers to develop and enhance the infrastructure and virtualization aspects of the product. I contributed both as a hands-on engineer and a strategic leader, focusing on the seamless integration of development and operations for efficient workflows and high-quality software solutions. As a DevOps manager, I implemented strategies and processes to foster a culture of continuous integration and deployment, which expedited the development cycle while maintaining high standards of reliability and stability. I worked closely with other teams to bridge gaps and improve communication, fostering an environment of collaboration and collective problem-solving. As a Senior Software Engineer, I leveraged my technical prowess to contribute to the design, development, and deployment of key features. I also played a vital role in problem-solving and code optimization, striving to maintain the product's performance at an optimal level. ## 🎓 Education 2025-2026 Master of Business Administration, _MBA_ Quantic School of Business and Technology, US. 2006-2011 M.Eng (Master of Engineering), _Communication networks and systems_ Volga State University of Telecommunications and Informatics, Russia. ## 🎖️ Professional Qualifications - [GCP Professional Cloud Architect](https://google.accredible.com/4db3ac85-6442-45d5-8cc7-e6087fbe98a1) - [GCP Professional Cloud Security Engineer](https://www.credential.net/b92ced5a-134b-4aa5-b216-53c74fd6027b) - [GCP Associate Cloud Engineer](https://www.credential.net/f0c6c335-ddcd-4e66-a657-88964970ffa9) - [HashiCorp Certified: Terraform Associate](https://www.credly.com/badges/16331cd7-3c14-41f9-afd0-717f5a216485) - [Kubernetes Networking and Security using Calico](https://courses.academy.tigera.io/certificates/39ae5d6f9dc748fd8946d8e7632bb00a) ## 📜 Patents - US20180300115A1: [Technologies for creating and distributing integration connectors in a cloud service brokerage system](https://patents.google.com/patent/US20180300115A1/en?inventor=Khaerov) - US20180191718A1: [Technologies for securely extending cloud service APIs in a cloud service marketplace](https://patents.google.com/patent/US20180191718A1/en?inventor=Khaerov&oq=inventor:Khaerov) - US20190132410A1: [System and method for integrating cloud applications into a cloud service broker platform using an automated, universal connector package](https://patents.google.com/patent/US20190132410A1/en?inventor=Khaerov&oq=inventor:Khaerov) ### See Alex Khaerov’s profile on [Google Scholar](https://scholar.google.com/citations?user=pphTJAoAAAAJ) --- ## 🎓 Academic & Research I serve as a **guest lecturer** in platform engineering and cloud architecture, bridging Fortune 500 infrastructure practice with university computing programs. My academic interests focus on Internal Developer Platforms (IDPs), multi-cloud architecture, AI infrastructure, and socio-technical systems at enterprise scale. **Research Contributions**: - 3 US Patents in cloud automation and platform integration - 3 Academic publications in Next Generation Networks - 15+ Technical articles (50,000+ cumulative views) - 14 Conference presentations (2019-2025) For a comprehensive overview of my academic credentials, research interests, patents, publications, and professional contributions, see my [**Academic Profile**](https://hayorov.me/academic/). --- ## 📢 Public Speaking I speak regularly at international conferences and industry panels on cloud infrastructure, platform engineering, AI adoption, and DevOps leadership. Recent engagements include keynotes and panels at Tech Week Shanghai, HashiDays Singapore, Cloud Expo Asia, F5 AppWorld, and DevOps Summit Singapore. I have had the privilege to speak at numerous conferences and meetups across the globe. Here are some of my contributions: | Year | Topic | Conference | Location | | ---- | ----- | ---------- | -------- | | 2026 | [From Zero Trust to Autonomous Containment: Engineering Cyber Resilience in Multi-Cloud](https://www.linkedin.com/posts/cswaconference1080-x-13501-1-share-7503633373848854528-FtB5/) | [Cyber Security World Asia 2026](https://www.singaporetechnologyweek.com/cyber-security-world) | Singapore | | 2026 | [Design an Automation Fabric for the Agentic Era](https://www.ibm.com/events/think/singapore) | [IBM Think Singapore](https://www.ibm.com/events/think/singapore) | Singapore | | 2026 | [Panel: Enabling High-Velocity Engineering with Cloud Platforms and AI](https://chinatechbridge.com/shows/21/38.html) | [Tech Week Shanghai](https://techweeksh.digitalexpo.com/pc/micro-page?microPageId=10011052025072300017532510497859728597511753186&channelId=0021927269967692611584&contentId=10011052025072300017532510497859728597511753186&eid=10015032025071600017526323194428928557583597996&tohome=true) | Shanghai | | 2026 | [Advisory Board Member](https://exito-e.com/devopssummit/singapore/#speakers) | [Exito DevOps Summit Singapore](https://exito-e.com/devopssummit/singapore/) | Singapore | | 2025 | [Automating Infrastructure Management with Cloud-Native Services](https://www.singaporetechnologyweek.com/tech-week-singapore-mainstage-2025) | [Cloud & AI Infrastructure Asia](https://www.singaporetechnologyweek.com/tech-week-singapore-mainstage-2025) | Singapore | | 2025 | [Panel: AI & Automation: Enhancing and Streamlining DevOps Workflows](https://forefrontevents.co/event/devops-summit-singapore-2025/) | [DevOps Summit Singapore 2025](https://forefrontevents.co/event/devops-summit-singapore-2025/) | Singapore | | 2025 | [Anatomy of Self-Service Enterprise Infra Platforms](https://www.hashicorp.com/en/conferences/hashidays/singapore) | [HashiDays 2025 in Singapore](https://www.hashicorp.com/en/conferences/hashidays/singapore) | Singapore | | 2025 | [Panel: Shadow AI and LLM Security – Risks, Governance, and the Innovation Balance](https://www.linkedin.com/posts/tsangstanley_cybersecurity-aisecurity-aigovernance-activity-7334120539227115520-6mXb/) | [F5 AppWorld 2025](https://www.f5.com/appworld) | Singapore | | 2025 | [Panel: Unpacking the Cloud & Infrastructure Foundations Needed to Thrive in the AI Age](https://forefrontevents.co/event/cloud-it-infrastructure-summit-sing/) | [Cloud & IT Infrastructure Summit](https://forefrontevents.co/event/cloud-it-infrastructure-summit-sing/) | Singapore | | 2024 | [GenAI Adoption Path for Self-Services & Internal Developer Platforms](https://1drv.ms/b/s!AnRTaPU_RuJRtDe0sk7HLLGjS8zh?e=K24d4D) | [Cloud Expo Asia](https://web.archive.org/web/20240911192904/https://www.cloudexpoasia.com/2024-conference-programme/genai-adoption-path-for-self-services-internal-developer-platforms) | Singapore | | 2023 | [Terraform and ArgoCD: Managing k8s Lifecycle](https://1drv.ms/b/s!AnRTaPU_RuJRrkpFEP2YS6fGPbJg?e=AVbNz9) | [Kubernetes User Group Meetup](https://www.meetup.com/k8s-sg/events/292826519/) | Singapore | | 2022 | [Facilitating and Simplifying AIOps Platform Adoption with Chaos Mesh](https://www.youtube.com/watch?v=tQSYyAGtJaM) | [Bay Area Cloud Native Infra Meetup](https://www.meetup.com/Bay-Area-Cloud-Native-Database-Meetup/events/283613507/) | San Mateo, CA | | 2020 | [Workshop: Cloud-Native Pipelines with Tekton](https://summit.fossasia.org/event/schedule.html#6088) | [FOSSASIA Summit](https://summit.fossasia.org/) | Singapore | | 2020 | [Pouekhavshie - Singapore (Russian)](https://linkmeup.ru/blog/541.html) | [Linkmeup Podcast](https://linkmeup.ru) | Singapore | | 2019 | [Securing Containers: A Necessary Precaution](https://www.youtube.com/watch?v=QltHmfevCo8&list=PLtFn4-Uxnqyn2ZnJ8iaCBTvTzuMvnGQeb&index=16) | [DevOps Conference](https://devopsconf.io/) | Moscow | | 2019 | [Entangled in Dependencies: A Look at Pipenv & Poetry](https://speakerdeck.com/hayorov/entangled-in-dependencies-pipenv-and-poetry) | [Python User Group SG](https://pugs.org.sg/) | Singapore | | 2019 | [Creating a "Family Budget" in Minutes with Chainstack](https://speakerdeck.com/hayorov/family-budget-in-minutes-with-chainstack) | [Law Blockchain Festival](https://www.meetup.com/Legal-Technology-Singapore/events/261249518/) | Singapore | | 2019 | [Entering the Service Mesh Era: Our First Experience with Istio](https://speakerdeck.com/hayorov/welcome-to-the-service-mesh-era) | [Singapore Kubernetes User Group](https://www.meetup.com/Singapore-Kubernetes-User-Group/) | Singapore | | 2019 | [Quick Start to Quorum with Chainstack](https://speakerdeck.com/hayorov/quorum-in-minutes-with-chainstack) | [DApps Dev Club](https://dappsdev.org/blog/2019-04-12-dapps-dev-club-4th-session-roundup/) | Singapore | ## 🧩 Beyond Work Engineer at heart — I maintain open-source projects like [helm-gcs](https://github.com/hayorov/helm-gcs) (Helm chart repositories on GCP, Helm 4 compatible) and stay close to the tools I advocate for. Outside of work, I ride road bikes across Singapore and beyond, build FPV drones, and collect laptop stickers — see my [devlids](https://devlids.com/lids/hayorov). Strava profile: https://www.strava.com/athletes/39930728 (the HTML page embeds a ride heatmap and activity summary). --- # Academic Profile - URL: https://hayorov.me/academic/ - Markdown: https://hayorov.me/academic/index.md - JSON: https://hayorov.me/academic/index.json - Published: 2026-05-17 - Updated: 2026-08-02 > Alex Khaerov — Academic credentials, research interests, patents, publications, and professional contributions in cloud infrastructure, platform engineering, and distributed systems. **Alex Khaerov** Director, Head of GTIS Cloud Prudential plc, Singapore 📧 alex@hayorov.me · 🔗 [LinkedIn](https://linkedin.com/in/alexkhaerov) · 💻 [GitHub](https://github.com/hayorov) --- ## Research Interests My work bridges industry practice and academic inquiry in large-scale distributed systems, focusing on the organizational and technical dimensions of cloud infrastructure at enterprise scale. **Primary Areas**: - **Platform Engineering & Internal Developer Platforms (IDPs)** — Cognitive load reduction, self-service infrastructure, developer experience optimization - **Omni-Cloud Architecture & Multi-Cloud Governance** — Cloud-agnostic design patterns, cross-provider orchestration, vendor neutrality strategies - **AI Infrastructure & MLOps** — Production ML/AI platforms, model deployment pipelines, GPU/accelerator orchestration - **Cloud-Native Systems** — Kubernetes ecosystems, container orchestration, service mesh architectures - **Infrastructure Automation & GitOps** — Declarative infrastructure, infrastructure-as-code, continuous reconciliation **Interdisciplinary Interests**: - Socio-technical systems in large-scale infrastructure organizations - Developer Experience (DevEx) and cognitive load theory in platform design - FinOps and cloud economic optimization at Fortune 500 scale - Site Reliability Engineering (SRE) practices and organizational patterns **Industry-Academia Engagement**: - Prudential Global AI Lab partnerships with NUS, SMU, Republic Polytechnic, Singapore Polytechnic (2024–Present) - Guest lecturer in platform engineering and cloud architecture - Active participation in Singapore technology ecosystem (SCS, Python User Group Singapore, IEEE) --- ## Education **Executive Master of Business Administration (EMBA)** Quantic School of Business and Technology | 2025–2026 (Expected Oct 2026) *Focus*: Strategy, Leadership, Finance, Innovation Management **Master of Engineering (M.Eng) with Honors** Povolzhskiy State University of Telecommunications and Informatics (PSUTI) | 2006–2011 *Thesis*: Next Generation Networks (NGN) Platform Architecture *Recognition*: Best Postgraduate Student Award (2011) **Doctoral Studies** (Unfinished, transitioned to industry) PSUTI | 2011–2012 *Research*: Dynamic Virtual Private Network Technologies --- ## Patents **Granted U.S. Patents** (3 patents in cloud automation and platform integration): 1. **[US 20180300115A1](https://patents.google.com/patent/US20180300115A1)** — Technologies for creating and distributing integration connectors in a cloud service brokerage system (Filed: Apr 2017, Published: Oct 2018, Assignee: Ingram Micro Inc.) 2. **[US 20180191718A1](https://patents.google.com/patent/US20180191718A1)** — Technologies for securely extending cloud service APIs in a cloud service marketplace (Filed: Dec 2016, Published: Jul 2018, Assignee: Ingram Micro Inc.) 3. **[US 20190132410A1](https://patents.google.com/patent/US20190132410A1)** — System and method for integrating cloud applications into a cloud service broker platform using an automated, universal connector package (Filed: Oct 2017, Published: May 2019, Assignee: Ingram Micro Inc.) *Thematic Focus*: Platform extensibility, multi-vendor integration, automation frameworks — foundational concepts applicable to contemporary Internal Developer Platform (IDP) design and omni-cloud architectures. --- ## Publications ### Academic Publications **Roslyakov A.V., Grebeshkov A.U., Vanyashin S.V., Khaerov A.A.** (2012). *Multiservice Platforms of the Next Generation Networks. Volume 2: Foreign Manufacture Systems*. Samara: PSUTI Publishing. 344 pages. (Contributing author — technical analysis of international NGN platforms) **Roslyakov A.V., Kudryavceva E.N., Lysikov A.A., Khaerov A.A.** (2012). "The Next Generation Network Multiservice Platform Equipment Database." *Electronic Resources Industry Foundation «Science and Education»*, Registration Certificate No. 18650, Russian Federation. **Roslyakov A.V., Kudryavceva E.N., Lysikov A.A., Khaerov A.A.** (2012). "Next Generation Networks Platform's Portal." *Electronic Resources Industry Foundation «Science and Education»*, Registration Certificate No. 18651, Russian Federation. ### Professional & Technical Publications **Platform Engineering & IDP Series** (2024–2025): - **Khaerov, A.** (2024). "Part 2: Why Building IDPs is a Challenging Business?" *Medium*. https://akhaerov.medium.com/part-2-why-building-idps-is-a-challenging-business-41112f2fb834 *Analysis of organizational, technical, and cultural barriers in Internal Developer Platform adoption at enterprise scale* - **Khaerov, A.** (2024). "Part 1: IDPs – What Comes to Your Mind?" *Medium*. https://akhaerov.medium.com/part-1-idps-what-comes-to-your-mind-3127269b2a6e *Conceptual framework for understanding platform engineering value propositions and IDP design patterns* - **Khaerov, A.** (2025). "What Fast-Food Order Screens Can Teach Us About Broken Observability" *Medium* (pending publication) *User experience design patterns in observability platforms, drawing parallels from consumer technology* **Cloud Infrastructure & Security** (2019–2020): - **Khaerov, A.** (2020). "Could Containers be Secured?" *Habr*. - **Khaerov, A.** (2019). "Helm Security" *Habr*. - **Khaerov, A.** (2019). "Public and Private Smart Contracts with JP Morgan Quorum" *Habr*. - **Khaerov, A.** (2024). "Comparison of UFW, iptables, and nftables on Alpine Linux" *Medium*. **Publication Metrics**: 15+ technical articles, cumulative 50,000+ views (2011–2025) **Platforms**: [Medium](https://akhaerov.medium.com/), [Habr](https://habr.com/en/users/allexx/articles/), [SpeakerDeck](https://speakerdeck.com/hayorov) --- ## Conference Presentations **Selected Talks** (14 presentations, 2019–2025): **HashiDays 2025 Singapore** | Leadership Track "Anatomy of Self-Service Enterprise Infrastructure Platforms" *IDP design patterns, developer cognitive load reduction, omni-cloud self-service enablement* **Cloud Expo Asia 2024** | Singapore (TechWeek Singapore) "GenAI Adoption Path for Self-Services & Internal Developer Platforms" *AI integration in platform engineering workflows, Prudential AI Lab case study* **Bay Area Cloud Native Infrastructure Meetup 2022** | San Mateo, California "Facilitating and Simplifying AIOps Platform Adoption with Chaos Mesh" *Chaos engineering methodologies, observability, reliability engineering* **FOSSASIA Summit 2020** | Singapore "Cloud-Native Pipelines with Tekton" (2-hour hands-on workshop, 40+ participants) **Kubernetes User Group Singapore 2023** "Terraform and ArgoCD: Managing Kubernetes Lifecycle" *GitOps workflows, declarative infrastructure, cluster lifecycle management* **Geographic Reach**: Singapore, United States, Russian Federation **Audience Types**: Industry practitioners, technology leaders, open-source developers [View complete speaking history →](https://hayorov.me/talks) --- ## Professional Experience **Director, Head of GTIS Cloud** Prudential plc | Singapore | Dec 2019 – Present Leading omni-cloud infrastructure platforms (Microsoft Azure, Google Cloud Platform) serving 15,000+ employees across 12 Asia-Africa markets. GTIS (Group Technology & Innovation Solutions) Cloud encompasses global cloud operations, AI platforms, and developer experience. *Key Initiatives*: - **Prudential Global AI Lab Foundation** (2024) — Technical architect for Singapore AI research hub in partnership with Google Cloud and Singapore MDDI, facilitating collaboration with NUS, SMU, Republic Polytechnic, Singapore Polytechnic. - **Enterprise IDP Transformation** — Architected unified Internal Developer Platform serving 12 markets using Backstage (Spotify), GitOps (ArgoCD, Terraform), infrastructure self-service portals. *Outcomes*: 99.85% platform availability, 15% infrastructure cost optimization, 12-country geographic reach, 15,000 users enabled. **Software Engineering Manager** Chainstack (Acronis spin-off) | Singapore | Sep 2018 – Dec 2019 Led infrastructure engineering for blockchain-as-a-service platform. Delivered omni-cloud blockchain infrastructure (GCP, AWS, Azure) from concept to production in 9 months. *Recognition*: Featured in Google Cloud customer case study (2019) — "Chainstack: Making blockchain work for enterprises and developers with Google Cloud" https://cloud.google.com/customers/chainstack **Software Engineering Unit Manager** Ingram Micro Cloud (now CloudBlue) | Moscow, Russian Federation | Dec 2015 – Sep 2018 Managed 35-engineer organization responsible for CloudBlue Connect platform. Generated 3 U.S. patents in cloud service automation. *Press*: https://ir.ingrammicro.com/press-releases/detail/173/ --- ## Industry Advisory & Leadership **HashiCorp Customer Advisory Board (E-CAB)** — Singapore Representative | 2023–Present Strategic advisor on product roadmap for Terraform, Vault, Consul at enterprise scale. Board composition includes senior leaders from Singapore government agencies (CSIT, HTX, DSTA) and Fortune 500 enterprises. **Google Cloud Innovators Program** | 2022–Present Community leader and technical expert in GCP ecosystem. Profile: https://g.dev/khaerov **Professional Society Memberships**: - Singapore Computer Society (SCS) — Professional Member #33685 (2020–Present) - Python User Group Singapore — Voting Member (2019–Present) - IEEE Computer Society — Member #96513498 (2016–Present) --- ## Certifications - Google Cloud Professional Cloud Architect (Valid: Mar 2023 – Mar 2025) - Google Cloud Professional Cloud Security Engineer (Valid: Jun 2023 – Jun 2025) - Google Cloud Associate Cloud Engineer (Valid: Sep 2022 – Sep 2025) - Certified Calico Operator: Level 1 (Tigera, No Expiration) - Cisco Certified Network Associate (CCNA) --- ## Open Source Contributions **Primary Maintainer**: [**helm-gcs**](https://github.com/hayorov/helm-gcs) — Google Cloud Storage plugin for Helm chart repositories (285★, 72 forks, active maintenance) **Community Contributions**: - **Terraform**: #418 global contributor ranking (OSSRank) - **Kubernetes Documentation**: Corrections, examples, guides - **Microsoft Azure Documentation**: AKS, Terraform on Azure - **Chaos Mesh**: CNCF project contributions **GitHub Profile**: https://github.com/hayorov **OSSRank**: #188,485 globally among all open-source contributors (66,809 points) --- ## Media Coverage **Prudential Global AI Lab Launch** (2024) Press Release: "Prudential officially launches global AI Lab in Singapore" (Nov 19, 2024, Ministerial participation — Singapore MDDI) https://www.prudentialplc.com/en/newsroom/company-news/2024/prudential-officially-launches-global-ai-lab-in-singapore/ **Chainstack – Google Cloud Case Study** (2019) https://cloud.google.com/customers/chainstack **Ingram Micro Cloud Platform Launch** (2018) https://ir.ingrammicro.com/press-releases/detail/173/ --- ## Technical Expertise **Cloud Platforms**: Omni-cloud architecture (Azure, GCP, AWS) **Container Orchestration**: Kubernetes, Docker, OpenShift, Helm **Infrastructure-as-Code**: Terraform, Terragrunt, Ansible, Pulumi **Programming**: Python (Django, Flask), Go, JavaScript, Shell scripting **CI/CD & GitOps**: ArgoCD, Tekton, GitHub Actions, GitLab CI **Developer Platforms**: Backstage (Spotify IDP), platform engineering tools **Observability**: Grafana, Prometheus, ELK Stack **AI/ML Infrastructure**: Azure AI Foundry, Google Vertex AI, MLOps platforms **Methodologies**: SRE, DevOps, Platform Engineering, FinOps, Agile **Languages**: English (professional fluency), Russian (native) --- ## Download CV [📄 Download Full Academic CV (PDF)](https://hayorov.me/files/khaerov-academic-cv.pdf) --- *Last Updated: May 2026* --- # My Talks - URL: https://hayorov.me/talks/ - Markdown: https://hayorov.me/talks/index.md - JSON: https://hayorov.me/talks/index.json - Published: 2021-07-03 - Updated: 2026-10-04 > Conference talks and speaking engagements by Alex Khaerov on cloud infrastructure, platform engineering, DevOps, AI adoption, and Kubernetes at international conferences including HashiDays, Cloud Expo Asia, and DevOps Summit. I have had the privilege to speak at numerous conferences and meetups across the globe. Here are some of my contributions: | Year | Topic | Conference | Location | | ---- | ----- | ---------- | -------- | | 2026 | [From Zero Trust to Autonomous Containment: Engineering Cyber Resilience in Multi-Cloud](https://www.linkedin.com/posts/cswaconference1080-x-13501-1-share-7503633373848854528-FtB5/) | [Cyber Security World Asia 2026](https://www.singaporetechnologyweek.com/cyber-security-world) | Singapore | | 2026 | [Design an Automation Fabric for the Agentic Era](https://www.ibm.com/events/think/singapore) | [IBM Think Singapore](https://www.ibm.com/events/think/singapore) | Singapore | | 2026 | [Panel: Enabling High-Velocity Engineering with Cloud Platforms and AI](https://chinatechbridge.com/shows/21/38.html) | [Tech Week Shanghai](https://techweeksh.digitalexpo.com/pc/micro-page?microPageId=10011052025072300017532510497859728597511753186&channelId=0021927269967692611584&contentId=10011052025072300017532510497859728597511753186&eid=10015032025071600017526323194428928557583597996&tohome=true) | Shanghai | | 2026 | [Advisory Board Member](https://exito-e.com/devopssummit/singapore/#speakers) | [Exito DevOps Summit Singapore](https://exito-e.com/devopssummit/singapore/) | Singapore | | 2025 | [Automating Infrastructure Management with Cloud-Native Services](https://www.singaporetechnologyweek.com/tech-week-singapore-mainstage-2025) | [Cloud & AI Infrastructure Asia](https://www.singaporetechnologyweek.com/tech-week-singapore-mainstage-2025) | Singapore | | 2025 | [Panel: AI & Automation: Enhancing and Streamlining DevOps Workflows](https://forefrontevents.co/event/devops-summit-singapore-2025/) | [DevOps Summit Singapore 2025](https://forefrontevents.co/event/devops-summit-singapore-2025/) | Singapore | | 2025 | [Anatomy of Self-Service Enterprise Infra Platforms](https://www.hashicorp.com/en/conferences/hashidays/singapore) | [HashiDays 2025 in Singapore](https://www.hashicorp.com/en/conferences/hashidays/singapore) | Singapore | | 2025 | [Panel: Shadow AI and LLM Security – Risks, Governance, and the Innovation Balance](https://www.linkedin.com/posts/tsangstanley_cybersecurity-aisecurity-aigovernance-activity-7334120539227115520-6mXb/) | [F5 AppWorld 2025](https://www.f5.com/appworld) | Singapore | | 2025 | [Panel: Unpacking the Cloud & Infrastructure Foundations Needed to Thrive in the AI Age](https://forefrontevents.co/event/cloud-it-infrastructure-summit-sing/) | [Cloud & IT Infrastructure Summit](https://forefrontevents.co/event/cloud-it-infrastructure-summit-sing/) | Singapore | | 2024 | [GenAI Adoption Path for Self-Services & Internal Developer Platforms](https://1drv.ms/b/s!AnRTaPU_RuJRtDe0sk7HLLGjS8zh?e=K24d4D) | [Cloud Expo Asia](https://web.archive.org/web/20240911192904/https://www.cloudexpoasia.com/2024-conference-programme/genai-adoption-path-for-self-services-internal-developer-platforms) | Singapore | | 2023 | [Terraform and ArgoCD: Managing k8s Lifecycle](https://1drv.ms/b/s!AnRTaPU_RuJRrkpFEP2YS6fGPbJg?e=AVbNz9) | [Kubernetes User Group Meetup](https://www.meetup.com/k8s-sg/events/292826519/) | Singapore | | 2022 | [Facilitating and Simplifying AIOps Platform Adoption with Chaos Mesh](https://www.youtube.com/watch?v=tQSYyAGtJaM) | [Bay Area Cloud Native Infra Meetup](https://www.meetup.com/Bay-Area-Cloud-Native-Database-Meetup/events/283613507/) | San Mateo, CA | | 2020 | [Workshop: Cloud-Native Pipelines with Tekton](https://summit.fossasia.org/event/schedule.html#6088) | [FOSSASIA Summit](https://summit.fossasia.org/) | Singapore | | 2020 | [Pouekhavshie - Singapore (Russian)](https://linkmeup.ru/blog/541.html) | [Linkmeup Podcast](https://linkmeup.ru) | Singapore | | 2019 | [Securing Containers: A Necessary Precaution](https://www.youtube.com/watch?v=QltHmfevCo8&list=PLtFn4-Uxnqyn2ZnJ8iaCBTvTzuMvnGQeb&index=16) | [DevOps Conference](https://devopsconf.io/) | Moscow | | 2019 | [Entangled in Dependencies: A Look at Pipenv & Poetry](https://speakerdeck.com/hayorov/entangled-in-dependencies-pipenv-and-poetry) | [Python User Group SG](https://pugs.org.sg/) | Singapore | | 2019 | [Creating a "Family Budget" in Minutes with Chainstack](https://speakerdeck.com/hayorov/family-budget-in-minutes-with-chainstack) | [Law Blockchain Festival](https://www.meetup.com/Legal-Technology-Singapore/events/261249518/) | Singapore | | 2019 | [Entering the Service Mesh Era: Our First Experience with Istio](https://speakerdeck.com/hayorov/welcome-to-the-service-mesh-era) | [Singapore Kubernetes User Group](https://www.meetup.com/Singapore-Kubernetes-User-Group/) | Singapore | | 2019 | [Quick Start to Quorum with Chainstack](https://speakerdeck.com/hayorov/quorum-in-minutes-with-chainstack) | [DApps Dev Club](https://dappsdev.org/blog/2019-04-12-dapps-dev-club-4th-session-roundup/) | Singapore | --- # Publications - URL: https://hayorov.me/publications/ - Markdown: https://hayorov.me/publications/index.md - JSON: https://hayorov.me/publications/index.json - Published: 2021-07-03 - Updated: 2026-10-04 > Technical publications and articles by Alex Khaerov on Internal Developer Platforms, cloud security, containers, Kubernetes, and infrastructure engineering. Published on Medium and Habr. ## 📚 Publications Over the years, I've written and published various technical articles. Here are some of my works: | Year | Topic | Language | | ---- | ----- | -------- | | 2024 | [Part 2 \| Why Building IDPs is a Challenging Business?](https://akhaerov.medium.com/part-2-why-building-idps-is-a-challenging-business-41112f2fb834) | English | | 2024 | [Comparison of UFW, iptables, and nftables on Alpine Linux](https://akhaerov.medium.com/comparison-of-ufw-iptables-and-nftables-on-alpine-linux-f0f4b99c9890) | English | | 2024 | [Part 1 \| IDPs: What Comes to Your Mind?](https://akhaerov.medium.com/part-1-idps-what-comes-to-your-mind-3127269b2a6e) | English | | 2020 | [Could Containers be Secured?](https://habr.com/en/company/oleg-bunin/blog/480630/) | Russian | | 2019 | [Helm Security](https://habr.com/en/company/oleg-bunin/blog/462665) | Russian | | 2019 | [Public and Private Smart Contracts with JP Morgan Quorum](https://habr.com/en/post/456368/) | Russian | | 2018 | [Browser Voxel 3D Game in Python](https://habr.com/en/company/oleg-bunin/blog/359130/) | Russian | | 2011 | [Virtual Juniper's Mythbusters: Policies & Filters](https://habr.com/en/post/112390/) | Russian | | 2011 | [Installing Juniper JunOS 10 M/T Series](https://habr.com/en/post/111974/) | Russian | | 2011 | [Virtualization Juniper JunOS in GNS3 Environment](https://habr.com/en/post/111172/) | Russian | All of these publications are available on [Habr.com](https://habr.com/en/), a popular IT blog platform. ## 📚 Offline Publications - **Roslyakov A.V., Kudryavceva E.N., Lysikov A.A., Khaerov A.A.** _Baza dannykh oborudovaniya multiservisnykh platform setey sleduyushchego pokoleniya NGN_ \[_The Next Generation Network Multiservice Platform Equipment Database_\]. The registration certificate of electronic resources, Electronic Resources Industry Foundation «Science and Education», Russia, №18650, 12.11.2012. - **Roslyakov A.V., Kudryavceva E.N., Lysikov A.A., Khaerov A.A.** _Portal platform setey sleduyushchego pokoleniya NGN_ \[_Next Generation Networks Platform’s Portal_\]. The registration certificate of electronic resources, Electronic Resources Industry Foundation «Science and Education», Russia, №18651, 12.11.2012. - **Roslyakov A.V., Grebeshkov A.U., Vanyashin S.V., Khaerov A.A.** _Multiservisnye platformy setey sleduyushchego pokoleniya NGN. Zarubezhnye sistemy_ \[_Multiservice Platforms of the Next Generation Networks. V. 2. Foreign Manufacture Systems_\]. Samara, PSUTI Publ., 2012. 344 p. --- # FPV & UAV - URL: https://hayorov.me/fpv/ - Markdown: https://hayorov.me/fpv/index.md - JSON: https://hayorov.me/fpv/index.json - Published: 2021-07-03 - Updated: 2026-03-02 > Alex Khaerov's FPV drone hobby — DIY builds in the 3.5″ to 5″ range, component sourcing, tuning, and flying with DJI O3 digital systems. An electronics engineer's take on the FPV craft. I’m an FPV drone DIY enthusiast—I love designing, building, and tuning drones from scratch. While I’m still a rookie UAV pilot, what I enjoy most is the engineering side: bulk sourcing components, optimizing performance, and using my technical skills to bring it all together. Flying is just a bonus that makes the hobby even more rewarding in my spare time. I’m focused on DIY FPV builds in the 3.5" to 5" range. As an electronics engineer, I spend more time on engineering, assembly, configuration, and tuning than flight practice. ![Wallboard of my FPV/UAV setup, January 2026](https://hayorov.me/fpv/uav-board-jan26.png) This wallboard is my January 2026 setup: a pair of AOS 3.5" drones with DJI O3 air units, plus a DJI Mini Pro 4 as a fun footage drone I bought recently. I started right away with digital and never really flew analog, moving from Caddx Walksnail to DJI and now mostly using the O3 system. --- # Cycling - URL: https://hayorov.me/cycling/ - Markdown: https://hayorov.me/cycling/index.md - JSON: https://hayorov.me/cycling/index.json - Published: 2021-07-03 - Updated: 2026-03-02 > Alex Khaerov's road cycling adventures in Singapore and beyond. Rides, routes, bikes (Canyon Endurace & Ultimate), and a visual timeline of cycling highlights. Cycling is my main way to explore new places, clear my head, and stay consistent with fitness. I ride mostly on the road with a focus on long steady efforts, scenic routes, and occasional tempo blocks when I am training for an event. The bike is also my preferred way to discover Singapore and nearby regions on trips. ### Why I Ride - Steady endurance: longer rides at a sustainable pace. - Simple joy: coffee stops and a good view are non-negotiable. ### Typical Ride Profile - Distance: 60-120 km for weekend rides, 30-50 km on weekdays. - Terrain: mostly rolling, with climbs when traveling. - Time of day: early mornings to avoid heat and traffic. - Extras: one cafe stop, photos. ## [Canyon Endurace CF SLX 8 AXS Aero](https://www.canyon.com/en-sg/endurace-cf-slx-8-axs-aero/50033704.html) Current bike. Color: New Stealth. ## [Canyon Ultimate CF SL 8 Disc Di2](https://www.canyon.com/en-sg/road-bikes/race-bikes/ultimate/cf-sl/ultimate-cf-sl-8-disc-di2/2756.html?dwvar_2756_pv_rahmenfarbe=BU%2FBK) Former bike until 2026. ### Where I Ride - Singapore - Travel: whenever I can bring or rent a road bike, I prioritize one long ride. Photo gallery (7 images): - ![00 big blue jul21](https://hayorov.me/cycling/00BigBlueJul21.jpg) - ![01 big blue nov21](https://hayorov.me/cycling/01BigBlueNov21.jpg) - ![02 big blue apr23](https://hayorov.me/cycling/02BigBlueApr23.jpg) - ![03 big blue apr25](https://hayorov.me/cycling/03BigBlueApr25.jpg) - ![03 big blue jul25](https://hayorov.me/cycling/03BigBlueJul25.jpg) - ![04 big blue oct25](https://hayorov.me/cycling/04BigBlueOct25.png) - ![05 big blue jan26](https://hayorov.me/cycling/05BigBlueJan26.png) --- # For AI Agents & Tools - URL: https://hayorov.me/ai/ - Markdown: https://hayorov.me/ai/index.md - JSON: https://hayorov.me/ai/index.json - Published: 2026-10-04 - Updated: 2026-10-04 > How AI assistants, LLM crawlers and agents can read hayorov.me: llms.txt, Markdown and JSON twins of every page, structured profile, talks and publications data, feeds, and an OpenAPI description. This site is built to be read by machines as well as people. Everything below is static, cacheable, served with `Access-Control-Allow-Origin: *`, and needs no API key. If you are an LLM or an agent, start with [`/llms.txt`](https://hayorov.me/llms.txt). ## Start here | Endpoint | What it is | | -------- | ---------- | | [`/llms.txt`](https://hayorov.me/llms.txt) | Index of the whole site in the [llms.txt](https://llmstxt.org/) format: who I am, every page and post with a one-line description, talks, publications, patents, links | | [`/llms-full.txt`](https://hayorov.me/llms-full.txt) | Every page concatenated as Markdown, for one-shot ingestion | | [`/openapi.json`](https://hayorov.me/openapi.json) | OpenAPI 3.1 description of the endpoints on this page, ready to import as tool or function definitions | ## Every page as Markdown or JSON Append `index.md` or `index.json` to any page URL. HTML pages also advertise them with `` and ``. | HTML | Markdown | JSON | | ---- | -------- | ---- | | `/about/` | [`/about/index.md`](https://hayorov.me/about/index.md) | [`/about/index.json`](https://hayorov.me/about/index.json) | | `/posts/idps-part1/` | [`/posts/idps-part1/index.md`](https://hayorov.me/posts/idps-part1/index.md) | [`/posts/idps-part1/index.json`](https://hayorov.me/posts/idps-part1/index.json) | | `/posts/` | [`/posts/index.md`](https://hayorov.me/posts/index.md) | [`/posts/index.json`](https://hayorov.me/posts/index.json) | The Markdown twin carries YAML front matter (title, description, canonical URL, dates, tags) and a body in which galleries become image lists, embeds become links, and all links are absolute. The JSON twin carries the same metadata plus `content_markdown` and `content_text`. ## Structured data Three pages carry a dataset under the `data` key of their JSON twin. The data lives in version-controlled YAML and renders both the HTML tables and these endpoints, so they never drift. | Endpoint | `data` contains | | -------- | --------------- | | [`/about/index.json`](https://hayorov.me/about/index.json) | Profile: current role, experience timeline, education, certifications, patents, advisory roles and memberships, open source, links | | [`/talks/index.json`](https://hayorov.me/talks/index.json) | Every talk, panel, workshop and podcast: year, title, URL, event, event URL, location, type | | [`/publications/index.json`](https://hayorov.me/publications/index.json) | `articles` (Medium, Habr) and `offline` (books and registered electronic resources) | | [`/posts/index.json`](https://hayorov.me/posts/index.json) | Every blog post: title, description, dates, tags, word count, and links to its Markdown and JSON | ## Feeds and indexes - [`/feed.json`](https://hayorov.me/feed.json) — JSON Feed 1.1 with full HTML and plain-text content for every post - [`/index.xml`](https://hayorov.me/index.xml) — RSS 2.0 with full content - [`/sitemap.xml`](https://hayorov.me/sitemap.xml) — XML sitemap - [`/index.json`](https://hayorov.me/index.json) — the client-side search index (title, section, summary, plain text, permalink for every page) ## Semantics in the HTML Every HTML page embeds JSON-LD (`Person` and `WebSite` on the home page, `Article` and `BreadcrumbList` elsewhere), Open Graph and Twitter Card metadata, `rel="me"` links to my profiles, and a `rel="describedby"` link to `/llms.txt`. ## Crawling, quoting and contact AI crawlers and assistants are explicitly allowed in [`/robots.txt`](https://hayorov.me/robots.txt). You are welcome to read, index, summarise and quote this site; please link back to the canonical page URL when you do. Something missing or wrong in the machine-readable data? Email [alex@hayorov.me](mailto:alex@hayorov.me). # Part 2 — Blog posts (newest first) --- # Two Devices, One Scroll Setting: Fixing a Decade-Old macOS Annoyance - URL: https://hayorov.me/posts/macos-scroll-direction-linearmouse/ - Markdown: https://hayorov.me/posts/macos-scroll-direction-linearmouse/index.md - JSON: https://hayorov.me/posts/macos-scroll-direction-linearmouse/index.json - Published: 2026-06-11 - Updated: 2026-06-11 - Tags: macos, productivity, tools > How LinearMouse ended my twice-a-day natural-scrolling toggle ritual between a desk mouse and the MacBook trackpad. > 💻 MacBook Air, docked at the desk with a mouse — trackpad-only everywhere else > 🐭 One global "natural scrolling" toggle, two devices that want opposite things > ✅ LinearMouse: per-device scrolling, set once, forget forever For years I had this dumb little ritual. Dock the laptop in the morning, grab the mouse, scroll — page flies the wrong way. Open System Settings, flip Natural Scrolling off. Pack up in the evening, open the laptop on the couch, and now the trackpad scrolls backwards. Flip it back on. Twice a day, every day. I'd love to tell you I fixed this years ago like a reasonable person. I did not. I just kept flipping that checkbox. ## Why this is even a thing The toggle lives in **System Settings → Trackpad → Natural Scrolling**, but despite sitting under "Trackpad", it controls the mouse too. One checkbox, both devices. And the two devices genuinely want opposite directions. A trackpad should scroll like a phone screen — content follows your fingers, anything else feels broken. A mouse wheel should scroll like a mouse wheel: wheel down, page down, the way it has worked since the 90s. There is no position of that checkbox that's right for both. Apple has shipped it unchanged for over a decade. ## LinearMouse The fix turned out to be a small open-source app called [LinearMouse](https://linearmouse.app). It does one clever thing: it applies pointer and scroll settings per device. The trackpad and the mouse stop sharing a fate. ```shell brew install --cask linearmouse ``` The whole setup took me about a minute: 1. Launch it, grant the Accessibility permission it asks for 2. Leave macOS Natural Scrolling **on** — that keeps the trackpad correct 3. Pick the mouse in LinearMouse's device dropdown 4. Turn on **Scrolling → Reverse scrolling → Vertical** for it 5. Enable **Start at login** That's the entire fix. Trackpad scrolls like a phone, mouse scrolls like a mouse, and docking is no longer a settings event. While you're in there, do yourself one more favor: **Pointer → Disable pointer acceleration** for the mouse. macOS acceleration is weirdly aggressive, and turning it off made precise cursor work noticeably calmer. Honestly a close second for best feature in the app. ## What about Scroll Reverser and Mos I tried the alternatives before settling. [Scroll Reverser](https://pilotmoon.com/scrollreverser/) is the classic tool for exactly this problem and still works fine, but it does only that one thing and development has mostly stalled. [Mos](https://mos.caldis.me) is built around smooth scrolling — some people swear by it, to me it feels floaty, like scrolling through syrup. LinearMouse covers the scroll direction, kills the acceleration, and stays out of the way. Easy call. ## A year-ish later I genuinely don't think about scrolling anymore, which is the whole point. The best tools are the ones you forget you installed. This one took a `brew install` and one checkbox — I'm only annoyed it took me this long. --- # Riverside Commuter: Shimano CUES Drivetrain Swap - URL: https://hayorov.me/posts/riverside-commuter-shimano-cues-drivetrain/ - Markdown: https://hayorov.me/posts/riverside-commuter-shimano-cues-drivetrain/index.md - JSON: https://hayorov.me/posts/riverside-commuter-shimano-cues-drivetrain/index.json - Published: 2026-04-13 - Updated: 2026-04-14 - Tags: cycling, gear, diy > Part two of the Riverside upgrade — replacing the stock B'Twin square-taper crankset and bottom bracket with a Shimano CUES 1x setup for smoother shifting and a cleaner chainline. > 🚲 Bike: Decathlon Riverside hybrid > 🔧 Upgrade: Shimano CUES FC-U4000 crankset + Hollowtech II BB > 📍 Part 2 of the [Riverside upgrade series](https://hayorov.me/posts/riverside-commuter-rigid-fork-swap/) In [Part 1](https://hayorov.me/posts/riverside-commuter-rigid-fork-swap/) I swapped the heavy Zoom suspension fork for a TOSEEK carbon rigid. That shaved over a kilogram off the front end and transformed the steering. Naturally, once you fix one thing, the next weak link becomes impossible to ignore — and on the Riverside that was the drivetrain. ![The stock drivetrain — B'Twin square-taper crankset with plastic chain guard, 11-36T cassette, and the original bottom bracket. Functional, but nothing more.](https://hayorov.me/riverside-upgrade/stock-drivetrain.jpg) --- ## 🔍 Why the Crankset Had to Go The stock B'Twin crankset is a square-taper unit with a riveted plastic chain guard and a stamped steel chainring. It works, but the interface is loose after a few thousand kilometers, the chainring wears unevenly, and the whole assembly feels like it belongs on a department-store bike. The square-taper bottom bracket cartridge was also overdue — the bearings had developed a gritty feel that no amount of grease would fix. **Symptoms that forced the swap:** - Creaking under load, especially climbing - Visible play in the crank arms - Chainring teeth worn into shark fins - Bottom bracket bearings grinding on rotation --- ## 🆕 The Upgrade: Shimano CUES Shimano's CUES line is their answer to the "good enough for commuters, actually engineered properly" segment. I went with the FC-U4000 crankset and a matching Hollowtech II bottom bracket: ![Shimano CUES crankset and Hollowtech II bottom bracket — still in factory wrapping. The 32T chainring with Dynamic Chain Engagement+ and external bearing cups with orange seals.](https://hayorov.me/riverside-upgrade/shimano-cues-parts.jpg) | Spec | Stock B'Twin | Shimano CUES | |---|---|---| | Interface | Square taper | Hollowtech II | | Chainring | Stamped steel, riveted | 32T, Dynamic Chain Engagement+ | | Bottom bracket | Cartridge, sealed | External bearing cups | | Chain guard | Plastic bolt-on | None needed (narrow-wide ring) | | Feel | Vague, creaky | Solid, silent | The narrow-wide chainring profile means no chain guard and no dropped chains. One less thing hanging off the bike. --- ## 🔩 Teardown First step — strip the old drivetrain down to the bare bottom bracket shell. ![The old B'Twin crankset and square-taper cartridge bottom bracket laid out after removal. The crank bolts, chainring, and plastic guard all come off as one unit.](https://hayorov.me/riverside-upgrade/old-crankset-removed.jpg) ![Bottom bracket shell cleaned and ready. Internal threads are in good shape — no corrosion or cross-threading. Cable guide bolted underneath routes the derailleur cables.](https://hayorov.me/riverside-upgrade/bb-shell-empty.jpg) > **Note:** Before pulling the old cartridge, mark which side is drive and non-drive. The cups thread in opposite directions — left is standard, right is reverse. Cross-threading a BB shell is expensive to fix. --- ## 🛠️ Install The Hollowtech II bottom bracket is a press-and-thread affair — grease the threads, thread the cups by hand, then torque with a BB tool. ### Step 1: Bottom bracket cups ![Drive-side bottom bracket cup installed with fresh green grease on the bearing interface. The hollow center is ready for the crank spindle.](https://hayorov.me/riverside-upgrade/bb-greased.jpg) ![Tightening the bottom bracket cup with a TOOPRE BB wrench. The external splines engage cleanly — no hammering required.](https://hayorov.me/riverside-upgrade/bb-tool-install.jpg) ### Step 2: Crankset Once the bottom bracket is seated, the crankset slides through and the non-drive arm pinch-bolts lock everything in place: ![Shimano CUES crankset installed — chainring on, chain routed, pedal not yet threaded. The matte black finish matches the fork and stem.](https://hayorov.me/riverside-upgrade/cues-crankset-installed.jpg) > **Tip:** Grease the pedal threads before installing. Aluminum crank arms and steel pedal spindles will seize if you skip this. ### Torque specs | Fastener | Torque | |---|---| | BB cups | 35–50 Nm | | Crank arm pinch bolts | 12–14 Nm | | Pedals | 35 Nm | | Chainring bolts | 12–14 Nm | --- ## ✅ Result ![The finished drivetrain — Shimano CUES crankset with 32T narrow-wide ring, bottle cage back on, and the chain tensioned. Clean and functional.](https://hayorov.me/riverside-upgrade/cues-final.jpg) The difference is immediate. Pedaling feels direct — no flex, no creak, no play in the bottom bracket. The narrow-wide chainring grabs the chain with confidence, and the Hollowtech II spindle is noticeably stiffer than the old square taper. Combined with the rigid fork from Part 1, the Riverside now rides like a bike that costs twice what I paid for it. **What changed:** - ✅ Zero creak under load - ✅ No chain drops — narrow-wide ring holds firm - ✅ Stiffer pedaling platform - ✅ Cleaner look without the plastic chain guard --- ## 💰 Gear | Part | Link | Price | |---|---|---| | Shimano CUES FC-U4000 crankset | [Shimano](https://bike.shimano.com/en-US/product/component/cues-u4000.html) | ~65 SGD | | Shimano Hollowtech II BB | included with crankset | — | | TOOPRE BB wrench (BB-46/41/39) | [Shopee](https://shopee.sg/) | ~12 SGD | | Crank puller (square taper) | already owned | — | --- ## 🔮 What's Next The drivetrain and fork are sorted. Next on the list: the rear derailleur and shifter. The stock B'Twin units still work, but they are the last pieces that feel out of place on a bike that is rapidly outgrowing its price tag. --- # Riverside Commuter: Rigid Fork Swap - URL: https://hayorov.me/posts/riverside-commuter-rigid-fork-swap/ - Markdown: https://hayorov.me/posts/riverside-commuter-rigid-fork-swap/index.md - JSON: https://hayorov.me/posts/riverside-commuter-rigid-fork-swap/index.json - Published: 2026-03-29 - Updated: 2026-04-14 - Tags: cycling, gear, diy > Upgrading a Decathlon Riverside hybrid with a TOSEEK carbon rigid fork — ditching the heavy suspension for a lighter, stiffer commute. > 🚲 Bike: Decathlon Riverside hybrid > 🔧 Upgrade: TOSEEK carbon rigid fork > 📍 Part 1 of the Riverside upgrade series My commuter is a [Decathlon Riverside](https://www.decathlon.sg/) — a practical step-through hybrid that handles daily duties: grocery runs, short errands, and the occasional evening spin around the neighborhood. It came with a Zoom suspension fork branded "63 COMFORT," which sounds reassuring until you realize it adds unnecessary weight and flex on smooth tarmac. ![The Riverside in its stock form — Zoom 63 Comfort suspension fork, B'Twin Trekking Speed tires, and flat bar cockpit.](https://hayorov.me/riverside-upgrade/riverside-stock.png) ![Evening commuter setup. Roll-top waterproof pannier on the rear rack, bottle cage on the down tube, and a saddle bag for tools.](https://hayorov.me/riverside-upgrade/pannier-night.png) ![Rear view showing the pannier bag, bungee cord securing the load, and the kickstand deployed for quick stops.](https://hayorov.me/riverside-upgrade/rear-view.png) ![Full daily loadout — rear LED light, reflective pannier patch, and the B'Twin Trekking Speed 700×38C tires that handle everything from tarmac to park connectors.](https://hayorov.me/riverside-upgrade/commuter-loadout.png) --- ## 🔍 Why Swap the Fork The stock Zoom suspension fork is heavy, vague, and designed for terrain I never ride. On flat Singapore roads it just bobs under pedaling effort and adds dead weight. A rigid fork is the single best upgrade for a hybrid used primarily on pavement: | Stock Fork | Rigid Fork | |---|---| | Zoom coil suspension | TOSEEK carbon | | ~1.8 kg | ~0.5 kg | | Flex under braking | Direct steering feel | | Seals & stanchions to maintain | Zero maintenance | --- ## 🆕 The Fork: TOSEEK Carbon Rigid I went with a [TOSEEK carbon rigid fork](https://www.aliexpress.com/item/1005004954479868.html) from AliExpress. Key specs that had to match the stock geometry: ![The TOSEEK rigid fork — matte carbon finish, post-mount disc brake tab, and an expander plug for the carbon steerer.](https://hayorov.me/riverside-upgrade/toseek-fork.png) ![Technical drawing showing the 470mm axle-to-crown (29\"), 28.6mm steerer, 100mm hub spacing, and 45mm rake.](https://hayorov.me/riverside-upgrade/toseek-specs.png) | Spec | Value | |---|---| | Steerer | 1-1/8" (28.6mm), 300mm | | Axle-to-crown | 470mm (29") | | Brake mount | Post mount, 160mm rotor | | Dropout | 9mm quick-release | | Tire clearance | 70mm internal | > **Note:** The fork came with an expander plug for the carbon steerer — the correct way to compress the headset. Never use a star nut on carbon. --- ## ⚖️ Old vs. New ![Side by side — the worn Zoom suspension fork with rusted stanchions (right) next to the new TOSEEK carbon rigid (left). The weight and bulk difference is obvious.](https://hayorov.me/riverside-upgrade/forks-comparison.png) --- ## 🛠️ Setup The swap is straightforward if you have basic tools and a crown race setter: 1. Remove the front wheel, brake caliper, and stem. 2. Drop out the old fork, pull the crown race. 3. Set the crown race on the new fork *(press fit — use a PVC pipe or proper tool)*. 4. Insert the new fork, stack spacers, tighten the stem. 5. Reinstall brake caliper — realign pads to the rotor. 6. Install the expander plug inside the carbon steerer **before** compressing the headset. > **Tip:** Double-check the steerer length before cutting. Measure twice — you cannot undo a cut on carbon. --- ## ✅ Result The bike feels noticeably lighter at the front and steers with more precision. Braking is more direct without the fork compressing. For a commuter that lives on tarmac and park connectors, it is the right call. The ride is marginally harsher over bumps, but nothing the 38mm tires at lower pressure cannot absorb. --- ## 🧾 Gear | Part | Link | Price | |---|---|---| | TOSEEK Carbon Rigid Fork 29" | [AliExpress](https://www.aliexpress.com/item/1005004954479868.html) | ~80 SGD | | Decathlon Riverside hybrid | stock | — | | B'Twin Trekking Speed 700×38C | stock | — | --- ## 🔮 What's Next With the front end sorted, the next weak link became obvious — the stock B'Twin square-taper crankset and bottom bracket. In [Part 2: Shimano CUES Drivetrain Swap](https://hayorov.me/posts/riverside-commuter-shimano-cues-drivetrain/) I replace the drivetrain with a Shimano CUES 1x setup for smoother shifting and a cleaner chainline. --- # From Lift-and-Shift to Omni-Cloud: My Conversation with Frontier Enterprise - URL: https://hayorov.me/posts/frontier-enterprise-omni-cloud-2026/ - Markdown: https://hayorov.me/posts/frontier-enterprise-omni-cloud-2026/index.md - JSON: https://hayorov.me/posts/frontier-enterprise-omni-cloud-2026/index.json - Published: 2026-03-18 - Updated: 2026-04-14 - Tags: cloud, platform-engineering, multi-cloud, interview > My interview with Frontier Enterprise on cloud evolution at Prudential — from lift-and-shift through multi-cloud to the omni-cloud model, and why platform engineering is the only way to scale. > 📰 **Publication:** Frontier Enterprise 2026 — A Special Issue > ☁️ **Topic:** Cloud Evolution at Prudential > 🎙️ **Format:** Interview — distilled with added context I recently had the opportunity to share my perspective on cloud evolution at Prudential in the *Frontier Enterprise 2026 Special Issue*. The full magazine is available here: 👉 [Frontier Enterprise 2026 — A Special Issue](https://www.frontier-enterprise.com/frontier-enterprise-2026-a-special-issue/) My interview is featured in **"Prudential's Path to an Omni-Cloud Future"** (Issue #1). A copy of the original draft is [hosted here](https://hayorov.me/materials/frontier-enterprise-2026-omni-cloud.md) for reference. This post is a distilled version of that conversation — with more context and my own framing. --- ## 🔍 The Real Story Behind "Cloud Transformation" Most enterprises like to tell a clean story: *we moved to cloud, got faster, cheaper, better.* Reality is messier. At Prudential, the journey started like many others — large-scale migration, heavy lift-and-shift, and an expectation that cloud would automatically improve stability and cost. Some of that worked, especially scalability. But some assumptions didn't hold: - Stability is not a given in the cloud - Cost efficiency requires active engineering - Complexity actually **increases**, not decreases That realization triggered the real transformation. ## 🔄 What Actually Happens: Phases of Cloud Evolution After more than a decade in cloud infrastructure, I've seen this pattern repeat across organizations. It's not linear and it's never clean, but the phases are recognizable. ### 1. Lift-and-Shift Move workloads fast. Minimal redesign. Immediate footprint reduction. Necessary, but shallow — you're *in* the cloud, but not using it properly. ### 2. Cloud-Native + Self-Service This is where things get serious. Kubernetes adoption, greenfield architecture, Infrastructure as Code, GitOps. We moved away from centralized provisioning bottlenecks toward teams owning infrastructure end-to-end. But with guardrails — not chaos. The key insight here: **self-service without standardization is entropy.** I've written about this dynamic in more detail in my series on [Internal Developer Platforms](https://hayorov.me/posts/idps-part1/). ### 3. Multi-Cloud Vendor lock-in becomes obvious once teams start using provider-specific services — BigQuery, DynamoDB, and so on. The model shifts from "one cloud fits all" to "place workloads where they fit best." ### 4. Platform Engineering and Abstraction At scale, developers shouldn't care about which cloud, which networking model, or which infra primitives. So we introduced Internal Developer Platforms, abstraction layers, and application-centric interfaces. Developers request: *"I need a service"* — not *"Give me VPC + subnet + IAM + load balancer."* This is where platform engineering becomes real. ### 5. AI-Assisted Infrastructure Now things get interesting. We're entering a phase where developers describe intent in natural language, systems generate infrastructure patterns, and AI assists in documentation summarization, config generation, telemetry interpretation, and change proposals. But let's be precise — AI is not replacing engineers. It's **compressing cognitive load**. Human approval remains critical, especially in regulated environments. I explored the practical side of this in [AI-Driven Cloud Cost Optimization](https://hayorov.me/posts/ai-cloud-cost-optimization/). --- ## 🚀 The Next Step: Omni-Cloud This is the concept I'm most excited about. **Omni-cloud** is not just multi-cloud. It's a unified management plane with multiple interchangeable control planes and standardized interfaces across cloud providers, SaaS platforms, and AI services. Think of it like OpenTelemetry — but for infrastructure and platforms. Developers interact with one system. The system decides *where and how* to run things. The underlying provider becomes an implementation detail, not an architectural decision. --- ## 🎯 What Actually Matters After all phases, tools, and trends — here's where I land: **Complexity is unavoidable.** Cloud didn't simplify infrastructure — it shifted and amplified it. **Abstraction is the only scalable strategy.** Without it, multi-cloud becomes operational chaos. **Platform engineering is not optional anymore.** It's the only way to standardize, scale, and govern. **AI will change interfaces, not responsibilities.** Humans still own risk, make decisions, and carry accountability. --- ## 💡 Final Thought Enterprise cloud is no longer about infrastructure. It's about **reducing cognitive load while increasing control**. That's the real balancing act — and it's what makes this work interesting. 👉 [Read the full interview in Frontier Enterprise 2026](https://www.frontier-enterprise.com/frontier-enterprise-2026-a-special-issue/) 📄 [Download a copy of the full article (PDF)](https://hayorov.me/materials/Frontier-Enterprise-2026-MagLyt-06.pdf) --- # Mechanical Keyboards After the Hype - URL: https://hayorov.me/posts/mechanical-keyboards-after-the-hype/ - Markdown: https://hayorov.me/posts/mechanical-keyboards-after-the-hype/index.md - JSON: https://hayorov.me/posts/mechanical-keyboards-after-the-hype/index.json - Published: 2026-03-08 - Updated: 2026-04-14 - Tags: keyboards, hardware, engineering, review > The mechanical keyboard scene passed its peak. Some thoughts on the market, why hardware is brutal, and why you should maybe grab a Monokei Standard for 50 bucks. > ⌨️ **Topic:** Mechanical Keyboards — After the Hype > 📍 **Location:** Singapore > 📅 **Written:** March 2026 The mechanical keyboard space went through a pretty classic cycle: **innovation → hype → speculation → correction** Peak was probably somewhere around **2019–2022**. Boutique studios popping up left and right, endless switch variants, group buys with year-long waits, YouTube sound tests pulling millions of views, builds hitting **$1000–$2000**. Keyboards stopped being input devices and turned into collectibles, basically. Now in 2026 things feel different. Community is still around, but the intensity dropped. Market is cooling down. Cheese Turbulence covers this shift well: [YouTube video](https://www.youtube.com/watch?v=kROa-ej-sX4) The point is simple — the scene has likely **already passed its peak**. And what's happening on the business side confirms it. --- ## 🔩 Hardware is brutal There's this perception that keyboard makers are running some hugely profitable operation. Aluminium cases, limited drops, high prices — must be printing money, right? Not really. CNC tooling costs, minimum order quantities, logistics, inventory risk, community demand that can vanish overnight. Hardware is just hard. Always has been. Case in point — **Rama Works**. One of the most recognizable names in the premium keyboard world. In **March 2025** they went into **liquidation**. If you've ever been around hardware startups, this is sadly not shocking. Good video on the whole story: [YouTube video](https://www.youtube.com/watch?v=KEqYO1_RP08) A niche market can look huge during hype phase. The actual sustainable demand? Usually much smaller. --- ## 🧑‍💻 Where I stand with keyboards I'm not deep in the mechanical keyboard rabbit hole. Lucky, probably — there's enough dopamine in this hobby to lose your mind completely. New switches, new plates, new mounts, new keycaps. Never ends. I'm quite happy **not** dropping $2000 on every new Atelier Magnus build. Those boards look incredible from an industrial design angle, but that's not where I want my money going. What I do enjoy is the engineering side of it: - switch mechanics - typing acoustics - stabilizer tuning - plate materials - the good old **blue tape mod** How small mechanical tweaks change the feel and sound — that part is genuinely interesting to me. I just treat it as tinkering, not collecting. --- ## 🇸🇬 Monokei This one hits closer to home. I don't know the founders personally and I won't pretend to know the full story. But I fell in love with their design and their whole approach. The slogan on the bottom of the board says it all: > **Designed in Singapore & Malaysia — good things for everyone** Photo gallery (1 images): - ![Monokei standard series 1 07](https://hayorov.me/monokei-keyboard/monokei-standard-series-1-07.webp) Living here in SG, seeing a hardware product actually designed in this region — that just feels good. Not another rebrand from Shenzhen. An actual local team trying to make proper keyboards at a fair price. I own **two Monokei Standard boards**. They're not exotic, not limited edition, nothing fancy. Just solid entry-level mechanical keyboards with honest pricing and clean design. That's it. And that's enough. But Monokei has been going through tough times. I won't dig into the details here — if you're curious, Reddit has everything: the drama, the responses, the founders' side. It's all there. What's clear is that they, like many other small keyboard makers, are struggling. This business is not easy. --- ## 🛒 Grab one while you still can Right now Monokei is clearing out remaining **Standard** stock at about **$50 SGD**. 👉 [Monokei Standard on sale](https://store.monokei.co/collections/keyboards/products/sale-monokei-standard) Fifty bucks. For a proper mechanical keyboard. That's less than what a set of Cherry MX switches costs on its own. If you need a decent daily driver keyboard — just get it. And if you want to support a local team that tried to do something real in a hype-driven market — that's reason enough too. --- ## 🔮 After the hype Mechanical keyboards aren't going anywhere. But the scene is shifting from hype to something more stable. Some brands will fold. Some will consolidate. The community will get smaller but probably healthier. That's fine. That's how these things work. --- *Not affiliated with Monokei or any keyboard brand. Just my take.* --- # Stategraph, 'Terraform Is Dead,' and Other Infra Myths That Won't Die - URL: https://hayorov.me/posts/stategraph-terraform-infra-myths/ - Markdown: https://hayorov.me/posts/stategraph-terraform-infra-myths/index.md - JSON: https://hayorov.me/posts/stategraph-terraform-infra-myths/index.json - Published: 2026-03-01 - Updated: 2026-04-14 - Tags: terraform, infrastructure, iac, platform-engineering > Why Stategraph is a solid execution improvement — not a Terraform replacement — and why IaC isn't going anywhere despite what the hype cycle says. > 🏗️ **Topic:** Infrastructure as Code > 🛠️ **Tool:** Stategraph + Terraform > 💡 **TL;DR:** Stategraph is a solid execution improvement — not a Terraform replacement — and IaC isn't going anywhere. Every few months, the infrastructure community runs the same playbook. A new tool shows up, does something genuinely useful, and within a week the narrative jumps from "this is a nice improvement" to "Terraform is dead, IaC is over, AI will manage your infrastructure now." The latest iteration involves **Stategraph** — and while the technology is real and the problem it solves is valid, the conversation around it has drifted into territory I've seen too many times to stay quiet about. ## 🔍 What Problem Is Actually Being Solved? Terraform's dependency resolution is excellent — within a single state boundary. That's by design. But real-world infrastructure doesn't live in one state file. Once you're operating at scale, you're dealing with: - Multiple root modules - Layered environments - Shared primitives across teams - Platform vs. product ownership boundaries This creates **cross-state dependencies** — and that's exactly where the ecosystem has been building workarounds for years: - **Terragrunt** for orchestration and DRY config - **Terramate** for code generation and orchestration - **CI-driven DAGs** for sequencing applies - Countless homegrown runners held together with scripts and prayers None of this happened because Terraform *failed*. It happened because infrastructure isn't deployed as one atomic unit, and it never will be. Stategraph addresses this gap head-on: it builds a **dependency graph across otherwise isolated execution units**. The result is a unified planning surface, better blast radius awareness, and fewer "apply → discover breakage → re-plan" loops. That's useful. It removes friction I deal with regularly. But let's call it what it is: **an execution intelligence layer** — not a replacement for Terraform's model. ## 🧱 The "Single State Is Broken" Narrative Is Overblown There's a growing tendency to frame Terraform's state isolation as a design flaw. I see this argument a lot, and it misses the point. State boundaries exist because they enable: - **Failure containment** — a bad apply doesn't cascade across your entire estate - **Deploy independence** — teams ship without waiting on each other - **Ownership scoping** — clear lines between platform and product - **Security isolation** — least privilege at the state level In enterprise environments — especially regulated ones like those I've worked in across APAC — fragmentation of state is **intentional**. You don't want one global graph. You want platform domains, product domains, environment separation, and lifecycle autonomy. The orchestration complexity we see today isn't caused by Terraform being "too simple." It's caused by **organizational structure**. Conway's Law applies to infrastructure just as much as it applies to software. Stategraph helps you reason across that structure. It doesn't eliminate the need for it. ## 🔄 This Is the Kind of Capability Terraform Could Absorb Technically, nothing about Stategraph is philosophically incompatible with Terraform. It's still dependency resolution, graph execution, and change planning — just extended across boundaries. In another timeline, this might have simply shipped as: ```bash terraform plan --global ``` Instead of being positioned as a paradigm shift. Which is why framing it as a replacement feels more like ecosystem storytelling than an actual architectural shift. Good improvements don't need to be revolutions to matter. ## 🤖 The AI Layer: IaC Is Not Going Away Here's the twist that keeps getting bundled into these conversations: **"AI will replace IaC anyway."** I've written about [AI-driven cloud cost optimization](https://hayorov.me/posts/ai-cloud-cost-optimization/) and how AI is genuinely changing operational workflows. But the assumption that AI will replace IaC confuses the problem space. The hard part of infrastructure was never writing HCL or YAML. It's: - **Governance** — who can change what, and under what conditions - **Determinism** — knowing exactly what will happen before you apply - **Auditability** — proving to regulators what changed, when, and why - **Blast radius control** — limiting the impact of any single change - **Lifecycle ownership** — clear accountability across teams AI can accelerate authoring. It can help compose intent. It can suggest configurations and catch misconfigurations before they ship. I use AI tooling daily and it genuinely speeds things up. But it doesn't remove the need for: - ✅ Versioned change tracked in git - ✅ Reviewable plans before execution - ✅ Controlled, deterministic execution - ✅ Scoped ownership with clear boundaries If anything, AI **increases** the need for explicit declarative control. Because now changes can be produced faster than ever — and speed without guardrails is how you get outages at 2 AM. **IaC becomes the safety system. Not the bottleneck.** ## ✅ Where Stategraph Actually Adds Value Credit where it's due — there are real improvements here: - **Better impact visibility** across states before you apply - **Reduced orchestration duplication** — less glue code, fewer homegrown runners - **Simplified planning loops** — one surface to understand change impact - **Clearer change surfaces** — who's affected by what For platform teams operating large multi-root estates, this matters. It reduces operational friction, improves confidence in deploys, and shortens feedback cycles. That's meaningful progress. But it doesn't change: - How infrastructure ownership works at the org level - Why environments are isolated by design - How compliance boundaries are enforced - Why deployments must remain deterministic and auditable ## 🗺️ The Reality Infrastructure is not just a graph problem. It's a **socio-technical system**. | Layer | What It Does | |---|---| | **Terraform** | Models resources — the building blocks | | **Orchestration** | Models responsibility — who owns what | | **Stategraph** | Improves execution awareness — what's connected | AI may change how we *author* infrastructure. But it won't remove the need for explicit state, deterministic plans, and controlled blast radius. These aren't limitations of old tooling — they're requirements of production operations. ## 🎯 Final Thought Stategraph is a solid optimization. It makes multi-state Terraform environments easier to reason about, and that's genuinely valuable for anyone running infrastructure at scale. But calling it a Terraform replacement — or tying it to the idea that IaC is fading away — stretches the technical reality past where I'm comfortable following. Infrastructure doesn't disappear into prompts. And good execution improvements don't need to be revolutions to matter. --- # Mirra 1 Alternatives in 2026 - URL: https://hayorov.me/posts/mirra-1-alternatives-2026/ - Markdown: https://hayorov.me/posts/mirra-1-alternatives-2026/index.md - JSON: https://hayorov.me/posts/mirra-1-alternatives-2026/index.json - Published: 2026-02-19 - Updated: 2026-04-14 - Tags: ergonomics, review, workspace > Practical comparison of Herman Miller Mirra 1 alternatives in 2026, covering premium, mid-range, and budget ergonomic chairs. > 🪑 Topic: Ergonomic Chair Comparison > 📍 Previous: [My Favorite Chair: Herman Miller Mirra 1](https://hayorov.me/posts/my-favorite-chair-24/) I still love my decade-old Herman Miller Mirra 1. It is breathable, adjustable, and has a design that feels timeless. If you want the full story, see [My Favorite Chair: Herman Miller Mirra 1](https://hayorov.me/posts/my-favorite-chair-24/). The Mirra 1 is discontinued, parts are harder to find, and that pushed me to research what I would buy in 2026. This is a practical, engineer-style roundup. Marketing claims are loud, but neutral posture can be achieved at several price points. The real tradeoff is support, adjustability, warranty, and cost. ## ✨ What Made the Mirra 1 Special - **Breathable mesh and flexible back:** The mesh keeps airflow moving and encourages upright posture. - **Practical adjustability:** Lumbar support, tilt tension, and seat height are enough for daily comfort. - **Distinctive aesthetic:** It looks modern without being flashy. - **Long-term value:** Even with a mesh replacement, it keeps delivering. --- ## 🔍 How I Evaluated Alternatives - **Support and adjustability:** Lumbar, armrests, seat depth, and tilt matter most. - **Materials and breathability:** Mesh works well in humid climates, padded seats trade airflow for cushion. - **Warranty and durability:** Premium brands usually offer 10 to 12 years, budget options often 1 to 2. - **Price and value:** Higher price does not guarantee better ergonomics. - **Aesthetics and footprint:** Some chairs are visually light, others dominate a room. --- ## 💎 Premium Mesh and Hybrid Chairs (S$1,000 to S$2,500) ### Herman Miller Aeron (Remastered) **Overview:** The Aeron remains a benchmark. Its 8-zone Pellicle mesh adapts to movement, and it comes in multiple sizes. The forward-tilt option supports active work positions. | Pros | Cons | | --- | --- | | Adaptive mesh that stays cool.
Forward tilt supports active posture.
Multiple sizes and optional lumbar systems. | Narrow recline range limits lounging.
Firm seat edge can feel restrictive.
Armrests are only 3D. | **Why it works as a Mirra 1 alternative:** Structured, breathable support with a long warranty, even if the aesthetic is more technical and the seat is less flexible. ### Herman Miller Mirra 2 **Overview:** The Mirra 2 modernizes the Mirra concept with improved lumbar adjustment and armrests. Two back options (Triflex or Butterfly) flex with movement, and the Harmonic tilt provides a smooth recline. | Pros | Cons | | --- | --- | | Breathable mesh and flexible back.
Height and depth adjustable lumbar support with 4D arms.
Lighter frame and friendlier seat edge than the Aeron. | Armrests can feel wide for smaller users.
Butterfly back adds cost and is harder to clean. | Photo gallery (2 images): - ![Mirra2 front](https://hayorov.me/mirra2/mirra2-front.jpg) - ![Mirra2 rear](https://hayorov.me/mirra2/mirra2-rear.jpg) **Why it works as a Mirra 1 alternative:** It is the most direct successor, preserving the original feel while improving adjustability. ### Herman Miller Embody **Overview:** The Embody uses a dynamic back structure that adapts as you move. It is premium, distinctive, and polarizing. | Pros | Cons | | --- | --- | | Encourages movement throughout the day.
Premium build quality.
Excellent for focused, long sessions. | Often above S$2,000.
Firm, highly tuned feel is not for everyone.
Adjustment learning curve. | **Why it works as a Mirra 1 alternative:** A different philosophy, best for people who want a chair that actively responds to posture changes. ### Steelcase Gesture **Overview:** Designed for modern multi-device work, the Gesture's arms adjust in multiple axes to support typing, tablet use, and sketching. It is durable but heavy. | Pros | Cons | | --- | --- | | Highly adjustable arms.
Stable construction with long warranty.
Great for tech-heavy setups and posture shifting. | Expensive compared to mid-range chairs.
Large footprint.
Firmer seat feel than padded alternatives. | **Why it works as a Mirra 1 alternative:** It adds arm flexibility the Mirra 1 never had, though its look is more industrial. ### Steelcase Leap V2 **Overview:** A padded classic with the LiveBack system and seat depth adjustment. It is reliable but visually dated. | Pros | Cons | | --- | --- | | Forgiving padded seat.
LiveBack flexes with the spine.
4D armrests and recline locks. | No major updates in years.
Cubicle-era styling.
Fabric seat needs more cleaning. | **Why it works as a Mirra 1 alternative:** A plush, adjustable alternative if you prefer padding over mesh. ### Haworth Fern **Overview:** The Fern blends a flexible back with conventional lumbar support. The back flexes beautifully, but lumbar positioning can be divisive. | Pros | Cons | | --- | --- | | Modern, distinctive look.
Upper back flexibility.
Forward tilt and long warranty. | Lumbar position can feel too low or too aggressive.
Few functional advantages over cheaper chairs. | **Why it works as a Mirra 1 alternative:** A style-forward option that needs in-person testing to confirm lumbar fit. ### 📊 Premium Chairs at a Glance | Chair | Seat material | Lumbar support | Arms | Warranty | Typical price | | --- | --- | --- | --- | --- | --- | | Herman Miller Aeron | 8-zone mesh | Optional | 3D | 12 yrs | ~S$1,900 | | Herman Miller Mirra 2 | Mesh | Height + depth | 4D | 12 yrs | ~S$1,500 | | Herman Miller Embody | Hybrid | Adaptive back | 3D | 12 yrs | ~S$2,000 | | Steelcase Gesture | Padded mesh | Built-in | Multi-axis | 12 yrs | ~S$1,500 | | Steelcase Leap V2 | Padded fabric | Adjustable slider | 4D | 12 yrs | ~S$700 to S$800 | | Haworth Fern | Hybrid | Built-in + optional air bladder | 4D | 12 yrs (3 yrs upholstery) | ~S$1,000 to S$1,400 | --- ## ⚖️ Mid-Range Options (S$350 to S$1,100) These are the chairs that often get you 70 to 80 percent of the premium experience at half the price. | Chair | Key adjustments | Seat type | Warranty | Price range | | --- | --- | --- | --- | --- | | Branch Ergo Chair Pro | Height, depth, headrest, forward tilt | Mesh/foam | 7 yrs | ~S$500 to S$700 | | Steelcase Karman | Height, tilt | Mesh | 12 yrs | ~S$900 to S$1,100 | | Humanscale Diffrient World | Minimal adjustments | Mesh | 15 yrs | ~S$900 | | Autonomous Ultra 2 | Seat depth, recline lock, tilt tension | Mesh | 2 yrs | ~S$500 to S$600 | | ProtoArc Flexer Pro | Seat depth, 4D arms, recline angles | Foam/mesh | 1 to 3 yrs | ~S$350 to S$550 | --- ## 🏷️ Budget-Friendly Options (Under S$400) Budget chairs rarely match premium build quality, but they can be good for short sessions or secondary workspaces. ### HON Altern **Overview:** A wide, soft seat with adjustable depth and a headrest, but limited back support. | Pros | Cons | | --- | --- | | Wide seat with adjustable depth.
Headrest included.
Affordable. | Weak lumbar support.
Limited arm adjustability.
Uncertain long-term durability. | ### HON Nucleus Drafting Chair **Overview:** Designed for higher desks with a foot ring and adjustable lumbar support. Comfortable enough, but with limited recline. | Pros | Cons | | --- | --- | | Foot ring for tall desks.
Adjustable lumbar and seat depth. | No recline.
Comfort feels average for the price. | ### 📊 Budget Chairs at a Glance | Chair | Notable features | Limitations | Typical price | | --- | --- | --- | --- | | HON Altern | Wide seat, adjustable depth, headrest | Weak lumbar, limited arms | ~S$300 | | HON Nucleus Drafting | Foot ring for high desks | No recline, average comfort | Varies | --- ## ✅ Recommendations **If you want a direct successor:** The Herman Miller Mirra 2 is the closest match to the Mirra 1. The Aeron is a solid alternative if you prefer a more structured seat. **If you want padded comfort with adjustability:** Look at the Steelcase Leap V2 or Branch Ergo Chair Pro. Both balance adjustability with a softer seat feel. **If you need budget relief or a second workspace:** The HON Altern is a serviceable entry-level choice, while the HON Nucleus Drafting is helpful for standing-desk setups. --- ## 💭 Final Thoughts Ergonomic chairs are long-term investments. Premium models offer sophisticated materials and extended warranties, while mid-range chairs can deliver most of the support for a lower cost. Budget options can be good for occasional use or secondary workspaces. Test chairs when possible, listen to your body, and choose the model that fits your habits, budget, and space. --- # Multi-Cloud Resilience, Minus the Buzzwords - URL: https://hayorov.me/posts/resilient-multi-cloud-architectures/ - Markdown: https://hayorov.me/posts/resilient-multi-cloud-architectures/index.md - JSON: https://hayorov.me/posts/resilient-multi-cloud-architectures/index.json - Published: 2026-02-16 - Updated: 2026-06-11 - Tags: multi-cloud, kubernetes, architecture, devops > What actually makes multi-cloud architectures resilient: deliberate design, boring automation, tested failovers — and the honesty to keep most workloads on one cloud. > ☁️ **Topic:** multi-cloud resilience > 💡 **Short version:** multi-cloud done right is deliberate and boring — and most of your workloads still belong on one cloud After a decade-plus of building cloud platforms, I've developed an allergy to the phrase "multi-cloud strategy." Too often it means "we ended up on three clouds by accident and now call it strategy." But there's a real version of multi-cloud, and the reason for it is resilience: staying up when a provider has a bad day, keeping regulators satisfied about where data lives, and retaining the ability to walk away from a pricing conversation. The catch is that resilience doesn't come from using many clouds. It comes from deliberate design on top of them. Spreading workloads across providers without that design doesn't halve your risk — it doubles your surface area for things to go wrong. --- ## 🛡️ Why bother at all Three reasons survive contact with reality: **Outages happen to everyone.** Even the best providers have regional incidents and emergency maintenance. If a single provider event can take your business offline, that's a decision you've made, whether you wrote it down or not. I learned this one viscerally. In a previous role, a misconfigured DNS record in our primary cloud killed all external connectivity — during a public event, naturally. We got back within SLA only because a warm standby in a second provider existed, the failover was automated, and we had actually drilled it. The drills felt like overhead right up until the moment they didn't. **Regulators don't care about your architecture diagram.** Data residency laws across Southeast Asia, Europe, and elsewhere mean certain data lives in certain places, full stop. Multi-cloud is often the only practical way to satisfy that without re-architecting every time a law changes. But map workloads to jurisdictions early — compliance never falls out of technology choices by itself. **Leverage is real.** Total provider independence is a fantasy, but the demonstrated ability to move critical workloads changes how renewal negotiations go. Providers can tell the difference between a customer who could leave and one who can't. --- ## 🏗️ What it's built from Every resilient multi-cloud setup I've seen rests on the same three foundations, none of them exotic. **Kubernetes as the portability layer.** Containers abstract the app from the infrastructure; Kubernetes makes deploy, scale, and heal work the same way on every cloud. That's what makes "move this workload" a real sentence during an incident instead of a quarter-long project. Workloads welded to proprietary services don't get to fail over. **One observability picture, not five.** Siloed per-cloud dashboards are how surprises happen. Aggregate metrics, logs, and traces into a single view — Prometheus and Grafana remain the workhorses — and be ruthless about alert quality. A dashboard nobody trusts is worse than no dashboard; I've ranted about that in [the fast-food order screen post](https://hayorov.me/posts/observability-fastfood-dashboard/). **Everything as code.** Terraform (or Pulumi) for provisioning, CI/CD for deploys, policy-as-code (OPA) for governance. Reproducibility is what makes recovery fast: if your environment lives in reviewed, versioned code, rebuilding it elsewhere is a pipeline run, not tribal-knowledge archaeology. This is also where platform engineering earns its keep — see [my IDP series](https://hayorov.me/posts/idps-part1/) for that thread. --- ## 🧩 Pick a pattern, not a posture "Multi-cloud" hides several very different architectures with very different price tags: | Pattern | What it means | Resilience | Complexity | | --- | --- | --- | --- | | **Functional distribution** | Each cloud does what it's best at — analytics here, transactions there | Moderate — failures stay contained per function | Low-medium | | **Active-active** | Same app live on multiple clouds, traffic follows health | High — near-zero-downtime failover | High — distributed state is no joke | | **Cloud bursting** | One primary cloud, overflow elsewhere during spikes | Moderate — primary failure still hurts | Medium | Active-active sounds great in slides and costs accordingly — synchronizing state across providers is some of the hardest engineering in this space. Most organizations need it for a handful of services, not for everything. Which brings me to the most useful multi-cloud decision of all: **classifying workloads honestly.** Your revenue-critical path may justify active-active. Your internal wiki does not. Letting auxiliary systems live happily on one cloud with decent backups isn't a compromise — it's the design. --- ## ✅ The practices that separate working setups from slideware - Infrastructure defined in code, reviewed and versioned — no snowflake environments - Clusters configured the same way on every cloud, so drift doesn't ambush you mid-failover - Replication and backups matched to actual RPO/RTO numbers someone signed off on - Centralized identity and automated misconfiguration scanning across all providers — every new cloud is new attack surface - Egress costs modeled with real data flows *before* the architecture is locked in, because cross-cloud data transfer is where budgets go to die - **Failovers drilled live, on a schedule.** Paper DR plans fail. Every drill I've run found a dependency nobody knew about. Every single one. Roll it out in phases: stateless and non-critical workloads first, automation expanding as confidence grows, governance and DR drills as standing practice rather than launch-week theater. Track MTTR and change failure rate so "more resilient" is a measurement, not a feeling. --- ## ⚠️ How these projects actually fail Rarely on technology. The pattern I keep seeing: orchestration complexity built before there's a need for it, egress bills nobody modeled, security treated as inherited from providers rather than practiced daily, failover plans that were never tested, and — underneath all of it — no clear answer to who owns what. The biggest multi-cloud risk isn't an outage. It's ambiguity about architecture and responsibility, discovered at 2 AM. The trend lines (AIOps for anomaly detection, CSPM for cross-cloud policy, IDPs as the standardization layer) all help, but they amplify a sound foundation rather than substitute for one. Multi-cloud resilience is a continuous practice, not a procurement event. Keep it deliberate, keep it boring, drill the failovers — and if you're working on this in 2026, I'd genuinely like to hear what's working for you and what still hurts. --- # AI Is Taking Over the Boring Half of FinOps - URL: https://hayorov.me/posts/ai-cloud-cost-optimization/ - Markdown: https://hayorov.me/posts/ai-cloud-cost-optimization/index.md - JSON: https://hayorov.me/posts/ai-cloud-cost-optimization/index.json - Published: 2026-02-13 - Updated: 2026-06-11 - Tags: cloud, finops, ai, cost-optimization > Where AI-driven cloud cost optimization actually helps — anomaly detection, forecasting, rightsizing — and where you should keep your hands on the wheel. > 💰 **Topic:** AI in cloud cost management > 🎯 **Short version:** let the machines do the watching, forecasting, and rightsizing — keep the judgment calls for yourself I've watched cloud bills spiral more times than I can count. It always starts innocently: a team provisions generously "just for now", a few experiments never get torn down, nobody touches the commitment plans because forecasting feels like gambling. Six months later a third of the bill is pure waste, and someone gets handed "look into costs" as a side quest next to their actual job. The classic FinOps answer is process — tagging discipline, weekly reviews, dashboards. It works, sort of. But it's reactive by nature: you spend hours investigating a spike that already happened, fix it, and wait for the next one. Meanwhile the footprint keeps growing — thousands of instances, Kubernetes clusters, serverless, storage tiers, and now GPU fleets for AI workloads, each with its own pricing model. No human reviews their way through that weekly. This is exactly the kind of problem AI tooling is good at. Not the strategy — the volume. --- ## 🔍 The problems that keep repeating Across teams I've seen, the waste comes from the same handful of places: - **Sizing for peak, running 24/7.** Actual utilization averages 20–30%, but nobody wants to be the one who under-provisioned. - **Commitments left on the table.** Reserved Instances and Savings Plans need a usage forecast someone actually trusts. Usually nobody does, so everything runs on-demand. - **Anomalies nobody catches.** A misconfigured autoscaler can burn thousands before the bill arrives. By then it's archaeology, not incident response. - **Pricing complexity.** AWS alone has hundreds of instance types across purchase options and regions. Tracking the optimal combination by hand is not a job, it's a punishment. GPU workloads make all of this worse. Training instances cost serious money per hour, and the failure modes are mundane: a notebook left running overnight, an inference cluster sized for traffic that never came. --- ## 🛠️ What AI tooling actually does well **Anomaly detection.** Models learn your baseline — daily cycles, weekly patterns, seasonality — and flag deviations in minutes instead of at month-end. The autoscaling group that spun up 500 instances by mistake becomes an alert today, not a forensic exercise in three weeks. **Forecasting.** Instead of extrapolating last month's number linearly, decent models account for growth patterns and planned changes. It won't be perfect, but it's good enough to have a real budgeting conversation before migrating a workload or kicking off a big training run, not after. **Autonomous rightsizing.** This is where the actual savings live. Recommendation reports are where good intentions go to die — engineers are busy, and downsizing someone else's instance is nobody's favorite ticket. Platforms that execute changes themselves (with dependency awareness, staged rollouts, and rollback) close the loop that humans chronically don't. On Kubernetes that means adjusting requests and limits, bin-packing pods, and scaling node groups without anyone filing anything. **Commitment management.** AI is genuinely better than humans at the buy-too-many vs. buy-too-few dance. It watches steady-state usage and keeps coverage high as the infrastructure shifts. This was always a spreadsheet job nobody wanted; now it doesn't have to be one. --- ## 🧰 The tools The space matured fast. A few names worth knowing: **Sedai** for fully autonomous optimization (their Palo Alto Networks case study claims $3.5M saved — vendor numbers, but directionally believable), **Cast AI** for Kubernetes and especially GPU/spot orchestration, **nOps** if you're AWS-and-EKS-heavy, **CloudZero** if you care about unit economics — cost per customer, per feature — rather than raw totals, and **Holori** for multi-cloud visibility. Take every "we cut costs by 70%" number with the usual case-study salt. The common thread that matters: these tools act instead of just reporting. That's the actual generational difference from the old cost dashboards. --- ## 🎯 What I'd actually do If I were starting this today: 1. **Baseline first.** Cost Explorer, GCP Billing, Azure Cost Management — know your top five cost drivers before buying anything. 2. **Recommendations mode before autonomy.** Let the tool suggest for a few weeks. You'll learn whether you trust it, and your team learns what it's about to start doing on its own. 3. **Spot instances for anything fault-tolerant.** Batch jobs, CI, and — with proper checkpointing — model training. Running experiments on spot GPUs instead of on-demand flagship instances is the single biggest GPU saving available. 4. **Be ruthless about idle AI infrastructure.** Auto-shutdown for notebooks, ephemeral environments for experiments, separate sizing for training vs. inference. Most GPU waste is not exotic; it's stuff left on. 5. **Don't forget storage.** Tiering cold data and deleting orphaned snapshots is unglamorous and routinely worth 20% of the bill. --- ## ⚠️ Where to keep your hands on the wheel Autonomous cost tooling making changes to production is a real operational decision, not a checkbox. You want audit trails, respect for compliance boundaries, and a human in the loop for workloads with unusual patterns — the AI doesn't know that your weird batch job is load-bearing. And watch the lock-in: pick platforms that work across clouds, or you've just traded one dependency for another. The direction of travel seems clear to me though. Cloud footprints are getting more complex, not less, and the manual review model stopped scaling a while ago. The teams handing the repetitive half of FinOps to machines now are the ones who'll have the spare attention for the decisions that actually need a human. --- # AWS, Azure, or GCP: How I Think About the Enterprise Cloud Question - URL: https://hayorov.me/posts/best-cloud-platforms-enterprise-scale-deployment/ - Markdown: https://hayorov.me/posts/best-cloud-platforms-enterprise-scale-deployment/index.md - JSON: https://hayorov.me/posts/best-cloud-platforms-enterprise-scale-deployment/index.json - Published: 2026-02-09 - Updated: 2026-06-11 - Tags: cloud, enterprise, architecture > An opinionated take on choosing between AWS, Azure, and GCP for enterprise-scale deployment — and why the honest answer is usually about your org, not the platform. > ☁️ **Question:** which cloud for enterprise scale? > 💡 **Honest answer:** the one that matches your org chart, your licenses, and your team's muscle memory — not the feature matrix Every architecture review eventually arrives at the same question: AWS, Azure, or GCP? And every vendor comparison answers it with a feature matrix, as if enterprises pick clouds the way gamers pick GPUs. After years of sitting in these discussions, I can tell you the feature matrix is the least interesting part. All three hyperscalers can run your workloads. The real differences are about fit. Here's how I actually think about it. --- ## 🟠 AWS: the default for a reason AWS is the safe pick, and "safe" is not an insult at enterprise scale. The service catalog is the deepest, the ecosystem of tooling and people who know it is the largest, and the sharp edges have mostly been documented by a decade of other people's incidents. The strengths are real: EC2 covers practically any performance-to-budget combination, S3 is still the benchmark everyone else describes themselves against, Lambda is the most mature serverless option, and Outposts handles the "we still have a data center" reality without a full rewrite. The cost is complexity. AWS pricing is a discipline of its own, and the learning curve for a team starting fresh is steep. The proprietary-service gravity is also strongest here — convenient services pull you in, and five years later "we could migrate if we wanted" is a sentence nobody says with a straight face. Kubernetes and open tooling are the usual counterweight. --- ## 🔵 Azure: if you're a Microsoft shop, stop pretending you have a choice I mean this without judgment. If your company runs on Active Directory, Windows Server, and SQL Server, Azure is not one option among three — it's the path of least resistance, and resistance is expensive. Azure Hybrid Benefit alone (reusing existing licenses in the cloud) changes the financial math enough to end many evaluations early. Azure's hybrid story is genuinely its best feature: Arc and Stack treat on-prem, multi-cloud, and Azure as one managed surface, and extending AD to the cloud is about as smooth as that sentence can ever be. Compliance tooling is strong, which matters in regulated industries. Where it lags: spot capacity is less mature than AWS's, and while Linux support is fine these days, the platform clearly shines brightest in Microsoft-first environments. That's not a flaw — it's the strategy. --- ## 🟡 GCP: the engineer's cloud, with caveats GCP is what happens when the company that invented Kubernetes builds the cloud around it. If your architecture is container-native and your workloads lean toward data and ML, GCP feels coherent in a way the others don't — GKE is the best managed Kubernetes, the networking is excellent, Vertex AI is a serious ML platform, and pricing (sustained-use discounts, preemptible VMs) is the most transparent of the three. The caveat: GCP assumes you've adopted its worldview. Teams new to containers face a steeper on-ramp, and the enterprise sales and support motion still trails the other two. You pick GCP because your engineers want it — which, depending on your org, is either the best or the worst reason. --- ## 🧮 The quick version | You are... | Lean toward | | --- | --- | | Starting fresh, want the broadest ecosystem and hiring pool | AWS | | A Microsoft estate with AD, SQL Server, and EA agreements | Azure | | Container-native, data/ML-heavy, engineering-led | GCP | | Regulated, with hard data-residency or on-prem requirements | Whoever has the right regions + a hybrid layer (Arc, Anthos, OpenShift) | And the option the vendor decks undersell: **more than one**. Most large organizations end up multi-cloud whether they planned it or not — an acquisition here, a data-residency requirement there. Designing for portability from day one (containers, Terraform, no gratuitous proprietary couplings) costs little and buys you negotiating leverage forever. I've written more about that in [resilient multi-cloud architectures](https://hayorov.me/posts/resilient-multi-cloud-architectures/). --- ## 🧭 What actually decides it In my experience the decision usually comes down to three unglamorous questions: 1. **What does your team already know?** Re-skilling an organization costs more than any pricing difference between providers. 2. **What do your contracts say?** Existing Microsoft agreements, committed-spend deals, and partner relationships move the needle more than benchmarks do. 3. **What will your regulator accept?** In some industries and regions this question eliminates options before engineering ever gets a vote. Notice that none of these are about the technology. That's the point. The platforms have converged enough that the differentiator is fit with your organization — and the architecture practices you bring (IaC, GitOps, workload portability, FinOps discipline) will determine your outcome far more than the logo on the invoice. --- # Modernizing Legacy Systems Without Burning the House Down - URL: https://hayorov.me/posts/cloud-native-legacy-modernization/ - Markdown: https://hayorov.me/posts/cloud-native-legacy-modernization/index.md - JSON: https://hayorov.me/posts/cloud-native-legacy-modernization/index.json - Published: 2026-02-07 - Updated: 2026-06-11 - Tags: cloud-native, architecture, modernization > A practitioner's view on legacy modernization: strangler figs, hybrid bridges, and why the big-bang rewrite is almost always the wrong answer. > 🏚️ **Topic:** legacy system modernization > 💡 **Short version:** wrap, don't rip — the strangler fig beats the big-bang rewrite almost every time I've spent a lot of time around organizations trapped in legacy systems. The pattern is always the same: the old system works — that's exactly the problem. It runs the business reliably enough that nobody can justify touching it, while quietly consuming most of the IT budget, blocking every integration, and depending on the two people who still understand it. Everyone knows it needs to go. Nobody wants to be holding it when it breaks. The good news is that modernization in 2026 doesn't have to mean the heroic rewrite. The big-bang replacement — freeze features for two years, rebuild everything, cut over on a weekend — has a failure rate that should disqualify it from polite conversation. The approaches that actually work are duller, slower, and dramatically safer. --- ## 🌉 The hybrid bridge The lowest-risk entry point is almost always hybrid: keep the stable core running where it is, and start moving the things around it — analytics, reporting, batch processing, new features — to the cloud. You're not betting the company on a migration; you're relieving pressure while learning how the system actually behaves. This also converts the finance conversation. Instead of a terrifying capital project, modernization becomes incremental operational spend with checkpoints where you can stop, measure, and decide whether to continue. CFOs like off-ramps. So should architects. --- ## 🌿 The strangler fig The pattern at the heart of every modernization I've seen succeed: wrap legacy functions behind APIs, then grow new services around them until the old code quietly stops mattering. Named after the fig that grows around a host tree — by the time the tree is gone, the fig stands on its own. In practice: 1. **Put an API facade in front of the monolith.** Nothing changes inside yet; you've just created a seam. 2. **Route new functionality through the facade** as separate services — containerized, deployable on their own schedule. 3. **Migrate existing functions opportunistically**, one at a time, when there's a business reason to touch them anyway. 4. **Retire legacy code paths** as traffic drains away from them. No cutover weekend. No feature freeze. The system stays alive the whole time, which means you can stop at any point and still be better off than when you started. That last property is the one that saves careers. --- ## 🗺️ Picking the right move per system Not everything deserves the same treatment, and pretending otherwise is how modernization programs drown. The standard menu: | Strategy | What it means | When it fits | |---|---|---| | **Rehost** | Lift-and-shift to cloud infrastructure | The system is fine, the data center isn't | | **Refactor** | Restructure toward cloud-native patterns | Solid core that needs scalability | | **Rearchitect** | Break it apart into services | The architecture itself is the bottleneck | | **Replace** | Buy or rebuild | High risk, low differentiation — why are you maintaining this? | The honest assessment that precedes this table is the unglamorous part everyone skimps on: mapping dependencies, scoring components by business criticality and technical risk, finding out which "simple" module secretly talks to fourteen others. Hidden dependencies are where timelines go to die — and it's worth involving people who've done this before, because internal teams are often too close to the system to see its traps. Start the actual migration with something non-critical — internal tools, batch jobs — run it for a couple of quarters, and collect real numbers. Pilot results buy you the political capital for the scary parts later. --- ## ⚙️ The parts people underestimate **The deployment pipeline matters more than the architecture diagram.** Microservices with manual deployments are just a distributed monolith with extra steps. CI/CD, blue-green deploys, and feature flags are what make incremental migration safe enough to do continuously. **Data is the hard part.** Code migration gets the attention; data synchronization between old and new systems during the transition is where the genuinely difficult engineering lives. Budget for it accordingly, especially anywhere compliance is watching. **The last 20% is operational.** Post-migration tuning — cost optimization, observability, getting on-call comfortable with the new world — takes real time. Plan for it or it becomes the reason people call the migration a failure despite the system working. **Resistance is rational.** The people defending the legacy system are usually the ones who get paged when things break. They're not blockers, they're your risk register. Win them with pilot results, not slideware. --- ## 🏁 The payoff When it works, the change is bigger than the infrastructure bill. The thing that actually surprises teams isn't the cost reduction — it's what happens when developers stop firefighting a fragile system and start shipping features again. Maintenance load drops, deploys stop being events, and integrating the next thing (an AI/ML workload, a new partner API) becomes a sprint instead of a steering-committee topic. Legacy systems became legacy because they were once good enough to survive. The goal isn't to punish them for it — it's to inherit their reliability without inheriting their constraints. Wrap, migrate, retire. Boring, incremental, and it works. --- # Step-by-Step: Setting Up a CI/CD Pipeline Using Tekton - URL: https://hayorov.me/posts/tekton-cicd-pipeline-guide/ - Markdown: https://hayorov.me/posts/tekton-cicd-pipeline-guide/index.md - JSON: https://hayorov.me/posts/tekton-cicd-pipeline-guide/index.json - Published: 2026-02-05 - Updated: 2026-04-14 - Tags: tekton, kubernetes, cicd, devops > Step-by-step guide to setting up CI/CD pipelines with Tekton on Kubernetes, covering Tasks, Pipelines, and security scanning. > 🔧 **Tool**: Tekton Pipelines v1.3.x LTS > ☸️ **Platform**: Kubernetes v1.27+ > 📦 **Scope**: CI/CD — Build, Test, Scan, Deploy > 🕐 **Updated**: February 2026 Setting up a **CI/CD pipeline** with **Tekton** transforms how you handle continuous integration and delivery in Kubernetes environments. This guide walks you through every step - from installation to running a production-ready pipeline - using the latest Tekton practices as of early 2026, enabling you to automate builds, tests, scans, and deployments efficiently on your cluster. Tekton stands out as a **cloud-native CI/CD framework** because it runs entirely within Kubernetes as custom resources, eliminating the need for external servers. You'll learn to create reusable **Tasks**, orchestrate them in **Pipelines**, and execute **PipelineRuns** with real-world examples, including security scanning and multi-environment deployments. By the end, you'll have a scalable setup that boosts developer productivity and reliability. --- ## 🚀 Why Choose Tekton for Your CI/CD Needs **Tekton Pipelines** excels in Kubernetes-native environments by defining workflows as declarative YAML manifests. Unlike traditional tools like Jenkins, Tekton leverages Kubernetes pods for execution, making it highly scalable and portable across clusters. Key advantages include: - **Reusability**: Share **Tasks** across pipelines via Tekton Hub or using the cluster resolver. - **Flexibility**: Run tasks sequentially, in parallel, or conditionally using `when` expressions. - **Data sharing**: Use **Workspaces** and **Results** to pass artifacts and metadata between steps without hardcoded paths. - **Extensibility**: Integrate with tools like Kaniko for builds, Trivy for scans, and Kubernetes for deployments. - **Event-driven automation**: Use Tekton Triggers with EventListeners for webhook-based pipeline execution. The latest Tekton v1.3.1 LTS (released August 2025, supported through August 2026) emphasizes better resource management, improved performance, and stable v1 APIs. For teams managing microservices on Kubernetes, this setup reduces deployment times by up to 50% compared to agent-based systems, based on community benchmarks. Visit [hayorov.me](https://hayorov.me) for more insights into optimizing your Kubernetes workflows with modern DevOps tools. --- ## 📋 Prerequisites for Tekton Installation Before diving in, ensure your environment meets these requirements: - A running **Kubernetes cluster** (v1.27+ recommended for full Tekton v1 support). - **kubectl** configured and working. - **tkn CLI** v0.43.0 or later installed. - Cluster-admin access for installing CRDs. - Persistent storage class for Workspaces (e.g., for source code sharing). Install the latest Tekton CLI (v0.43.0+): ```bash # macOS via Homebrew brew install tektoncd-cli # Linux (x86_64) curl -LO https://github.com/tektoncd/cli/releases/download/v0.43.0/tkn_0.43.0_Linux_x86_64.tar.gz sudo tar xvzf tkn_0.43.0_Linux_x86_64.tar.gz -C /usr/local/bin/ tkn # Verify installation tkn version ``` --- ## ⚙️ Installing Tekton Pipelines on Your Cluster Tekton installation is straightforward via YAML manifests. Use the latest LTS release for production stability. 1. **Install Tekton Pipelines** (latest v1.3.1 LTS): ```bash kubectl apply --filename https://storage.googleapis.com/tekton-releases/pipeline/latest/release.yaml ``` 2. **Verify installation**: ```bash tkn version kubectl get pods -n tekton-pipelines ``` Expect `tekton-pipelines-controller` and `tekton-pipelines-webhook` pods running. 3. **Wait for all components to be ready**: ```bash kubectl wait --for=condition=ready pod --all -n tekton-pipelines --timeout=300s ``` For visualization, install the **Tekton Dashboard** (latest release): ```bash kubectl apply --filename https://storage.googleapis.com/tekton-releases/dashboard/latest/release.yaml ``` Access it via port-forward: `kubectl port-forward -n tekton-pipelines service/tekton-dashboard 9097:9097`, then open `http://localhost:9097` in your browser. **Pro Tip**: For production environments, pin to specific LTS versions for stability. The current LTS v1.3.1 is supported through August 2026. --- ## 🧩 Understanding Tekton Core Components Master these building blocks to build flexible pipelines: - **Step**: A single container execution (e.g., `npm test`). - **Task**: Sequence of steps for one job (e.g., git-clone). - **Pipeline**: Orchestrates Tasks with parameters, workspaces, and conditions. - **PipelineRun**: Instantiates a Pipeline with concrete values. - **Workspace**: PersistentVolumeClaim or other storage for sharing files between tasks. - **Results**: Structured outputs passed between Tasks (e.g., image digest). - **Resolvers**: Fetch Tasks from external sources (Hub, Git, Bundles, Cluster). **Important Note**: ClusterTasks are deprecated in favor of the **cluster resolver**. Use `resolver: cluster` in taskRef to reference cluster-scoped tasks. --- ## ✏️ Creating Your First Simple Task Start with a basic **git-clone Task** using the Tekton Hub resolver - the modern way to reference tasks. Install the git-clone task from Tekton Hub: ```bash tkn hub install task git-clone ``` Test with a standalone **TaskRun**: ```yaml apiVersion: tekton.dev/v1 kind: TaskRun metadata: name: test-git-clone spec: taskRef: resolver: hub params: - name: catalog value: tekton - name: type value: task - name: name value: git-clone - name: version value: "0.9" params: - name: url value: https://github.com/tektoncd/pipeline - name: revision value: main workspaces: - name: output persistentVolumeClaim: claimName: source-pvc # Create this PVC first ``` Apply: `kubectl apply -f taskrun.yaml`, then check logs: `tkn taskrun logs test-git-clone -f`. This clones the repo into a Workspace, foundational for pipelines. --- ## 🔨 Building a Basic Pipeline: Clone, Build, and Push Combine Tasks into a **Pipeline** for a classic flow: clone → build → push. Install required tasks from Tekton Hub: ```bash tkn hub install task git-clone tkn hub install task kaniko ``` Create `basic-pipeline.yaml` using v1 API: ```yaml apiVersion: tekton.dev/v1 kind: Pipeline metadata: name: build-and-push spec: params: - name: git-url type: string - name: image type: string - name: revision type: string default: "main" workspaces: - name: source - name: dockerconfig tasks: - name: fetch-repo taskRef: resolver: hub params: - name: catalog value: tekton - name: type value: task - name: name value: git-clone - name: version value: "0.9" params: - name: url value: $(params.git-url) - name: revision value: $(params.revision) workspaces: - name: output workspace: source - name: build-push runAfter: [fetch-repo] taskRef: resolver: hub params: - name: catalog value: tekton - name: type value: task - name: name value: kaniko - name: version value: "0.6" workspaces: - name: source workspace: source - name: dockerconfig workspace: dockerconfig params: - name: IMAGE value: $(params.image) ``` Apply: `kubectl apply -f basic-pipeline.yaml`. --- ## ▶️ Executing Your First PipelineRun Create a PVC for Workspace: ```yaml apiVersion: v1 kind: PersistentVolumeClaim metadata: name: source-pvc spec: accessModes: - ReadWriteOnce resources: requests: storage: 5Gi ``` Create a Docker config secret for pushing images: ```bash kubectl create secret docker-registry docker-credentials \ --docker-server=docker.io \ --docker-username=YOUR_USERNAME \ --docker-password=YOUR_PASSWORD \ --docker-email=YOUR_EMAIL ``` Run the Pipeline: ```yaml apiVersion: tekton.dev/v1 kind: PipelineRun metadata: generateName: basic-run- spec: pipelineRef: name: build-and-push params: - name: git-url value: https://github.com/your-org/sample-app - name: image value: docker.io/yourusername/sample-app:latest - name: revision value: main workspaces: - name: source persistentVolumeClaim: claimName: source-pvc - name: dockerconfig secret: secretName: docker-credentials timeouts: pipeline: "30m" ``` Apply with: `kubectl create -f pipelinerun.yaml` (note: use create for generateName), then monitor: `tkn pipelinerun logs -f -L`. Success! Your code is cloned, built with Kaniko (no Docker daemon needed), and pushed. --- ## 🏗️ Advanced Pipeline: Full CI/CD with Tests, Scans, and Deployments Scale to production with testing, security scanning, and multi-stage deploys. Install additional tasks: ```bash tkn hub install task git-clone tkn hub install task kaniko tkn hub install task trivy-scanner tkn hub install task kubernetes-actions ``` Create `advanced-pipeline.yaml` with modern v1 API and hub resolver: ```yaml apiVersion: tekton.dev/v1 kind: Pipeline metadata: name: app-cicd-pipeline spec: params: - name: git-url type: string - name: git-revision type: string default: "main" - name: image-registry type: string default: "docker.io" - name: image-name type: string - name: deploy-env type: string default: "staging" workspaces: - name: source-code - name: docker-config - name: kubeconfig results: - name: image-digest value: $(tasks.build-image.results.IMAGE_DIGEST) tasks: # Clone repository - name: fetch-source taskRef: resolver: hub params: - name: catalog value: tekton - name: type value: task - name: name value: git-clone - name: version value: "0.9" params: - name: url value: $(params.git-url) - name: revision value: $(params.git-revision) workspaces: - name: output workspace: source-code # Parallel: Tests and Security Scan - name: run-unit-tests taskRef: name: run-tests # Custom Task: npm test, pytest, etc. runAfter: [fetch-source] workspaces: - name: source workspace: source-code - name: security-scan taskRef: resolver: hub params: - name: catalog value: tekton - name: type value: task - name: name value: trivy-scanner - name: version value: "0.2" runAfter: [fetch-source] params: - name: ARGS value: ["fs", "--severity", "CRITICAL,HIGH", "."] - name: IMAGE_PATH value: "." workspaces: - name: manifest-dir workspace: source-code # Build after tests pass - name: build-image taskRef: resolver: hub params: - name: catalog value: tekton - name: type value: task - name: name value: kaniko - name: version value: "0.6" runAfter: - run-unit-tests - security-scan params: - name: IMAGE value: "$(params.image-registry)/$(params.image-name):$(params.git-revision)" workspaces: - name: source workspace: source-code - name: dockerconfig workspace: docker-config # Conditional Deploy to Staging - name: deploy-staging taskRef: resolver: hub params: - name: catalog value: tekton - name: type value: task - name: name value: kubernetes-actions - name: version value: "0.2" runAfter: [build-image] when: - input: $(params.deploy-env) operator: in values: ["staging"] params: - name: script value: | kubectl set image deployment/myapp myapp=$(params.image-registry)/$(params.image-name):$(params.git-revision) -n staging kubectl rollout status deployment/myapp -n staging workspaces: - name: kubeconfig-dir workspace: kubeconfig finally: - name: cleanup taskRef: name: cleanup-workspace workspaces: - name: source workspace: source-code ``` Key enhancements: - **Hub resolver**: Modern way to reference tasks from Tekton Hub (no more ClusterTasks). - **Parallel execution**: Tests and security scans run simultaneously for faster feedback. - **When conditions**: Environment-specific deploys based on parameters. - **Finally block**: Ensures cleanup/notifications always run, even on failure. - **Pipeline-level Results**: Capture deployable artifacts like image digests. - **Timeouts**: Prevent resource hogs with task and pipeline-level timeouts. --- ## 🔐 Service Accounts, Secrets, and Security Best Practices Secure your pipeline with proper RBAC and secret management: 1. **Create ServiceAccount with proper permissions**: ```yaml apiVersion: v1 kind: ServiceAccount metadata: name: pipeline-sa namespace: default secrets: - name: docker-credentials - name: kubeconfig-secret --- apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: pipeline-deployer namespace: staging rules: - apiGroups: ["apps"] resources: ["deployments"] verbs: ["get", "list", "patch", "update"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: pipeline-sa-deployer namespace: staging subjects: - kind: ServiceAccount name: pipeline-sa namespace: default roleRef: kind: Role name: pipeline-deployer apiGroup: rbac.authorization.k8s.io ``` 2. **Registry Secret** (already created in previous section): ```bash kubectl create secret docker-registry docker-credentials \ --docker-server=docker.io \ --docker-username=youruser \ --docker-password=yourtoken \ --docker-email=you@example.com ``` 3. **Kubeconfig for Deployments**: Create a service account in your target cluster with deploy permissions, extract the token, and create a kubeconfig secret. 4. **Resource Limits and Timeouts**: ```yaml # Add to individual tasks timeout: 10m computeResources: requests: cpu: 500m memory: 512Mi limits: cpu: 1000m memory: 1Gi ``` **2026 Security Best Practices**: - Use **Workload Identity** or **IRSA** (IAM Roles for Service Accounts) instead of static credentials where possible. - Parameterize all sensitive inputs; never hardcode secrets in YAML. - Use **immutable image tags** (git commit SHA) instead of `latest`. - Implement **Trivy scanning** with severity thresholds (CRITICAL, HIGH). - Enable **SBOM generation** for supply chain security. - Use **signed bundles** with Tekton Chains for task provenance. - Implement **network policies** to restrict pod-to-pod communication. - Version pipelines in Git alongside application code (GitOps approach). - Use **OPA Gatekeeper** or Kyverno for policy enforcement. --- ## ⚡ Event-Driven Automation with Tekton Triggers Automate pipeline execution using webhooks with Tekton Triggers and EventListeners. Install Tekton Triggers: ```bash kubectl apply --filename https://storage.googleapis.com/tekton-releases/triggers/latest/release.yaml kubectl apply --filename https://storage.googleapis.com/tekton-releases/triggers/latest/interceptors.yaml ``` Create an EventListener for GitHub webhooks: ```yaml apiVersion: triggers.tekton.dev/v1beta1 kind: EventListener metadata: name: github-listener spec: serviceAccountName: pipeline-sa triggers: - name: github-push interceptors: - ref: name: github params: - name: eventTypes value: ["push"] bindings: - ref: github-binding template: ref: pipeline-template --- apiVersion: triggers.tekton.dev/v1beta1 kind: TriggerBinding metadata: name: github-binding spec: params: - name: gitrevision value: $(body.head_commit.id) - name: gitrepositoryurl value: $(body.repository.clone_url) --- apiVersion: triggers.tekton.dev/v1beta1 kind: TriggerTemplate metadata: name: pipeline-template spec: params: - name: gitrevision - name: gitrepositoryurl resourcetemplates: - apiVersion: tekton.dev/v1 kind: PipelineRun metadata: generateName: github-run- spec: pipelineRef: name: app-cicd-pipeline params: - name: git-url value: $(tt.params.gitrepositoryurl) - name: git-revision value: $(tt.params.gitrevision) - name: image-name value: myapp workspaces: - name: source-code volumeClaimTemplate: spec: accessModes: - ReadWriteOnce resources: requests: storage: 1Gi - name: docker-config secret: secretName: docker-credentials ``` Expose the EventListener: ```bash kubectl port-forward service/el-github-listener 8080:8080 ``` Configure your GitHub repository webhook to point to the EventListener URL (use ngrok or Ingress for external access). --- ## 📊 Monitoring, Troubleshooting, and Optimization - **Logs**: ```bash tkn pipelinerun logs -f tkn pipelinerun list tkn taskrun list ``` - **Dashboard**: Visualize pipeline graphs, execution status, and logs at `http://localhost:9097`. - **Events**: ```bash kubectl get events --sort-by='.lastTimestamp' -n default kubectl describe pipelinerun ``` - **Prometheus Metrics**: Enable monitoring with Prometheus Operator: ```bash kubectl apply -f https://storage.googleapis.com/tekton-releases/pipeline/latest/release-metrics.yaml ``` - **Common Issues and Fixes**: | Issue | Fix | |-------|-----| | PVC not bound | Check storage class exists and has provisioner | | Permission denied | Verify ServiceAccount RBAC roles and bindings | | Task timeout | Increase timeout or optimize task steps | | Image push fail | Verify registry credentials and network access | | Resolver error | Check Hub connectivity or use specific versions | | Workspace error | Ensure PVC/secret exists and is accessible | --- ## 🏢 Scaling Tekton for Enterprise Workloads For large teams and production environments: - **EventListeners with Triggers**: Auto-run pipelines on Git events (push, PR, tag). - **Multi-tenancy**: Use namespaces and ResourceQuotas to isolate teams. - **Multi-cluster deployments**: Deploy to multiple clusters using different kubeconfigs. - **Metrics and Observability**: - Enable Prometheus integration for metrics collection - Use Grafana dashboards for visualization - Integrate with OpenTelemetry for distributed tracing - **Cost Optimization**: - Use ephemeral workspaces with emptyDir for non-persistent data - Implement autoscaling for EventListener pods - Set aggressive resource limits on Tasks - Use spot instances for build workloads - **GitOps Integration**: Combine with ArgoCD or Flux for complete CI/CD: - Tekton builds and pushes images - ArgoCD/Flux handles deployment and sync - Maintain separation of concerns - **Supply Chain Security**: - Use Tekton Chains for artifact signing and provenance - Generate SBOMs (Software Bill of Materials) - Implement policy enforcement with OPA/Kyverno --- ## 🆕 What's New in Tekton 2026 Recent advancements in Tekton v1.3.x (2026) include: - **Stable v1 API**: Migration from v1beta1 complete; use `tekton.dev/v1` for all resources. - **Improved Resolvers**: Hub, Git, Bundle, and Cluster resolvers are production-ready. - **Pipeline-level Results**: Aggregate results from multiple tasks. - **Better Resource Management**: Enhanced scheduling and resource allocation. - **Enhanced Security**: Non-root container execution by default. - **Performance Improvements**: Faster webhook processing and controller responsiveness. - **Tekton Chains Integration**: Built-in support for artifact signing and SLSA provenance. --- ## 🎯 Conclusion Mastering Tekton unlocks Kubernetes-native CI/CD that grows with your applications. This guide covered installation, basic and advanced pipelines, security best practices, event-driven automation, and enterprise scaling patterns using the latest Tekton v1 APIs and tooling available in 2026. Start with the basic clone-build-push example, iterate to advanced flows with testing and security scanning, then add event-driven automation with Triggers. Integrate with ArgoCD for GitOps-based deployments and implement supply chain security with Tekton Chains. Explore more DevOps automation patterns and Kubernetes best practices at [hayorov.me](https://hayorov.me) to continue elevating your cloud-native journey. --- ## 📚 Additional Resources - [Official Tekton Documentation](https://tekton.dev/docs/) - [Tekton Hub](https://hub.tekton.dev/) - Reusable Tasks and Pipelines - [Tekton Pipelines GitHub](https://github.com/tektoncd/pipeline) - [Tekton Triggers GitHub](https://github.com/tektoncd/triggers) - [Tekton Chains Documentation](https://tekton.dev/docs/chains/) --- # What Fast-Food Order Screens Can Teach Us About Broken Observability - URL: https://hayorov.me/posts/observability-fastfood-dashboard/ - Markdown: https://hayorov.me/posts/observability-fastfood-dashboard/index.md - JSON: https://hayorov.me/posts/observability-fastfood-dashboard/index.json - Published: 2025-07-12 - Updated: 2026-04-14 - Tags: observability, devops, engineering-culture > What fast-food order screens reveal about broken observability in engineering, and how to build dashboards that actually help. Photo gallery (1 images): - ![Observability](https://hayorov.me/observability-fastfood-img/observability.png) > 📊 **Topic:** Observability & Monitoring > 🍔 **Analogy:** Fast-food order screens > 🎯 **Takeaway:** Build dashboards engineers actually trust and use Ever stood at the most popular fast-food chain in Singapore (where, in my opinion, this issue feels especially pronounced), staring at the giant digital order screen that supposedly tells you when your food is ready? It looks slick—numbers updating in real time, animations flying—but you’re still standing there five minutes after your number disappeared. Or your food is ready before it even shows up. The system’s working—but no one believes it anymore. That’s exactly the kind of trap we fall into with observability in engineering teams. --- ## 🔍 When Observability Exists But Doesn’t Help We all know when monitoring is missing—that’s obvious. But there's a sneakier problem: dashboards, alerts, and metrics that exist but don’t actually help anyone. Here’s the usual setup: 1. **Telemetry Collection & Storage** You’ve got your Prometheus, OTEL, or some vendor agent scraping metrics from apps, infra, and services. Cool. But collecting data doesn’t mean people know what to do with it. 2. **Dashboards & Visualization** This is where a lot of us screw up. We throw every chart we can think of into Grafana—CPU, memory, HTTP codes, request rates. Technically correct, but not what folks actually need when things are on fire. What we really care about is stuff like “are users able to log in?” or “are purchases going through?” 3. **Alerts & Incident Response** Without context and clear ownership, alerts turn into background noise. Nobody wants to be paged for a spike that recovers in 30 seconds. If the alert doesn’t help fix or prevent something, it’s just noise. --- ## 🍔 The Fast-Food Display Syndrome Back to the food court analogy: the screen is up and running, but it doesn’t match reality. The staff are doing their thing, orders are flying, but what’s shown on screen has little to do with what’s actually happening. People start ignoring it. Same thing happens to your dashboards if they’re disconnected from what your system or users are really doing. Trust dies. And without trust, the whole observability setup is just noise and sunk cost. - 🛠️ **Slow Incident Response**: People rely on MS Teams chats and tribal knowledge instead of the data. - 📦 **Guesswork on Scaling**: Infra gets over- or under-provisioned because we’re not using real signals. - 🧪 **Performance Slips Under the Radar**: Gradual regressions sneak past everyone. - 📉 **Nobody Maintains Dashboards**: They rot because nobody's using them. --- ## 🛠️ How to Build Observability Engineers Actually Use Let’s get back to basics: ### 1. Start With What Actually Matters Think like a user. What’s the failure that makes people angry? Start from there, then trace it to signals your system produces. Track those. - Instead of counting 500s, measure failed checkouts or dropped login attempts. - Don’t just chart latency—track whether you’re meeting your SLA per endpoint or function. ### 2. Cut the Noise Prometheus can scrape everything, but that doesn’t mean it should. Keep dashboards tight and focused. Each one should have a reason to exist. - One “main” dashboard per service. - Keep it clean. Only show what SREs or devs actually look at during incidents. ### 3. Make Alerts Useful Again Good alerts are rare. They tell the right team what’s wrong, why it matters, and what to do next. If an alert doesn’t meet that bar, it’s a log line pretending to be useful. ### 4. Tune Constantly Check who’s acknowledging alerts. When was the last time a dashboard was opened? If nobody’s using a panel, archive it or fix it. ### 5. Make Observability Part of the Routine Don’t wait for a P1 to look at dashboards. Bring them into standups, retro, postmortems. Ask “what would’ve made this easier to catch?” --- ## 💭 Final Thought: Are You Building Control Towers or Eye Candy? Observability should help you *run* your systems—not just decorate your wiki or status board. If your team doesn’t trust your metrics or ignores your dashboards, that’s not just an ops issue—it’s a broken feedback loop. Before you add another panel or scrape job, ask: > “Is anyone using the stuff we already have?” If not, you’re just building another fast-food display—looks cool, tells you nothing. --- # In-Flight Internet Reality Check (2025): China Southern Airlines — Shanghai to Singapore - URL: https://hayorov.me/posts/inflight-internet-test-2025/ - Markdown: https://hayorov.me/posts/inflight-internet-test-2025/index.md - JSON: https://hayorov.me/posts/inflight-internet-test-2025/index.json - Published: 2025-06-22 - Updated: 2026-02-20 - Tags: travel, review > Real-world speed test of China Southern Airlines in-flight Wi-Fi on Shanghai to Singapore route. Usable for lightweight tasks. > ✈️ Tested on: China Southern Airlines > 🛫 Route: Shanghai → Singapore > 🕐 Duration: ~5 hours > 📅 Date: June 2025 > 💰 Plan: Starter Tier – ¥159 RMB (~29 SGD / 21 USD) In June 2025, I flew from Shanghai to Singapore with China Southern Airlines and tried their **in-flight Wi-Fi**. I opted for the _Starter Tier_, which promises internet access for the full flight at a flat rate of **¥159 RMB** (~29 SGD / 21 USD). Despite my skepticism, the service was **stable throughout** the entire flight—surprisingly usable for productivity tasks that don’t rely on video or real-time collaboration. ### 📊 Real-World Speed Test (via Cloudflare) - **Download speed**: ~388 kbps - **Upload speed**: ~212 kbps - **Latency**: ~1.29 seconds - **Jitter**: ~313 ms - **Packet loss**: Not measurable (ICE timeout) Photo gallery (2 images): - ![Check 1](https://hayorov.me/inflight-internet-check/check-1.png) - ![Check 2](https://hayorov.me/inflight-internet-check/check-2.png) ### 🎓 Verdict: Usable for MBA Study The speeds were far from impressive but more than sufficient for **lightweight study workflows**. I accessed course materials, completed quizzes, and followed reading assignments—all from my phone. ✅ Perfect for: - Reading articles or PDFs - Messanging - Browsing course content ❌ Not ideal for: - Zoom / Teams meetings - Video streaming - Large file transfers ### 🧠 TL;DR If you're flying China Southern Airlines and debating whether to pay for Wi-Fi on the Shanghai → Singapore leg, here's my take: > **For ¥159, it's worth it if your needs are text-heavy.** > Set expectations right—this is _functional_, not fast. --- # My Favorite Chair: Herman Miller Mirra 1 - URL: https://hayorov.me/posts/my-favorite-chair-24/ - Markdown: https://hayorov.me/posts/my-favorite-chair-24/index.md - JSON: https://hayorov.me/posts/my-favorite-chair-24/index.json - Published: 2024-06-15 - Updated: 2026-04-14 - Tags: ergonomics, review, workspace > A decade-long review of the Herman Miller Mirra 1 ergonomic chair covering durability, mesh replacement, and long-term value. > 🪑 Chair: Herman Miller Mirra 1 (manufactured ~2012) > 📍 Location: Singapore > ⏳ Ownership: 10+ years and counting I spend most of my day seated — coding, on calls, or reviewing documents. A good chair disappears under you. A bad one reminds you it exists every hour. After testing many options over the years, one chair earned a permanent spot: the [Herman Miller Mirra 1](https://www.hermanmiller.com/en_eur/products/seating/office-chairs/). Photo gallery (3 images): - ![Img 1533](https://hayorov.me/chair24/IMG_1533.jpeg) - ![Img 1534](https://hayorov.me/chair24/IMG_1534.jpeg) - ![Img 1535](https://hayorov.me/chair24/IMG_1535.jpeg) --- ## 🪑 Why the Mirra 1 The Mirra 1 is discontinued. Herman Miller replaced it with the Mirra 2, and the Aeron gets most of the attention. But the original Mirra has a character the successors never quite matched: - **Breathable mesh back** that flexes with movement and keeps airflow in humid Singapore - **Distinctive design** — the exposed back structure looks modern without trying too hard - **Practical adjustability** — lumbar support, tilt tension, seat height, and armrests cover the essentials without overwhelming you with knobs - **Compact footprint** — lighter and less imposing than an Aeron At the office we have Mirra 2s and Aerons. Both are excellent. But the Mirra 1 has a warmth to its design that the clinical precision of newer models lacks. It is a chair I actually like looking at. --- ## 🔧 Durability: 10+ Years and One Mesh Replacement My unit was produced around 2012 — over a decade old as of 2024. The frame, tilt mechanism, and gas cylinder are all original and still feel solid. No creaks, no wobble, no degradation in the adjustment mechanisms. The only repair: a **mesh seat pad replacement**. A dropped pen punctured the mesh, and the small hole slowly grew until the seat was unusable. Finding a replacement was the hard part: 1. **Local dealer** — contacted them first. The process was slow and ultimately a dead end for a discontinued model. 2. **eBay** — found an original Mirra 1 mesh from a seller in Nebraska. Shipping to Singapore was not cheap, but it was the right part. 3. **Result** — the chair is back to factory condition. Another decade of use, easy. > **Tip:** If you own a Mirra 1, bookmark eBay searches for replacement parts now. Stock is drying up as more units age out of corporate fleets. --- ## 💡 What Makes It Last | Aspect | Mirra 1 | |---|---| | Frame | Die-cast aluminum, no visible wear after 10 years | | Mesh | Replaceable — the seat pad swaps without tools | | Gas cylinder | Standard size, cheap to replace if needed | | Tilt mechanism | Still smooth, no play | | Armrests | Height and width adjustable, pads intact | Herman Miller built these for a 12-year warranty cycle. In practice, they outlast that easily if you maintain the mesh and keep the mechanism clean. --- ## ✅ Verdict The Herman Miller Mirra 1 is more than a chair — it is a decade-long proof that good design and solid engineering outlast trends. Discontinued does not mean obsolete. If you come across one secondhand, it is worth every dollar. The parts are still findable, the comfort is still there, and the design still holds up. For a commuter who upgrades bike parts one at a time, the philosophy is familiar: **buy once, maintain well, replace only what wears out.** --- ## 🔮 What's Next After 10+ years with the Mirra 1, I started researching what I would buy if it finally gave out. That turned into a full comparison — see [Mirra 1 Alternatives in 2026](https://hayorov.me/posts/mirra-1-alternatives-2026/) for the roundup of premium, mid-range, and budget ergonomic chairs. --- # Part 1 | IDPs: What Comes to Your Mind? - URL: https://hayorov.me/posts/idps-part1/ - Markdown: https://hayorov.me/posts/idps-part1/index.md - JSON: https://hayorov.me/posts/idps-part1/index.json - Published: 2024-06-13 - Updated: 2026-04-14 - Tags: platform-engineering, devops, idp > Internal Developer Platforms vs Infrastructure Developer Platforms: differences, similarities, and roles in modern platform engineering. > 🏗️ Topic: Internal Developer Platforms vs Infrastructure Developer Platforms > 🎯 Goal: Clarify what "IDP" actually means in platform engineering > 📍 Part 1 of the IDP series "IDP" — most people think Identity Provider. In platform engineering, it means something else entirely. There are two flavors: **Internal Developer Platforms** and **Infrastructure Developer Platforms**. They solve different problems, serve different users, and get confused constantly. This post breaks down both. --- ## 🔀 Two Platforms, One Acronym Two distinct platforms exist in modern engineering orgs. They complement each other, but they are not the same thing. Understanding the difference matters if you're building or buying either one. ## 🔑 Self-Service Is the Common Thread Both platform types share one core principle: **self-service**. Developers and ops teams should access resources without filing tickets or waiting on another team. Self-service removes bottlenecks, speeds up delivery, and is the foundational capability that makes either platform worth building. ### Internal Developer Platform (IDP) The Internal Developer Platform sits at the center of the development workflow. It gives developers what they need to build, test, and deploy — without depending on ops for every request. - **Self-Service Capabilities**: Developers provision resources independently. No ticket queues. - **Unified Interfaces**: One portal for project management, docs, and collaboration. - **Automation**: CI/CD pipelines, automated testing, deployment — all integrated. - **Observability and Monitoring**: Logging, alerting, and performance tracking built in. ### Infrastructure Developer Platform The Infrastructure Developer Platform is the foundation layer. It manages the compute, storage, and networking that applications run on. - **Infrastructure Provisioning**: Create, manage, and scale VMs, containers, and storage. - **Configuration Management**: Define infrastructure state with Terraform, Ansible, or Kubernetes. - **Resource Allocation and Optimization**: Scale up or down based on demand. No waste. - **Security and Compliance**: Enforce security standards and regulatory requirements at the infra level. --- ## 📊 A Face-to-Face Comparison | Feature | Internal Developer Platform | Infrastructure Developer Platform | |-------------------------------|------------------------------------------------------------|-----------------------------------------------------------| | **Primary Focus** | Enhances the development process, providing developers with tools and environments to streamline workflows. | Manages and optimizes the underlying infrastructure, ensuring resources are available and efficiently used. | | **User Interface** | User-friendly portals and dashboards designed for developers to easily manage their projects and resources. | More technical interfaces tailored to cloud engineers and operations teams responsible for managing infrastructure. | | **Automation and Self-Service**| Emphasizes self-service capabilities and the automation of development workflows, enabling developers to operate independently. | Focuses on automating infrastructure provisioning and management. | | **End Users** | Designed for software developers, aiming to make their development process more efficient and enjoyable. | Serves both developers and operations teams, providing tools to manage and optimize infrastructure. | ## 🧭 Platforms to Explore Here are some notable platforms in the space: - **[Backstage](https://backstage.io/)**: Originated from Spotify, it's an open-source platform for building developer portals, focusing on improving the developer experience. - **[Port](https://getport.io/)**: A platform designed to streamline infrastructure and operations, offering tools for managing applications and resources. - **[Spacelift](https://spacelift.io/)**: A CI/CD platform for infrastructure as code, designed to enhance collaboration and automation in infrastructure management. - **[Platform.sh](https://platform.sh/)**: A platform-as-a-service that offers tools for developing, deploying, and scaling applications, with a focus on ease of use and integration. - **[HashiCorp Waypoint](https://www.waypointproject.io/)**: A platform for building, deploying, and releasing applications across any platform, with a focus on simplifying the deployment process. ## 🏁 Conclusion Both platforms play crucial but different roles. The Internal Developer Platform makes it easier and faster to build and ship applications. The Infrastructure Developer Platform ensures the underlying infra is robust, scalable, and secure. They're complementary — not interchangeable. Next time, I'll dive deeper into IDP autonomy in the enterprise and explain why I've been building IDPs — and why it's a hard business. --- # Canyon CF10 Cockpit gear - URL: https://hayorov.me/posts/canyon-cf10cockpit-mount/ - Markdown: https://hayorov.me/posts/canyon-cf10cockpit-mount/index.md - JSON: https://hayorov.me/posts/canyon-cf10cockpit-mount/index.json - Published: 2021-11-26 - Updated: 2026-04-14 - Tags: cycling, gear > Wahoo GPS and headlight mounting setup for Canyon CF10 aero cockpit with carbon computer mount. > 🚴 Bike: Canyon with CP10 aero cockpit > 🔧 Setup: Wahoo GPS + headlight on a carbon out-front mount > 💡 Total cost: under 50 SGD Canyon's integrated cockpit looks great — until you need to mount a GPS and a light. The stock stem has no standard mount points, and most aftermarket brackets do not fit the aero bar shape. Here is how I solved it with a cheap carbon computer mount and a GoPro-compatible light. --- ## 📸 The Setup Photo gallery (2 images): - ![1st](https://hayorov.me/cp10cockpit/1.jpg) - ![2nd](https://hayorov.me/cp10cockpit/2.jpg) --- ## ✅ Requirements The mount had to tick three boxes: - **Canyon cockpit compatible** — fits H31, CP01, CP04, CP06, CP07, CP10 & CP16 aero/ergo bars - **GoPro-style quick release** — works with GoPro and compatible devices like front lights - **Stiff, light, and aero** — no wobbly plastic brackets ruining the clean bar profile --- ## 💰 Gear | Part | Link | Price | |---|---|---| | OEM Carbon bike computer mount | [AliExpress](https://www.aliexpress.com/item/32966754265.html) | ~15 SGD | | ROCKBROS 400LM Bike Light | [AliExpress](https://www.aliexpress.com/item/33052501051.html) | ~21 SGD | | Elemnt Bolt Silicone Cover | [AliExpress](https://www.aliexpress.com/item/1005001611693317.html) | ~10 SGD | --- # DIY Lezyne mount for Canyon handlebar - URL: https://hayorov.me/posts/canyon-lezynegps-mount/ - Markdown: https://hayorov.me/posts/canyon-lezynegps-mount/index.md - JSON: https://hayorov.me/posts/canyon-lezynegps-mount/index.json - Published: 2021-09-04 - Updated: 2026-04-14 - Tags: cycling, diy, 3d-printing > DIY 3D-printed Lezyne GPS mount for Canyon aero handlebars with GoPro-compatible quick release. Free STL download. > 🛠️ Canyon aero cockpits don't play nice with standard GPS mounts. So I designed my own — 3D-printed, GoPro-compatible, and free to download. --- ## 📐 The Model Photo gallery (1 images): - ![Preview canyon lezyne gopro mount v4](https://hayorov.me/stl-models/preview/preview-canyon-lezyne-gopro-mount-v4.png) Grab the STL file here: [canyon-lezyne-gopro-mount-v4.stl](https://github.com/hayorov/website/blob/master/static/stl-models/canyon-lezyne-gopro-mount-v4.stl) --- ## 🔧 Compatibility - [Lezyne GPS computers](https://ride.lezyne.com/collections/gps-devices-computers) with X-Mount (Super Pro GPS, Mega, Macro) - GoPro-like quick release mount (GoPro, compatible devices like front lights) - Canyon aero/ergo cockpit (H31, CP01, CP04, CP06, CP07, CP10 & CP16) --- ## 🖨️ Printed Result Photo gallery (2 images): - ![Img 7020](https://hayorov.me/stl-models/printed-preview/IMG_7020.jpg) - ![Img 7021](https://hayorov.me/stl-models/printed-preview/IMG_7021.jpg) --- # Challenge #1: Modify a table data - URL: https://hayorov.me/posts/for-all-rows/ - Markdown: https://hayorov.me/posts/for-all-rows/index.md - JSON: https://hayorov.me/posts/for-all-rows/index.json - Published: 2020-05-02 - Updated: 2026-04-14 - Tags: python, coding-challenge > Python coding challenge: normalize table row lengths by filling missing labels with null values. > 🧩 Challenge: Normalize table row lengths > 🐍 Language: Python ## 📋 Problem Given a structure that represents a data table: ```python [ [foo:42, baz:7], [foo:45, bar:8, baz:9], ] ``` N rows, M items in a row, an item is `