<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Week 5 - AI Platform Integration on AI Platform Engineering Handbook</title><link>/docs/week-05/</link><description>Recent content in Week 5 - AI Platform Integration on AI Platform Engineering Handbook</description><generator>Hugo</generator><language>en</language><copyright>Copyright (c) 2026 Harshhaa</copyright><atom:link href="/docs/week-05/index.xml" rel="self" type="application/rss+xml"/><item><title>End-to-End AI Platform Architecture</title><link>/docs/week-05/end-to-end-ai-platform-architecture/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>/docs/week-05/end-to-end-ai-platform-architecture/</guid><description>&lt;hr&gt;
&lt;h2 id="1-cloud-native-ai-system-architecture"&gt;1. Cloud-Native AI System Architecture&lt;/h2&gt;
&lt;p&gt;Let&amp;rsquo;s start from the very beginning. Before cloud existed, if a company wanted to run software, they had to physically buy servers, put them in a room, hire people to maintain them, and pray nothing breaks. If traffic suddenly doubled, you were out of luck — you didn&amp;rsquo;t have extra hardware sitting around.&lt;/p&gt;</description></item><item><title>Advanced Deployment Strategies</title><link>/docs/week-05/advanced-deployment-strategies/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>/docs/week-05/advanced-deployment-strategies/</guid><description>&lt;hr&gt;
&lt;h2 id="1-blue-green-deployment-strategy"&gt;1. Blue-Green Deployment Strategy&lt;/h2&gt;
&lt;p&gt;Let me start with the problem this solves. You have a model or service running in production serving real users. You&amp;rsquo;ve built a new version and want to deploy it. The naive approach: shut down the old version, deploy the new one, hope it works. The problem with this: during the switchover, users get errors. And if the new version has a bug, you&amp;rsquo;ve already killed the old one — rolling back means going through the same painful process again.&lt;/p&gt;</description></item><item><title>Security &amp; Governance</title><link>/docs/week-05/security-governance/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>/docs/week-05/security-governance/</guid><description>&lt;hr&gt;
&lt;h2 id="1-devsecops-principles"&gt;1. DevSecOps Principles&lt;/h2&gt;
&lt;p&gt;Let&amp;rsquo;s start with how security used to work, because understanding the old way makes the new way make sense.&lt;/p&gt;</description></item><item><title>Career Positioning &amp; Branding</title><link>/docs/week-05/career-positioning-branding/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>/docs/week-05/career-positioning-branding/</guid><description>&lt;hr&gt;
&lt;h2 id="1-resume-structuring-for-ai-infrastructure-roles"&gt;1. Resume Structuring for AI Infrastructure Roles&lt;/h2&gt;
&lt;p&gt;Your resume is not a list of things you did. It is a marketing document whose only job is to get you an interview. Every word on it should serve that purpose. AI infrastructure roles — DevOps, MLOps, Platform Engineering, SRE — have specific expectations, and your resume needs to be structured to match those expectations immediately, because the person reading it is spending 15-30 seconds on first pass.&lt;/p&gt;</description></item></channel></rss>