diff --git a/README.md b/README.md index 5334095..c13c306 100644 --- a/README.md +++ b/README.md @@ -4,7 +4,7 @@ **🌐 Live Website**: [https://codexecutives.com](https://codexecutives.com) -**✨ Now featuring 12 complete learning modules with 78+ interactive visualizations covering Git, JavaScript Engine, RxJS, Data Structures, Next.js, Big-O Notation, Python Programming, AI Fundamentals, Node.js Ecosystem, and a LeetCode-style playground with advanced debugging and gamification.** +**✨ Now featuring 13 complete learning modules with 84+ interactive visualizations covering Git, JavaScript Engine, RxJS, Data Structures, Next.js, Big-O Notation, Python Programming, AI Fundamentals, Node.js Ecosystem, DevOps & Cloud Computing, and a LeetCode-style playground with advanced debugging and gamification.** > **📌 Repository Maintainers**: See [REPOSITORY-ABOUT-QUICK-REFERENCE.md](./docs/REPOSITORY-ABOUT-QUICK-REFERENCE.md) for GitHub repository About section configuration (description, website, and topics). @@ -21,6 +21,7 @@ - **Python Programming**: Complete Python tutorial covering philosophy, execution model, memory management, and concurrency - **AI Fundamentals**: Machine learning concepts from scratch — neural networks, gradient descent, embeddings, and RAG pipelines - **Node.js Ecosystem**: Deep dive into Event Loop, V8 memory, Streams, Clustering, module systems, package managers, frameworks, and runtime wars (Node vs Deno vs Bun) +- **DevOps & Cloud Computing**: CI/CD pipelines, cloud service models (IaaS/PaaS/SaaS/FaaS), container orchestration with Kubernetes, Infrastructure as Code, observability, and modern DevOps roles - **LeetCode-Style Playground**: Interactive coding environment with debugging, visualizations, and gamification ### 🎮 **Interactive Visualizations** @@ -324,6 +325,19 @@ Master machine learning concepts from the ground up with interactive visualizati - **Beginner Friendly**: Every section includes ELI10 boxes, real-world analogies, and key takeaways - **11 Interactive Sections**: Progressive visualizations guiding learners from zero ML knowledge to RAG pipelines +### ☁️ **DevOps & Cloud Computing (Complete)** + +Comprehensive DevOps and cloud computing module with 6 interactive visualizations covering the entire DevOps lifecycle: + +- **Introduction**: DevOps history, genesis timeline (2007-2011), the infinite DevOps loop, and Netflix case study +- **CI/CD Pipeline**: Interactive pipeline simulation with 7 stages, terminal logs, deployment strategies (blue-green, canary, rolling) +- **Cloud Service Models**: Interactive IaaS/PaaS/SaaS/FaaS comparison with pizza analogy, NIST characteristics, and management burden visualization +- **Cloud Architecture**: SVG diagrams for monolith, microservices, serverless, and load-balanced patterns with trade-off analysis +- **Container Orchestration**: Kubernetes pod simulator with auto-scaling, Docker fundamentals, container vs VM comparison +- **Infrastructure as Code**: Terraform/Ansible/Docker code examples, declarative vs imperative approaches, GitOps workflow, and drift detection +- **Modern Dev Roles**: Frontend cloud developer, backend serverless developer, DevOps/platform engineer, SRE roles, DevSecOps practices, and career paths +- **Observability**: Three pillars (metrics, logs, traces) with interactive exploration, alerting best practices, incident management, DORA metrics, and future trends + ### 🎯 **LeetCode-Style Playground (Complete)** Interactive coding environment that transforms algorithm learning through visual debugging and gamification: @@ -415,7 +429,7 @@ This project is licensed under the MIT License - see the [LICENSE](LICENSE) file - 📧 **Issues**: Report bugs or request features via GitHub Issues - 💬 **Discussions**: Join community discussions for questions and ideas - 📖 **Documentation**: Comprehensive docs available in the `/docs` directory -- 🎓 **Learning Modules**: 8 complete interactive modules with 80+ visualizations +- 🎓 **Learning Modules**: 13 complete interactive modules with 84+ visualizations - 🎯 **Playground**: LeetCode-style coding environment with debugging and gamification --- diff --git a/docs/DevOps and Cloud Computing Explained.md b/docs/DevOps and Cloud Computing Explained.md new file mode 100644 index 0000000..49c2af0 --- /dev/null +++ b/docs/DevOps and Cloud Computing Explained.md @@ -0,0 +1,269 @@ +# **The Modern Developer's Guide to DevOps and Cloud Computing: A Comprehensive and Visual Analysis** + +The digital landscape has undergone a monumental transformation over the past several decades. In the nascent stages of the software industry, developing and delivering applications required immense physical and logistical effort. Building an application in the 1990s involved purchasing expensive hardware, physically racking servers in climate-controlled rooms, and managing the intricate supply chains required to maintain them.1 Today, the paradigm of software delivery is defined by speed, infinite scalability, and rigorous automation. This transformation has been driven largely by the advent of DevOps methodologies and cloud computing architectures.1 + +This comprehensive analysis provides an exhaustive exploration of these paradigms, detailing their historical origins, mechanical functions, architectural patterns, and the specialized roles that sustain them. Furthermore, bridging the gap between highly technical concepts and foundational learning, this report provides tangible analogies suitable for a ten-year-old student, alongside concrete, actionable visualization guidelines for Artificial Intelligence (AI) agents to render these concepts into digestible architectural diagrams. + +## **The Genesis and Evolution of DevOps** + +To truly understand the modern developer ecosystem, it is essential to trace the origins of DevOps. For decades, the software industry operated under traditional, siloed development models, most notably the Waterfall methodology.3 This approach created a rigid boundary between the professionals who wrote the code (Developers) and the professionals who deployed, monitored, and maintained that code in production environments (IT Operations).4 + +### **Why DevOps Came into Existence** + +The DevOps movement began to coalesce between 2007 and 2008 as a direct response to what the technical community identified as a fatal level of dysfunction within the IT industry.4 Developers and Operations professionals operated with separate, and often fundamentally competing, objectives. Developers were incentivized to push new features and updates rapidly to satisfy business demands, while Operations teams were judged on system stability, security, and maximum uptime.4 The result was the infamous "Wall of Confusion," characterized by separate department leadership, distinct key performance indicators, botched software releases, and deeply unhappy customers.4 + +The conceptual breakthrough occurred in June 2009 at the O'Reilly Velocity Conference. John Allspaw and Paul Hammond delivered a seminal presentation titled "10+ Deploys a Day: Dev and Ops Cooperation at Flickr".5 This presentation demonstrated that it was possible for development and operations teams to integrate their workflows seamlessly. The talk resonated globally, particularly with Patrick Debois, an IT consultant in Belgium who had previously attempted to discuss these issues at an Agile conference with Andrew Clay Shafer.5 Emboldened by the Flickr presentation, Debois organized a gathering of developers and system administrators to discuss bridging the gap between the two disparate fields. He named the event "DevOpsDays," occurring in late October 2009\.5 The resulting conversations sparked lively debates on Twitter, where the hashtag was quickly shortened to simply "DevOps".5 By March 2011, major industry analysts like Cameron Haight of Gartner had recognized DevOps as the next major evolution in IT following Agile methodologies, solidifying its place in the enterprise landscape.5 + +### **Resolving the Crisis: Problems Solved by DevOps** + +DevOps was designed as a cultural movement and technical framework to resolve the inefficiencies of traditional software delivery.6 By utilizing a set of practices, workflows, and open-source tools, it bridges the gap between development and operations.1 + +Traditional models suffered from exceptionally high failure rates for new releases because code was developed in environments that did not accurately mirror production.4 DevOps resolves this by utilizing Infrastructure as Code (IaC), allowing developers to provision environments that are identical to production, drastically lowering the failure rate of new releases.3 Furthermore, traditional systems suffered from slow recovery times. When a system crashed, finding the root cause was a manual, painstaking process. DevOps introduces automated deployment pipelines and robust observability tools, leading to a significantly faster mean time to recovery (MTTR).3 Finally, DevOps dismantles siloed communication. It enforces cross-functional collaboration, ensuring that security, testing, and deployment are shared responsibilities rather than isolated phases executed by different departments on different floors of a building.4 + +### **The Core Benefits of Implementation** + +Organizations that implement DevOps report profound, measurable benefits. A comprehensive survey of DevOps practitioners revealed that 99% of DevOps teams feel highly confident in the success of the code they deploy into production.4 Integration targets such as continuous testing, quality testing, and feature development lead to significantly shorter times to market and improved productivity.3 + +A premier example of these benefits is Netflix, a pioneer in cloud-native DevOps. By utilizing resilience engineering tools like Chaos Monkey—which intentionally injects failures into the system to test resilience—and Spinnaker for automated deployments, Netflix achieves a 99.5% success rate for production deployments.7 They process an average of 245 daily deployments, and their chaos engineering initiatives have contributed to a 71% reduction in production incidents.7 Research indicates that integrating DevOps into legacy environments via continuous integration and continuous deployment (CI/CD) can lead to a 300% increase in deployment frequency and an 80% reduction in change lead time.7 + +### **Who is DevOps For and When Should It Be Used?** + +DevOps is designed for cross-functional teams comprising software engineers, system administrators, quality assurance testers, and security professionals.9 In modern frameworks like Scrum, these practitioners are collectively referred to as "Developers," emphasizing a shared accountability for creating a usable increment of a product.8 + +A team should adopt DevOps practices when they experience bottlenecks in code delivery, when scaling applications becomes too complex for manual intervention, or when attempting to maximize predictability, efficiency, security, and maintainability.3 The adoption is particularly crucial when an organization migrates its infrastructure to the cloud, as traditional siloed approaches simply cannot handle the agile, scalable, and highly available demands of distributed cloud environments.7 Teams utilizing microservices architectures—where monolithic applications are broken into smaller, independent services—must adopt DevOps to manage the decentralized and autonomous nature of their deployments.7 + +## **The Foundations and Mechanics of Cloud Computing** + +If DevOps represents the cultural and operational shift necessary for modern software delivery, cloud computing provides the underlying technological foundation that makes such rapid iteration possible. + +### **What is Cloud Computing and Why Did It Emerge?** + +The International Organization for Standardization (ISO) defines cloud computing as "a paradigm for enabling network access to a scalable and elastic pool of shareable physical or virtual resources with self-service provisioning and administration on demand".11 + +Historically, organizations had to purchase massive, prohibitively expensive mainframe computers to process data.12 These machines required specialized, climate-controlled rooms with immense power and cooling capabilities.2 Procurement cycles for this physical hardware often took months.13 Businesses were forced into a high-stakes guessing game regarding capacity planning. If they over-purchased, they wasted millions on servers that sat idle; if they under-purchased, their systems crashed during unexpected traffic spikes.13 Cloud computing emerged to solve this structural inefficiency by transforming capital expenditures—the buying of physical hardware—into operational expenses, where businesses rent compute power as a utility.13 + +The history of the cloud spans several distinct eras. During the 1950s and 1960s, the concept of shared computing resources originated with mainframes using "time-sharing" schedules, allowing multiple users to access a single central computer from connected stations.12 Through the 1970s and 1980s, research into virtual machines (VMs) and Virtual Private Networks (VPNs) advanced significantly, allowing multiple isolated operating environments to run simultaneously on a single piece of physical hardware.14 By the early 2000s, the modern public cloud began to take shape as companies like Amazon and Google offered businesses the ability to outsource data storage and infrastructure.14 The "first generation cloud" between 2005 and 2011 saw the articulation of Service Level Agreements (SLAs) and the launch of massive open-source orchestration projects like OpenStack.15 The "second generation cloud" from 2012 onward introduced real-time streaming data processing, non-relational databases, and the massive proliferation of container services, fueling the microservices architectures used today.15 + +### **How Cloud Computing Works** + +Cloud computing operates by pooling hardware, software, and networking resources in remote, globally distributed data centers managed by Cloud Service Providers (CSPs).2 Users do not need to manage the individual networked elements; instead, they access a virtual pool of shared resources over the internet.11 A central control server handles all communication between client devices and the remote servers, facilitating seamless data exchange and request routing.13 + +The hallmark of this technology is elasticity. Organizations can automatically scale resources up or down precisely when required, ensuring they only pay for what they consume.11 This provides unprecedented flexibility, allowing enterprises to deploy digital solutions globally with near-zero latency by placing applications in regions and availability zones closest to their end users.13 + +### **Common Architectural Patterns in Cloud Computing** + +To harness the full power of the cloud, software architects employ specific design patterns that dictate how applications are structured, deployed, and scaled. + +| Architectural Pattern | Technical Description | Primary Benefits and Implications | +| :---- | :---- | :---- | +| **Multi-Tenancy** | A foundational technology where cloud providers manage multiple customers (tenants) on shared physical infrastructure while maintaining strict logical data isolation.16 | Highly cost-efficient, as computing resources are pooled and utilized effectively. It allows dynamic reallocation of capacity across thousands of tenants without spinning up entirely new environments.17 | +| **Microservices** | An approach where traditional monolithic applications are broken down into smaller, independent, and modular services that communicate via APIs.7 | Decentralized teams can develop, test, deploy, and scale their specific domains independently. This massively accelerates time-to-market and isolates failures.7 | +| **Serverless (Event-Driven)** | An architecture where the cloud provider dynamically manages the allocation and provisioning of machine resources. Code executes strictly in response to defined triggers or events.18 | Eliminates all infrastructure management for the developer. Applications scale automatically from zero to planet-scale and bill only for the exact milliseconds of compute time used.13 | +| **Load Balancing** | A pattern that distributes incoming network traffic evenly across a group of backend servers, containers, or distinct geographical cloud regions.13 | Ensures high availability, prevents any single server from becoming a bottleneck, and maintains overall system resilience during extreme traffic spikes.13 | +| **Cache-Aside** | A performance optimization strategy where frequently accessed data is stored in a high-speed temporary storage layer, checked prior to querying the primary database.18 | Drastically reduces database query load, decreases response latency, and heavily optimizes application performance for end users.18 | +| **Valet Key** | Utilizing a token or temporary key to provide clients with restricted, direct access to a specific resource or service without routing through the main application.20 | Improves security, optimizes cost, and maximizes performance efficiency by offloading large data transfers directly to storage solutions.20 | + +## **Demystifying Cloud Service Models** + +Cloud computing is categorized by the degree of management responsibility and the level of control an organization retains over its environment. The "shared responsibility model" dictates the exact boundary between what the cloud service provider secures and manages, and what the customer is obligated to secure and manage.21 + +| Service Model | Definition and Mechanics | Shared Responsibility Boundary | Real-World Example | +| :---- | :---- | :---- | :---- | +| **Infrastructure as a Service (IaaS)** | Delivers the fundamental building blocks of cloud IT: virtualized computing resources, physical servers, storage space, and networking hardware.13 | The provider manages the physical data center, physical servers, and network topology. The user retains complete control and responsibility over the operating system, middleware, databases, applications, and security patches.13 | Google Compute Engine provides highly configurable virtual machines where users can select specific vCPUs, memory, and accelerators (like GPUs for AI).13 | +| **Platform as a Service (PaaS)** | Abstracts the underlying physical infrastructure and operating systems, providing a fully managed environment specifically designed for application development and deployment.13 | The provider manages the hardware, operating systems, capacity planning, load balancing, and software patching. The user only manages the application code and the underlying data schemas.13 | Google App Engine allows developers to deploy applications written in Node.js or Python with zero server configuration, automatically scaling based on web traffic.13 | +| **Software as a Service (SaaS)** | Delivers fully functional, ready-to-use software applications over the internet, typically accessed via a standard web browser on a subscription basis.24 | The provider manages the entire stack: infrastructure, platform runtime, application functionality, security, and updates. The user is only responsible for managing their specific user data and access controls.13 | Google Workspace provides cloud-based email, document editing, and video conferencing without requiring the user to install any localized server software.13 | +| **Containers as a Service (CaaS)** | Delivers the managed hardware and software orchestration resources needed to build, deploy, and scale containerized applications (such as Docker containers).13 | The provider manages the container orchestration plane and the underlying host virtual machines. The user manages the containerized application logic and internal container security.13 | Google Kubernetes Engine (GKE) provides a managed environment for running enterprise container workloads, supporting massive clusters for AI and machine learning.13 | +| **Function as a Service (FaaS)** | The pure embodiment of serverless computing. Developers deploy small, single-purpose snippets of code that execute in response to events (e.g., file uploads, webhooks).13 | The provider completely abstracts all infrastructure, scaling, and runtime environments. The user provides only the specific function code and configures the event triggers.13 | Cloud Run Functions execute code in response to data changes in Cloud Storage or Pub/Sub events, billing exclusively down to the nearest 100 milliseconds of execution time.13 | + +Many modern enterprises do not rely on a single model. Instead, they use a hybrid layered approach. For example, a company might run highly customized legacy applications on IaaS, develop new innovative microservices using PaaS, and rely on SaaS for their internal corporate communication and collaboration tools.25 This allows organizations to optimize cost and efficiency by utilizing the exact right level of abstraction for every specific task.25 + +## **The Evolving Roles and Responsibilities of Modern Developers** + +The transition to distributed cloud architectures and DevOps methodologies has fundamentally rewritten the job descriptions of software professionals. The traditional model, where a software engineer wrote code locally and handed it over a proverbial wall to a system operator, is obsolete.26 Today, responsibilities are deeply intertwined, requiring a combination of coding proficiency, systems thinking, and infrastructure management.9 + +### **The Software Engineer and Full-Stack Reality** + +The title "Software Engineer" operates as an umbrella classification for developers across all disciplines.27 In a DevOps culture, software engineers are integrated into Business System Teams that own the entire product lifecycle.8 They are no longer responsible just for writing algorithms; they are accountable for developing, testing, deploying, and maintaining their application code across the entire engineering pipeline.8 They utilize self-service infrastructure portals and API-driven automation to provision the resources they need without waiting for a separate IT department.8 They must possess a "service mindset," prioritizing quality by addressing defects early and actively participating in Agile methodologies like Scrum, where they manage the Sprint Backlog and adapt their plans daily.8 + +### **The Frontend Developer: From Pixels to the Edge Cloud** + +Traditionally, frontend developers were solely responsible for the user interface (UI) and user experience (UX), designing what the user sees using HTML, CSS, and JavaScript.28 Their primary goal was to ensure aesthetic appeal and cross-platform responsiveness.31 + +However, in the modern cloud era, the emergence of the "frontend cloud" has expanded their responsibilities deeply into global infrastructure management.32 Frontend developers now manage Content Delivery Networks (CDNs), configuring complex caching rules to reduce latency by delivering static and dynamic assets from edge nodes physically located near the user's browser.33 They are responsible for configuring traffic at the CDN level, managing IP allow lists, and analyzing vast volumes of CDN logs to spot issues in resource utilization.33 + +Furthermore, frontend developers now leverage "Edge Functions." These are lightweight, serverless functions deployed directly to the CDN edge rather than a centralized backend.35 Frontend engineers use these edge functions to manipulate HTTP requests, localize content, conduct A/B testing, and verify authentication tokens before a request ever reaches the main database, thereby minimizing latency and improving system reliability.36 This shift has allowed frontend responsibilities to merge with traditional backend concepts, creating a far more versatile engineering role.32 + +### **The Backend Developer: Serverless Architecture and Data Security** + +Backend developers build the invisible structure that powers the application, focusing on core application logic, database architecture, and APIs.29 Their main goal is to create reliable, performant architectures that handle data securely and efficiently.31 In the DevOps era, their responsibilities have merged significantly with cloud infrastructure provisioning. + +One of the most complex responsibilities for a modern backend developer is managing serverless database migrations. Traditionally, modifying a database schema (adding columns, creating indexes) required logging into a physical server via SSH.37 Today, backend developers utilize tools like Knex.js or Prisma to write programmatic up functions (to apply changes) and down functions (to revert changes).37 They package these migration scripts into Docker containers and execute them as serverless, one-off jobs (e.g., using Cloud Run Jobs).37 This process requires the backend developer to integrate the migration job securely into the CI/CD pipeline, manage database credentials via Secret Manager, and monitor the database for lock-heavy changes or performance regressions.37 + +Additionally, backend security practices demand that developers implement secure coding standards, encrypt sensitive data both in transit and at rest, and construct robust authorization systems.31 They must ensure that API endpoints can handle millions of simultaneous queries without succumbing to race conditions or unhandled exceptions that could corrupt data.38 + +### **The DevOps Engineer: The Infrastructure Orchestrator** + +A DevOps Engineer is an IT generalist possessing a wide-ranging skill set that spans both software development and infrastructure operations.9 Their primary responsibility is to bridge the divide between siloed teams and ensure smooth software delivery pipelines.9 They are often the engineers building the "paved road" or internal developer platforms that allow other engineers to work efficiently.8 + +The day-to-day responsibilities of a DevOps engineer include provisioning and adapting infrastructure components using Infrastructure as Code (IaC) tools like Terraform and Ansible.8 They build and maintain the Continuous Integration and Continuous Deployment (CI/CD) pipelines, automating the building, testing, and deployment of application code.8 DevOps engineers are also heavily involved in DevSecOps, ensuring infrastructure security through automated patch management and the integration of cybersecurity vulnerability scanners directly into the deployment workflow.7 Furthermore, they must possess the interpersonal skills necessary to foster a culture of collaboration, helping frontend developers understand deployment patterns and helping backend developers prioritize operability.9 + +While debates frequently arise across the industry regarding which role is more difficult, the reality is that each discipline manages a different form of extreme complexity. Frontend developers face the immediate scrutiny of user interaction and infinite browser discrepancies.38 Backend developers juggle the immense pressure of system architecture where a single poorly optimized query can crash the platform.38 DevOps engineers carry the intense operational burden of on-call rotations and ensuring that both sides function seamlessly together.38 + +## **Visualizing the Intangible: Metaphors for a Ten-Year-Old** + +Explaining distributed cloud systems, immutable infrastructure, and DevOps cultural philosophies to a ten-year-old child—or a non-technical executive—requires translating abstract digital mechanics into tangible, highly visual real-world examples.22 + +### **Metaphor 1: The Magic Toy Box (Understanding Cloud Storage)** + +To explain the concept of the cloud, imagine a child who loves toys but has a physical toy box in their bedroom that keeps getting full.39 If they want to play with a toy at their grandparents' house, they have to physically carry it. + +The cloud is like a magical toy box in the sky.39 This magical box never gets full, and the child can take out or put in toys anytime, anywhere.39 When a child plays games like Minecraft or Roblox, their progress isn't saved directly on the physical tablet in their hands; it is saved in this "magic toy box." This allows them to log in on a completely different computer and instantly resume their game right where they left off.39 The cloud is simply a massive, invisible network of these magic boxes working together to store photos, homework, and videos safely.41 + +### **Metaphor 2: The Pizza as a Service Model (Understanding IaaS, PaaS, SaaS)** + +Understanding the differences in cloud service models can be done by looking at how we procure and eat pizza.22 + +* **On-Premises (Traditional Computing):** This is making a pizza entirely from scratch at home. You must grow the tomatoes, milk the cow for cheese, knead the dough, build the fire, and supply the oven, electricity, and dining table.42 It requires immense effort and preparation before you ever get to eat. +* **Infrastructure as a Service (IaaS):** This is buying a frozen "Take and Bake" pizza from the supermarket.42 The provider supplies the raw, assembled ingredients, but you still need to use your own oven, set your own table, and wash the dishes afterward.42 +* **Platform as a Service (PaaS):** This is ordering pizza delivery.42 The restaurant handles sourcing the ingredients, baking the pizza perfectly, and delivering it to your door. All you have to do is provide the dining room table and the drinks.42 You are focusing only on the final consumption (the code). +* **Software as a Service (SaaS):** This is dining out at a high-end pizza restaurant.42 The restaurant provides the food, the table, the drinks, and does all the cleaning. You just walk in, enjoy the experience, and leave.42 + +### **Metaphor 3: The Lego House and the Magic Button (Understanding Immutable Infrastructure)** + +When explaining how software fails and how DevOps infrastructure works, the Lego metaphor is highly effective.43 + +* **The System:** Imagine a house built entirely out of tens of millions of tiny Lego bricks.43 Software developers write the "house rules" (like an instruction manual that says "no shoes on the carpet"), and each engineer is responsible for keeping a few thousand bricks in order.43 +* **System Drift:** Over time, life happens in the house. A cat knocks a Lego chair over, or a guest spills juice on the Lego carpet. The house slowly drifts away from its perfect, original state, and things stop working smoothly.43 This explains why computers slow down or apps freeze. +* **The DevOps Magic Button:** In the past, a programmer had to manually crawl through the house, find the broken Lego chair, and fix it. Modern cloud engineering and DevOps provide a "Magic Button." When pressed, the entire Lego house is instantly taken apart and rebuilt from scratch in less than a second, perfectly matching the original blueprint, with every single brick exactly where it belongs.43 This explains the concept of automated server deployments and immutable infrastructure. + +### **Metaphor 4: The Sandcastle Builders (Understanding DevOps Culture)** + +How do we explain the day-to-day job of a DevOps engineer? Imagine a group of kids trying to build the ultimate sandcastle on a busy beach.44 Some kids are the Builders (Software Developers) who want to create the tallest, most complex towers possible. Other kids are the Guardians (Operations) trying to stop the ocean waves from destroying the castle.44 Often, the Builders get mad at the Guardians for getting in the way, and the Guardians get mad at the Builders for building towers too close to the water. + +The DevOps engineer is the older sibling who steps in to organize everything. They prepare the perfect, wet sand ahead of time so the Builders can work fast.44 They hand out the best buckets and shovels (developer tools). They draw a safe boundary line on the beach so the Builders know exactly where to build without the waves hitting.44 They make sure everyone is hydrated and wearing sunblock. And critically, if a tower accidentally falls down, they have a photograph of exactly what it looked like five minutes ago so it can be rebuilt instantly.44 + +## **Visualization Guidelines for AI Image Generators** + +For platforms like codexecutives.com that aim to describe the hardest developer topics in a simplified, visualized way, integrating AI image generators (such as Midjourney, DALL-E, or architecture-specific tools like Eraser.io and Miro AI) is critical.45 The industry has moved beyond the "Canvas Era"—where architects wasted hours manually dragging, dropping, and aligning boxes on a screen—into the "Prompt Era".46 Today, generative AI functions as a force multiplier, allowing engineers to simply describe the logic of a system and letting the AI handle the aesthetic rendering.46 + +However, to ensure an AI agent creates accurate, enterprise-grade technical visualizations rather than nonsensical "wrapper" art, strict prompting guidelines must be followed.46 + +### **The Anatomy of a Technical Architecture Prompt** + +An effective prompt for technical diagramming must be written with strict engineering precision.45 An AI agent should be instructed to process prompts based on the following sequential framework: + +1. **Define Structural Components:** Explicitly list out the standalone resources and services required in the diagram (e.g., Load Balancer, API Gateway, Kubernetes Cluster, Relational Database).45 +2. **Establish Hierarchical Groupings:** Define the semantic groups and network boundaries to create logical separation. (e.g., "Enclose the Virtual Machines inside a Virtual Private Cloud (VPC) boundary", "Group the user interfaces under a Client-Side label").45 +3. **Map Sequential Flow:** Write out the exact, directional flow of how data or requests travel through the system. (e.g., "An arrow points from the User Web Browser to the Edge CDN. A bidirectional arrow connects the CDN to the API Gateway").45 + +### **Actionable Prompt Templates for Educational Platforms** + +To generate clear, educational visuals for complex DevOps and cloud topics, utilize the following specialized AI prompts: + +**Prompt 1: Visualizing the DevOps Infinite Loop** + +*AI Agent Instruction Context:* Act as a Senior Cloud Architect. Generate a highly structured architectural diagram representing the DevOps Lifecycle. + +*Structural Components:* Create an infinite figure-eight loop consisting of eight distinct nodes. + +*Hierarchical Groupings:* The left half of the figure-eight loop represents "Development" and the right half represents "Operations". + +*Sequential Flow:* The nodes on the loop must follow this exact clockwise sequence: Plan \-\> Code \-\> Build \-\> Test \-\> Release \-\> Deploy \-\> Operate \-\> Monitor \-\> (back to Plan). + +*Visual Style:* Use a minimalist, modern tech aesthetic. Color-code the Development side in vibrant blue and the Operations side in vibrant green. Add a central intersecting hub labeled "CI/CD Pipeline". + +**Prompt 2: Visualizing Cloud Service Models (The Pizza Analogy)** + +*AI Agent Instruction Context:* Generate a 4-panel comparative infographic illustrating the Cloud Computing Service Models using a pizza restaurant metaphor. + +*Panel 1 (On-Premises):* Render a person making a pizza in a messy home kitchen from scratch. Label it "On-Premises: You manage everything." + +*Panel 3 (PaaS):* Render a pizza delivery driver handing a hot pizza to a person at their front door. Label it "PaaS: Vendor delivers the platform, you provide the dining room." + +*Panel 4 (SaaS):* Render a person sitting at a high-end restaurant being served pizza by a waiter. Label it "SaaS: Vendor manages the entire experience." + +*Visual Style:* Flat vector illustration, vibrant colors, clean and approachable but professional enough for a corporate software presentation. Ensure all labels are clearly legible. + +**Prompt 3: Visualizing Frontend Edge Computing vs. Backend Infrastructure** + +*AI Agent Instruction Context:* Generate a technical architecture diagram showing how a modern Frontend Developer utilizes a CDN to bypass backend latency. + +*Structural Components:* End User (Mobile Phone icon), Edge Node (Server with a lightning bolt icon), Main Cloud Database (Cylinder icon). + +*Sequential Flow:* Draw a fast, solid green arrow from the End User directly to the Edge Node labeled "Cached Data Delivery via Edge Function (5ms)". Draw a dotted red arrow originating from the Edge Node to the Main Cloud Database labeled "Cache Miss / Database Query (100ms)". + +*Hierarchical Groupings:* Place the Edge Node inside a dashed bounding box labeled "Content Delivery Network (CDN) \- Managed by Frontend". Place the Main Cloud Database in a solid bounding box labeled "Backend Serverless Infrastructure". + +**Prompt 4: Visualizing Serverless Database Migrations** + +*AI Agent Instruction Context:* Generate a workflow diagram illustrating a backend developer performing a serverless database migration. + +*Structural Components:* Developer Laptop, CI/CD Pipeline (Gear icon), Cloud Run Job (Container icon), Secret Manager (Vault icon), Cloud SQL Database (Database icon). + +*Sequential Flow:* Arrow 1 from Developer to CI/CD labeled "Git Push Migration Scripts". Arrow 2 from CI/CD to Cloud Run Job labeled "Build and Deploy Container". Arrow 3 from Cloud Run Job pointing to Secret Manager labeled "Fetch DB Credentials securely". Arrow 4 from Cloud Run Job to Cloud SQL Database labeled "Execute Up/Down Schema Changes". + +*Visual Style:* Enterprise architecture aesthetic, utilizing standard cloud provider icons where possible, with clear, unidirectional data flow arrows. + +### **The Future of Diagramming: GenAIOps Workflows** + +For advanced platforms, generating these diagrams should not be a manual, one-off process. When utilizing AI to generate architecture diagrams or automate cloud documentation, practitioners should implement "GenAIOps" (Generative AI Operations).48 + +Modern workflows involve chat-based interactions that leverage Model Context Protocol (MCP) servers.49 This allows the AI agent to pull live, real-world data directly from the cloud environment (such as an AWS Cloud View integration) to ensure the diagrams are grounded in reality.47 By maintaining centralized code hosting for prompt templates, an AI agent can generate multiple variants of a diagram, allowing the human DevOps engineer to review the AI-generated outputs for technical accuracy and strategic alignment before publishing them to the educational platform.47 + +## **Synthesizing the Future of Software Delivery** + +The modern developer operates in an environment that is entirely unrecognizable from the software industry of the late 1990s and early 2000s. The invention of DevOps tore down the artificial walls between code creators and system maintainers, forging a new culture of intense collaboration, rigorous automation, and high-velocity delivery. Simultaneously, the evolution of cloud computing dissolved the physical limitations of hardware, offering infinite, elastic scalability through service models like IaaS, PaaS, and SaaS. + +Within this new paradigm, the responsibilities of developers have expanded and blurred. Frontend developers now push logic to the global edge via CDNs, taking control of latency and delivery. Backend developers execute complex serverless database migrations using ephemeral containers. DevOps engineers orchestrate the pipelines and infrastructure-as-code that bind these processes together securely. By utilizing clear, real-world metaphors—from magic toy boxes to Lego houses—and leveraging precise AI-driven visualization prompts, the immense complexity of these systems can be distilled and understood by anyone. This evolution ensures that teams can continue to build the digital infrastructure of tomorrow with unprecedented speed, security, and reliability. + +#### **Works cited** + +1. Report: The Evolution of DevOps | A Contrary Research Deep Dive, accessed April 2, 2026, [https://research.contrary.com/report/evolution-of-devops](https://research.contrary.com/report/evolution-of-devops) +2. What is cloud computing: Its uses and benefits | McKinsey, accessed April 2, 2026, [https://www.mckinsey.com/featured-insights/mckinsey-explainers/what-is-cloud-computing](https://www.mckinsey.com/featured-insights/mckinsey-explainers/what-is-cloud-computing) +3. History of DevOps – When Did DevOps Become a Thing? \- Bunnyshell, accessed April 2, 2026, [https://www.bunnyshell.com/blog/history-of-devops/](https://www.bunnyshell.com/blog/history-of-devops/) +4. History of DevOps | Atlassian, accessed April 2, 2026, [https://www.atlassian.com/devops/what-is-devops/history-of-devops](https://www.atlassian.com/devops/what-is-devops/history-of-devops) +5. A Brief History of DevOps – BMC Software | Blogs, accessed April 2, 2026, [https://www.bmc.com/blogs/devops-history/](https://www.bmc.com/blogs/devops-history/) +6. How to Explain DevOps in Plain English, accessed April 2, 2026, [https://www.devopsinstitute.com/how-to-explain-devops-in-plain-english/](https://www.devopsinstitute.com/how-to-explain-devops-in-plain-english/) +7. (PDF) The Evolution of DevOps in the Cloud Era \- ResearchGate, accessed April 2, 2026, [https://www.researchgate.net/publication/378039571\_The\_Evolution\_of\_DevOps\_in\_the\_Cloud\_Era](https://www.researchgate.net/publication/378039571_The_Evolution_of_DevOps_in_the_Cloud_Era) +8. Common DevOps Roles and Responsibilities Today: Who's on a ..., accessed April 2, 2026, [https://www.splunk.com/en\_us/blog/learn/devops-roles-responsibilities.html](https://www.splunk.com/en_us/blog/learn/devops-roles-responsibilities.html) +9. What is a DevOps Engineer? | Atlassian, accessed April 2, 2026, [https://www.atlassian.com/devops/what-is-devops/devops-engineer](https://www.atlassian.com/devops/what-is-devops/devops-engineer) +10. DevOps Job Descriptions: Who's on a DevOps Team? \- Coursera, accessed April 2, 2026, [https://www.coursera.org/articles/devops-job-description](https://www.coursera.org/articles/devops-job-description) +11. Cloud computing \- Wikipedia, accessed April 2, 2026, [https://en.wikipedia.org/wiki/Cloud\_computing](https://en.wikipedia.org/wiki/Cloud_computing) +12. A Brief History of Cloud Computing | ECPI University, accessed April 2, 2026, [https://www.ecpi.edu/blog/a-brief-history-of-cloud-computing](https://www.ecpi.edu/blog/a-brief-history-of-cloud-computing) +13. PaaS vs IaaS vs SaaS: What's the difference? | Google Cloud, accessed April 2, 2026, [https://cloud.google.com/learn/paas-vs-iaas-vs-saas](https://cloud.google.com/learn/paas-vs-iaas-vs-saas) +14. The Past and Present of Cloud: The Simplification of How We Live and Work, accessed April 2, 2026, [https://businesstech.bus.umich.edu/blog/the-past-and-present-of-cloud-the-simplification-of-how-we-live-and-work/](https://businesstech.bus.umich.edu/blog/the-past-and-present-of-cloud-the-simplification-of-how-we-live-and-work/) +15. History of the cloud \- BCS, The Chartered Institute for IT, accessed April 2, 2026, [https://www.bcs.org/articles-opinion-and-research/history-of-the-cloud/](https://www.bcs.org/articles-opinion-and-research/history-of-the-cloud/) +16. Multi-Tenant Architecture: How It Works, Pros, and Cons | Frontegg, accessed April 2, 2026, [https://frontegg.com/guides/multi-tenant-architecture](https://frontegg.com/guides/multi-tenant-architecture) +17. Multi-tenancy Matters: Scale \- SailPoint, accessed April 2, 2026, [https://www.sailpoint.com/blog/multi-tenancy-scale-identity-security](https://www.sailpoint.com/blog/multi-tenancy-scale-identity-security) +18. Cloud Computing Patterns Fundamentals To Design Build And Manage Cloud Applications \- CLaME, accessed April 2, 2026, [https://clame.nyu.edu/fetch.php/E095B6/312540/Cloud%20Computing%20Patterns%20Fundamentals%20To%20Design%20Build%20And%20Manage%20Cloud%20Applications.pdf](https://clame.nyu.edu/fetch.php/E095B6/312540/Cloud%20Computing%20Patterns%20Fundamentals%20To%20Design%20Build%20And%20Manage%20Cloud%20Applications.pdf) +19. The Role of Serverless Computing in Backend Development \- Talent500, accessed April 2, 2026, [https://talent500.com/blog/serverless-computing-in-backend-development/](https://talent500.com/blog/serverless-computing-in-backend-development/) +20. Cloud Design Patterns \- Azure Architecture Center \- Microsoft Learn, accessed April 2, 2026, [https://learn.microsoft.com/en-us/azure/architecture/patterns/](https://learn.microsoft.com/en-us/azure/architecture/patterns/) +21. What are Iaas, Paas, Saas and CaaS? | Trend Micro (UK), accessed April 2, 2026, [https://www.trendmicro.com/en\_gb/what-is/cloud-security/iaas-paas-saas.html](https://www.trendmicro.com/en_gb/what-is/cloud-security/iaas-paas-saas.html) +22. Understanding Cloud Misconfigurations — With Pizza and Lego | Trend Micro (US), accessed April 2, 2026, [https://www.trendmicro.com/en\_us/research/21/b/understanding-cloud-misconfigurations-with-pizza-and-lego.html](https://www.trendmicro.com/en_us/research/21/b/understanding-cloud-misconfigurations-with-pizza-and-lego.html) +23. SaaS vs PaaS vs IaaS – Types of Cloud Computing \- AWS, accessed April 2, 2026, [https://aws.amazon.com/types-of-cloud-computing/](https://aws.amazon.com/types-of-cloud-computing/) +24. Cloud Service Models Explained: IaaS, PaaS, and SaaS \- DataCamp, accessed April 2, 2026, [https://www.datacamp.com/blog/cloud-service-models](https://www.datacamp.com/blog/cloud-service-models) +25. What are IaaS, PaaS, and SaaS? \- Microsoft Azure, accessed April 2, 2026, [https://azure.microsoft.com/en-us/resources/cloud-computing-dictionary/what-are-iaas-paas-and-saas](https://azure.microsoft.com/en-us/resources/cloud-computing-dictionary/what-are-iaas-paas-and-saas) +26. Does devops do front end and backend codes? \- Reddit, accessed April 2, 2026, [https://www.reddit.com/r/devops/comments/1dush44/does\_devops\_do\_front\_end\_and\_backend\_codes/](https://www.reddit.com/r/devops/comments/1dush44/does_devops_do_front_end_and_backend_codes/) +27. What's the difference: software engineer versus front-end/back-end/full-stack developer? : r/cscareerquestions \- Reddit, accessed April 2, 2026, [https://www.reddit.com/r/cscareerquestions/comments/nzzuo6/whats\_the\_difference\_software\_engineer\_versus/](https://www.reddit.com/r/cscareerquestions/comments/nzzuo6/whats_the_difference_software_engineer_versus/) +28. Key roles in dev \- Webstarted, accessed April 2, 2026, [https://webstarted.com/blog/key-roles-in-dev](https://webstarted.com/blog/key-roles-in-dev) +29. Front-End vs. Back-End Developer: Understanding the Differences \- Coursera, accessed April 2, 2026, [https://www.coursera.org/articles/front-end-vs-back-end](https://www.coursera.org/articles/front-end-vs-back-end) +30. The Difference Between Front-End vs. Back-End \- ComputerScience.org, accessed April 2, 2026, [https://www.computerscience.org/bootcamps/resources/frontend-vs-backend/](https://www.computerscience.org/bootcamps/resources/frontend-vs-backend/) +31. What's the Difference Between Frontend and Backend in Application Development? \- AWS, accessed April 2, 2026, [https://aws.amazon.com/compare/the-difference-between-frontend-and-backend/](https://aws.amazon.com/compare/the-difference-between-frontend-and-backend/) +32. From CDNs to Frontend Clouds \- Vercel, accessed April 2, 2026, [https://vercel.com/blog/from-cdns-to-frontend-clouds](https://vercel.com/blog/from-cdns-to-frontend-clouds) +33. CDN in AEM as a Cloud Service | Adobe Experience Manager, accessed April 2, 2026, [https://experienceleague.adobe.com/en/docs/experience-manager-cloud-service/content/implementing/content-delivery/cdn](https://experienceleague.adobe.com/en/docs/experience-manager-cloud-service/content/implementing/content-delivery/cdn) +34. Best practices for monitoring CDN logs \- Datadog, accessed April 2, 2026, [https://www.datadoghq.com/blog/monitoring-cdn-logs/](https://www.datadoghq.com/blog/monitoring-cdn-logs/) +35. The Modern CDN Means Complex Decisions for Developers \- The New Stack, accessed April 2, 2026, [https://thenewstack.io/the-modern-cdn-means-complex-decisions-for-developers/](https://thenewstack.io/the-modern-cdn-means-complex-decisions-for-developers/) +36. How edge functions move your back end close to your front end \- Stack Overflow, accessed April 2, 2026, [https://stackoverflow.blog/2023/02/23/how-edge-functions-move-your-back-end-close-to-your-front-end/](https://stackoverflow.blog/2023/02/23/how-edge-functions-move-your-back-end-close-to-your-front-end/) +37. How to Use Serverless Database Migrations Using Cloud Run Jobs ..., accessed April 2, 2026, [https://oneuptime.com/blog/post/2026-02-17-how-to-implement-serverless-database-migrations-using-cloud-run-jobs-and-cloud-sql/view](https://oneuptime.com/blog/post/2026-02-17-how-to-implement-serverless-database-migrations-using-cloud-run-jobs-and-cloud-sql/view) +38. Stop Comparing: Backend, Frontend, DevOps \- What's Actually Hard? \- Medium, accessed April 2, 2026, [https://medium.com/@kmanoj296/stop-comparing-backend-frontend-devops-whats-actually-hard-9f523a09fe9a](https://medium.com/@kmanoj296/stop-comparing-backend-frontend-devops-whats-actually-hard-9f523a09fe9a) +39. How I explained “Cloud Computing” to a 10 year old\! | by Charu Pasternak \- Medium, accessed April 2, 2026, [https://medium.com/@charupasternak25/how-i-explained-cloud-computing-to-a-10-year-old-ac8f39caa96c](https://medium.com/@charupasternak25/how-i-explained-cloud-computing-to-a-10-year-old-ac8f39caa96c) +40. What's a good Programming Metaphor? \[closed\] \- Software Engineering Stack Exchange, accessed April 2, 2026, [https://softwareengineering.stackexchange.com/questions/2410/whats-a-good-programming-metaphor](https://softwareengineering.stackexchange.com/questions/2410/whats-a-good-programming-metaphor) +41. What is the Cloud? ☁️ Saving Files in the Sky\! | Cloud Computing Explained for Kids 5–10, accessed April 2, 2026, [https://www.youtube.com/watch?v=mXzPN0DEGXo](https://www.youtube.com/watch?v=mXzPN0DEGXo) +42. Pizza as a Service analogy: On Prem, IaaS, PaaS & SaaS \- Optimizely, accessed April 2, 2026, [https://www.optimizely.com/insights/blog/pizza-as-a-service/](https://www.optimizely.com/insights/blog/pizza-as-a-service/) +43. A Lego house metaphor for software and hardware failures | by Amy ..., accessed April 2, 2026, [https://medium.com/bits-and-behavior/a-lego-house-metaphor-for-software-and-hardware-failures-a2d2d501fe60](https://medium.com/bits-and-behavior/a-lego-house-metaphor-for-software-and-hardware-failures-a2d2d501fe60) +44. How do you explain DevOps to laypeople/computer-illiterate friends? \- Reddit, accessed April 2, 2026, [https://www.reddit.com/r/devops/comments/1f3dnik/how\_do\_you\_explain\_devops\_to/](https://www.reddit.com/r/devops/comments/1f3dnik/how_do_you_explain_devops_to/) +45. AI Architecture Diagram Generator \- Eraser.io, accessed April 2, 2026, [https://www.eraser.io/ai/architecture-diagram-generator](https://www.eraser.io/ai/architecture-diagram-generator) +46. Top 7 AI Architecture Diagram Generators to Fast-Track Your Documentation (2026), accessed April 2, 2026, [https://medium.com/@cloudairyhq/top-7-ai-architecture-diagram-generators-to-fast-track-your-documentation-2026-14291de06c42](https://medium.com/@cloudairyhq/top-7-ai-architecture-diagram-generators-to-fast-track-your-documentation-2026-14291de06c42) +47. AI for Architecture Diagrams: Draft, Analyze & Document Faster \- Miro, accessed April 2, 2026, [https://miro.com/ai/diagram-ai/architecture-diagram/](https://miro.com/ai/diagram-ai/architecture-diagram/) +48. GenAIOps with prompt flow and Azure DevOps \- Azure Machine Learning | Microsoft Learn, accessed April 2, 2026, [https://learn.microsoft.com/en-us/azure/machine-learning/prompt-flow/how-to-end-to-end-azure-devops-with-prompt-flow?view=azureml-api-2](https://learn.microsoft.com/en-us/azure/machine-learning/prompt-flow/how-to-end-to-end-azure-devops-with-prompt-flow?view=azureml-api-2) +49. Architecture diagrams with generative AI: Leveraging AI agents \- YouTube, accessed April 2, 2026, [https://www.youtube.com/watch?v=p8NU94fiFsg](https://www.youtube.com/watch?v=p8NU94fiFsg) \ No newline at end of file diff --git a/src/App.tsx b/src/App.tsx index dede365..1eb8fc6 100644 --- a/src/App.tsx +++ b/src/App.tsx @@ -29,6 +29,7 @@ const SystemDesignPage = lazy(() => import('./features/systemdesign')); const TypeScriptPage = lazy(() => import('./features/typescript')); const AIFundamentalsPage = lazy(() => import('./features/ai')); const NodeJSPage = lazy(() => import('./features/nodejs')); +const DevOpsPage = lazy(() => import('./features/devops')); const App: React.FC = () => { // Initialize analytics on app mount @@ -172,6 +173,14 @@ const App: React.FC = () => { } /> + + + + } + /> diff --git a/src/components/Header.tsx b/src/components/Header.tsx index 7fb1a90..f37bd91 100644 --- a/src/components/Header.tsx +++ b/src/components/Header.tsx @@ -16,6 +16,7 @@ import { Boxes, Brain, Server, + Cloud, } from 'lucide-react'; import { useUI } from '../shared/contexts'; @@ -123,6 +124,12 @@ const Header: React.FC = () => { icon: , description: 'AI & Machine Learning fundamentals', }, + { + label: 'DevOps', + path: '/devops', + icon: , + description: 'DevOps & Cloud Computing', + }, ], }, ]; @@ -188,6 +195,7 @@ const Header: React.FC = () => { if (path === '/bigo') return 'text-purple-600 bg-purple-50'; if (path === '/ai') return 'text-rose-600 bg-rose-50'; if (path === '/nodejs') return 'text-green-600 bg-green-50'; + if (path === '/devops') return 'text-sky-600 bg-sky-50'; return 'text-gray-700 hover:bg-gray-50'; }; diff --git a/src/components/Sidebar.tsx b/src/components/Sidebar.tsx index 3ce40e5..83f2af9 100644 --- a/src/components/Sidebar.tsx +++ b/src/components/Sidebar.tsx @@ -66,6 +66,13 @@ const getThemeColorClass = ( buttonHover: 'hover:text-green-600', border: 'border-green-100', }, + sky: { + active: 'bg-sky-100 text-sky-800 border-sky-500', + hover: 'hover:bg-sky-50 hover:text-sky-700', + buttonActive: 'text-sky-600 hover:text-sky-700', + buttonHover: 'hover:text-sky-600', + border: 'border-sky-100', + }, }; const colors = colorMap[theme.primary] || colorMap.blue; @@ -338,6 +345,16 @@ const sidebarSections: Record> = { { label: 'Frameworks', path: '/nodejs?section=Frameworks' }, { label: 'Runtime Wars', path: '/nodejs?section=Runtime%20Wars' }, ], + '/devops': [ + { label: 'Introduction', path: '/devops?section=Introduction' }, + { label: 'CI/CD Pipeline', path: '/devops?section=CI%2FCD%20Pipeline' }, + { label: 'Cloud Service Models', path: '/devops?section=Cloud%20Service%20Models' }, + { label: 'Cloud Architecture', path: '/devops?section=Cloud%20Architecture' }, + { label: 'Container Orchestration', path: '/devops?section=Container%20Orchestration' }, + { label: 'Infrastructure as Code', path: '/devops?section=Infrastructure%20as%20Code' }, + { label: 'Modern Dev Roles', path: '/devops?section=Modern%20Dev%20Roles' }, + { label: 'Observability', path: '/devops?section=Observability' }, + ], '/': [], '/about': [], }; @@ -364,7 +381,9 @@ const Sidebar: React.FC = () => { | 'systemdesign' | 'typescript' | 'ai' - | 'nodejs' => { + | 'nodejs' + | 'devops' => { + if (path.includes('/devops')) return 'devops'; if (path.includes('/nodejs')) return 'nodejs'; if (path.includes('/ai')) return 'ai'; if (path.includes('javascript')) return 'javascript'; diff --git a/src/features/devops/DevOpsPage.tsx b/src/features/devops/DevOpsPage.tsx new file mode 100644 index 0000000..b9af9a7 --- /dev/null +++ b/src/features/devops/DevOpsPage.tsx @@ -0,0 +1,51 @@ +import React, { Suspense } from 'react'; +import { useLocation } from 'react-router-dom'; + +// Lazy load section components for better performance +import Introduction from './components/sections/Introduction'; +const CICDPipeline = React.lazy(() => import('./components/sections/CICDPipeline')); +const CloudServiceModels = React.lazy(() => import('./components/sections/CloudServiceModels')); +const CloudArchitecture = React.lazy(() => import('./components/sections/CloudArchitecture')); +const ContainerOrchestration = React.lazy( + () => import('./components/sections/ContainerOrchestration') +); +const InfrastructureAsCode = React.lazy(() => import('./components/sections/InfrastructureAsCode')); +const ModernDevRoles = React.lazy(() => import('./components/sections/ModernDevRoles')); +const Observability = React.lazy(() => import('./components/sections/Observability')); + +const sectionComponents: Record = { + Introduction, + 'CI/CD Pipeline': CICDPipeline, + 'Cloud Service Models': CloudServiceModels, + 'Cloud Architecture': CloudArchitecture, + 'Container Orchestration': ContainerOrchestration, + 'Infrastructure as Code': InfrastructureAsCode, + 'Modern Dev Roles': ModernDevRoles, + Observability, +}; + +function useQuery(): URLSearchParams { + return new URLSearchParams(useLocation().search); +} + +const DevOpsPage: React.FC = () => { + const query = useQuery(); + const section = query.get('section') || 'Introduction'; + const Component = sectionComponents[section] || Introduction; + + return ( +
+ +
+
+ } + > + + + + ); +}; + +export default DevOpsPage; diff --git a/src/features/devops/components/sections/CICDPipeline.tsx b/src/features/devops/components/sections/CICDPipeline.tsx new file mode 100644 index 0000000..19d9573 --- /dev/null +++ b/src/features/devops/components/sections/CICDPipeline.tsx @@ -0,0 +1,169 @@ +import React from 'react'; +import ThemeCard from '../../../../components/shared/ThemeCard'; +import CICDPipelineViz from '../visualizations/2d/CICDPipelineViz'; +import { GitBranch, CheckCircle, AlertTriangle, Lightbulb } from 'lucide-react'; + +const CICDPipeline: React.FC = () => { + return ( +
+ {/* Header */} +
+
+
+ +
+
+

CI/CD Pipeline

+

Continuous Integration & Continuous Delivery

+
+
+

+ A CI/CD pipeline automates the journey from code commit to production deployment. Every + code change is automatically built, tested, scanned for security vulnerabilities, and + deployed — reducing human error and enabling teams to deploy hundreds of times per day. +

+
+ + {/* Interactive Pipeline Visualization */} + +

Interactive Pipeline

+

+ Watch a complete CI/CD pipeline execute. Each stage runs automatically, and the pipeline + halts if any stage fails — this is the "fail fast" principle. +

+ + + + {/* CI vs CD explanation */} +
+ +

+ Continuous Integration (CI) +

+

+ Developers merge their code changes into a shared repository multiple times a day. Each + merge triggers an automated build and test suite. +

+
+

CI Best Practices:

+
    +
  • • Commit to mainline at least once a day
    • +
  • • Every commit triggers automated tests
    • +
  • • Fix broken builds immediately (priority #1)
    • +
  • • Keep the build fast (< 10 minutes)
    • +
+
+ + + +

+ Continuous Delivery (CD) +

+

+ Every change that passes the automated pipeline is ready to deploy to + production. Continuous Deployment goes further — deploying automatically without human + approval. +

+
+

Deployment Strategies:

+
    +
  • + • Blue-Green: Two identical environments, swap traffic +
    • +
  • + • Canary: Roll out to 5% of users first +
    • +
  • + • Rolling: Gradually replace old instances +
    • +
  • + • Feature Flags: Toggle features without deploy +
    • +
+
+ +
+ + {/* Popular CI/CD Tools */} + +

Popular CI/CD Tools

+
+ {[ + { name: 'GitHub Actions', icon: '🐙', desc: 'Native GitHub CI/CD' }, + { name: 'Jenkins', icon: '🔧', desc: 'Open-source automation' }, + { name: 'GitLab CI', icon: '🦊', desc: 'All-in-one DevOps' }, + { name: 'CircleCI', icon: '⭕', desc: 'Cloud-native CI/CD' }, + { name: 'ArgoCD', icon: '🚢', desc: 'GitOps for Kubernetes' }, + { name: 'Spinnaker', icon: '🎡', desc: 'Multi-cloud deploy' }, + { name: 'Travis CI', icon: '🏠', desc: 'Open-source CI' }, + { name: 'AWS CodePipeline', icon: '☁️', desc: 'AWS native pipeline' }, + ].map((tool, i) => ( +
+ {tool.icon} +

{tool.name}

+

{tool.desc}

+
+ ))} +
+ + + {/* Anti-patterns */} + +

+ Common CI/CD Anti-Patterns +

+
+ {[ + { + bad: 'Long-lived feature branches (weeks/months)', + fix: 'Merge to main daily, use feature flags', + }, + { + bad: 'Skipping tests to "ship faster"', + fix: 'Tests ARE the safety net — never skip', + }, + { bad: 'Manual deployment steps', fix: 'Automate everything, including rollbacks' }, + { bad: 'No security scanning', fix: 'Add SAST/DAST/dependency scanning to pipeline' }, + ].map((item, i) => ( +
+
+ ✗ + {item.bad} +
+
+ ✓ + {item.fix} +
+
+ ))} +
+ + + {/* ELI10 */} +
+
+
+ +
+
+

+ Think of it like a factory assembly line 🏭 +

+

+ Imagine a toy factory. When you design a new toy, it goes through stations — each + station checks something: "Is the paint right? Are the wheels on? Is it + safe?" Only if the toy passes ALL stations does it go into a box and ship to + stores. That's exactly what a CI/CD pipeline does for code — each stage verifies + quality automatically! +

+
+
+
+
+ ); +}; + +export default CICDPipeline; diff --git a/src/features/devops/components/sections/CloudArchitecture.tsx b/src/features/devops/components/sections/CloudArchitecture.tsx new file mode 100644 index 0000000..42c2939 --- /dev/null +++ b/src/features/devops/components/sections/CloudArchitecture.tsx @@ -0,0 +1,216 @@ +import React from 'react'; +import ThemeCard from '../../../../components/shared/ThemeCard'; +import CloudArchitectureViz from '../visualizations/2d/CloudArchitectureViz'; +import { Network, Lightbulb, Shield, Zap } from 'lucide-react'; + +const CloudArchitecture: React.FC = () => { + return ( +
+ {/* Header */} +
+
+
+ +
+
+

Cloud Architecture Patterns

+

Monolith, Microservices, Serverless & More

+
+
+

+ Architecture patterns define how applications are structured, deployed, and scaled. + Choosing the right pattern depends on your team size, scale requirements, and operational + maturity — there is no one-size-fits-all solution. +

+
+ + {/* Interactive Architecture Visualization */} + +

Interactive Architecture Diagrams

+

+ Click each pattern to see an interactive architecture diagram with trade-offs and + real-world examples. +

+ + + + {/* Architecture Evolution */} + +

The Architecture Evolution

+
+ {/* Timeline line */} +
+ + {[ + { + era: '2000s', + title: 'Monolithic Architecture', + desc: 'One big application. Simple to develop and deploy, but hard to scale parts independently. A change anywhere requires redeploying everything.', + color: 'sky', + icon: '🏢', + }, + { + era: '2010s', + title: 'Microservices Architecture', + desc: 'Break the monolith into small, independent services. Each team owns their service, deploys independently, and can use different tech stacks.', + color: 'cyan', + icon: '🧩', + }, + { + era: '2015+', + title: 'Serverless / Event-Driven', + desc: 'Write functions, not servers. The cloud provider handles all infrastructure. Functions trigger from events — pay only when code runs.', + color: 'teal', + icon: '⚡', + }, + { + era: '2020+', + title: 'Edge Computing', + desc: 'Push computation to the network edge, closer to users. CDN workers execute code in 300+ locations globally for ultra-low latency.', + color: 'emerald', + icon: '🌍', + }, + ].map((item, i) => ( +
+
+
+ {item.icon} +
+
+
+
+ + {item.era} + +

{item.title}

+
+

{item.desc}

+
+
+ ))} +
+ + + {/* Cloud Design Patterns */} + +

+ Cloud Design Patterns +

+

+ Patterns from Microsoft Azure Architecture Center and AWS Well-Architected Framework: +

+
+ {[ + { + name: 'Cache-Aside', + desc: 'Load data into cache on demand. If not in cache, read from store, place in cache, return. Dramatically reduces database load.', + useCase: 'High-read workloads with rarely changing data', + }, + { + name: 'Circuit Breaker', + desc: 'Stop calling a failing service. After N failures, "open" the circuit and return fallback. Periodically test if the service recovered.', + useCase: 'Preventing cascade failures in distributed systems', + }, + { + name: 'Sidecar', + desc: 'Deploy helper components alongside your main service (logging, monitoring, proxying). The main service stays focused on business logic.', + useCase: 'Service mesh, observability, security policies', + }, + { + name: 'Strangler Fig', + desc: 'Gradually migrate from a monolith by routing traffic to new microservices one endpoint at a time. The old system shrinks until it disappears.', + useCase: 'Incremental monolith-to-microservices migration', + }, + { + name: 'CQRS', + desc: 'Separate read and write operations into different models. Reads can use denormalized views optimized for queries, writes enforce invariants.', + useCase: 'Complex domains with different read/write patterns', + }, + { + name: 'Valet Key', + desc: 'Give clients a limited-access token to access resources directly (e.g., pre-signed S3 URLs) instead of proxying all traffic through your server.', + useCase: 'File uploads, media streaming, CDN access', + }, + ].map((pattern, i) => ( +
+

{pattern.name}

+

{pattern.desc}

+
+ + {pattern.useCase} +
+
+ ))} +
+ + + {/* Decision Guide */} + +

Architecture Decision Guide

+
+ + + + + + + + + + + {[ + { factor: 'Team Size', mono: '1–10', micro: '10–100+', server: 'Any' }, + { + factor: 'Startup Speed', + mono: 'Fast ⚡', + micro: 'Slow 🐢', + server: 'Very Fast ⚡⚡', + }, + { factor: 'Scaling', mono: 'Vertical', micro: 'Horizontal', server: 'Auto' }, + { factor: 'Complexity', mono: 'Low', micro: 'High', server: 'Medium' }, + { factor: 'Cost at Scale', mono: 'Medium', micro: 'Optimized', server: 'Variable' }, + { factor: 'Vendor Lock-in', mono: 'None', micro: 'Low', server: 'High' }, + ].map((row, i) => ( + + + + + + + ))} + +
FactorMonolithMicroservicesServerless
{row.factor}{row.mono}{row.micro}{row.server}
+
+ + + {/* ELI10 */} +
+
+
+ +
+
+

+ Think of it like building with LEGOs 🧱 +

+

+ A monolith is like one giant LEGO structure — if one piece breaks, + the whole thing might fall apart. Microservices are like separate + LEGO sets (spaceship, castle, car) — each works independently.{' '} + Serverless is like a magical LEGO table where pieces assemble + themselves when someone walks by and disappear when nobody's watching! +

+
+
+
+
+ ); +}; + +export default CloudArchitecture; diff --git a/src/features/devops/components/sections/CloudServiceModels.tsx b/src/features/devops/components/sections/CloudServiceModels.tsx new file mode 100644 index 0000000..cdbf3ce --- /dev/null +++ b/src/features/devops/components/sections/CloudServiceModels.tsx @@ -0,0 +1,205 @@ +import React from 'react'; +import ThemeCard from '../../../../components/shared/ThemeCard'; +import CloudServiceModelsViz from '../visualizations/2d/CloudServiceModelsViz'; +import { Cloud, Lightbulb, Server, TrendingUp } from 'lucide-react'; + +const CloudServiceModels: React.FC = () => { + return ( +
+ {/* Header */} +
+
+
+ +
+
+

Cloud Service Models

+

IaaS, PaaS, SaaS, CaaS & FaaS

+
+
+

+ Cloud computing fundamentally changed how we think about infrastructure. Instead of buying + and maintaining physical servers, you rent computing resources on-demand — paying only for + what you use, like an electricity bill. +

+
+ + {/* Interactive Visualization */} + +

Interactive Comparison

+

+ Click each model to see what you manage vs. what the{' '} + provider manages. Toggle the pizza analogy for a fun comparison! +

+ + + + {/* Detailed Service Models */} +
+ +
+ +

IaaS — Infrastructure as a Service

+
+

+ You get raw computing resources — virtual machines, storage, networks — and build + everything on top. Maximum control, maximum responsibility. +

+
+

Examples:

+
    +
  • + • AWS EC2 — Virtual machines +
    • +
  • + • Azure VM — Microsoft's compute +
    • +
  • + • Google Compute Engine — Google's VMs +
    • +
  • + • DigitalOcean Droplets — Developer-friendly VMs +
    • +
+
+ + + +
+ +

PaaS — Platform as a Service

+
+

+ The cloud provider manages the infrastructure — you just deploy your code. No more + worrying about OS patches, load balancers, or scaling servers. +

+
+

Examples:

+
    +
  • + • Heroku — Simple app deployment +
    • +
  • + • Google App Engine — Google-managed platform +
    • +
  • + • Azure App Service — Microsoft PaaS +
    • +
  • + • Railway / Render — Modern PaaS alternatives +
    • +
+
+ + + +
+ +

SaaS — Software as a Service

+
+

+ Fully managed applications delivered over the internet. Users access everything through + a browser — no installation, no maintenance. +

+
+

Examples:

+
    +
  • + • Google Workspace — Docs, Sheets, Gmail +
    • +
  • + • Salesforce — CRM platform +
    • +
  • + • Slack / Teams — Communication +
    • +
  • + • GitHub — Code hosting & collaboration +
    • +
+
+ + + +
+ +

FaaS — Functions as a Service

+
+

+ The purest form of serverless. You write individual functions that execute in response + to events. Zero infrastructure to manage — scales to zero when idle. +

+
+

Examples:

+
    +
  • + • AWS Lambda — Amazon's serverless compute +
    • +
  • + • Azure Functions — Microsoft serverless +
    • +
  • + • Google Cloud Functions — Google serverless +
    • +
  • + • Cloudflare Workers — Edge functions +
    • +
+
+ +
+ + {/* NIST Definition */} + +

+ NIST's 5 Essential Characteristics +

+

+ The National Institute of Standards and Technology defines cloud computing with 5 + essential traits: +

+
+ {[ + { + title: 'On-Demand Self-Service', + desc: 'Provision resources without human intervention', + }, + { title: 'Broad Network Access', desc: 'Access from any device over the network' }, + { title: 'Resource Pooling', desc: 'Multi-tenant model for shared resources' }, + { title: 'Rapid Elasticity', desc: 'Scale up/down instantly to match demand' }, + { title: 'Measured Service', desc: 'Pay only for what you consume' }, + ].map((char, i) => ( +
+
+ {i + 1} +
+

{char.title}

+

{char.desc}

+
+ ))} +
+ + + {/* ELI10 */} +
+
+
+ +
+
+

The Pizza Analogy 🍕

+

+ On-Premises = Making pizza at home (you do everything).{' '} + IaaS = Renting a kitchen (you bring ingredients & cook).{' '} + PaaS = Take-and-bake pizza (oven & dough provided, you add + toppings). SaaS = Pizza delivery (just eat!). FaaS = + Pizza by the slice (pay per bite, no waste). +

+
+
+
+
+ ); +}; + +export default CloudServiceModels; diff --git a/src/features/devops/components/sections/ContainerOrchestration.tsx b/src/features/devops/components/sections/ContainerOrchestration.tsx new file mode 100644 index 0000000..810a09b --- /dev/null +++ b/src/features/devops/components/sections/ContainerOrchestration.tsx @@ -0,0 +1,247 @@ +import React from 'react'; +import ThemeCard from '../../../../components/shared/ThemeCard'; +import ContainerOrchestrationViz from '../visualizations/2d/ContainerOrchestrationViz'; +import { Container, Lightbulb, CheckCircle, Box } from 'lucide-react'; + +const ContainerOrchestration: React.FC = () => { + return ( +
+ {/* Header */} +
+
+
+ +
+
+

Container Orchestration

+

Docker, Kubernetes & Container Management

+
+
+

+ Containers package your code with everything it needs to run — the same way every time, + everywhere. Orchestrators like Kubernetes manage fleets of containers at scale, + automatically handling scaling, healing, and load balancing. +

+
+ + {/* Interactive Kubernetes Simulation */} + +

Kubernetes Pod Simulator

+

+ Scale pods up and down, watch auto-scaling in action, and see how Kubernetes maintains + desired state even when pods fail. +

+ + + + {/* Docker Fundamentals */} +
+ +
+ +

Docker Fundamentals

+
+

+ Docker packages applications into containers — lightweight, isolated + environments that include everything needed to run: code, runtime, libraries, and system + tools. +

+
+
# Dockerfile example
+
+ FROM node:20-alpine +
+
+ WORKDIR /app +
+
+ COPY package*.json ./ +
+
+ RUN npm ci --production +
+
+ COPY . . +
+
+ EXPOSE 3000 +
+
+ CMD ["node", "server.js"] +
+
+ + + +
+ +

Container vs. VM

+
+

+ Containers share the host OS kernel, making them much lighter than virtual machines. A + VM needs its own full OS — containers just need the application layers. +

+
+
+

Containers 📦

+
    +
  • ✅ Start in milliseconds
    • +
  • ✅ MBs in size (vs. GBs)
    • +
  • ✅ Share host OS kernel
    • +
  • ✅ Run 100s per host
    • +
+
+
+

Virtual Machines 🖥️

+
    +
  • ⚠️ Start in minutes
    • +
  • ⚠️ GBs in size
    • +
  • ✅ Full OS isolation
    • +
  • ⚠️ Run 10–20 per host
    • +
+
+
+ +
+ + {/* Kubernetes Concepts */} + +

Kubernetes Core Concepts

+
+ {[ + { + title: 'Pod', + desc: 'Smallest deployable unit. Contains one or more containers that share network and storage.', + icon: '🫛', + }, + { + title: 'Deployment', + desc: 'Declares desired state (e.g., "run 3 replicas"). K8s ensures reality matches the declaration.', + icon: '📋', + }, + { + title: 'Service', + desc: 'Stable network endpoint that routes traffic to pods. Pods come and go, the Service stays.', + icon: '🌐', + }, + { + title: 'Ingress', + desc: 'HTTP routing layer. Maps external URLs to internal services with TLS termination.', + icon: '🚪', + }, + { + title: 'ConfigMap / Secret', + desc: 'Decouple configuration from code. Secrets are base64-encoded and access-controlled.', + icon: '🔐', + }, + { + title: 'Namespace', + desc: 'Virtual cluster within a cluster. Isolate environments (dev, staging, prod) on shared infra.', + icon: '📁', + }, + ].map((concept, i) => ( +
+ {concept.icon} +

{concept.title}

+

{concept.desc}

+
+ ))} +
+ + + {/* Container Tools Ecosystem */} + +

Container Ecosystem

+
+ {[ + { name: 'Docker', category: 'Runtime', color: 'sky' }, + { name: 'Kubernetes', category: 'Orchestration', color: 'sky' }, + { name: 'Helm', category: 'Package Mgr', color: 'cyan' }, + { name: 'Istio', category: 'Service Mesh', color: 'cyan' }, + { name: 'Podman', category: 'Runtime (rootless)', color: 'teal' }, + { name: 'containerd', category: 'Container Runtime', color: 'teal' }, + { name: 'Docker Compose', category: 'Local Dev', color: 'emerald' }, + { name: 'Rancher', category: 'K8s Management', color: 'emerald' }, + ].map((tool, i) => ( +
+

{tool.name}

+ {tool.category} +
+ ))} +
+ + + {/* Best Practices */} + +

+ Container Best Practices +

+
+ {[ + { + practice: 'Use multi-stage builds', + why: 'Keep images small — build in one stage, copy artifacts to a minimal runtime image', + }, + { + practice: 'One process per container', + why: 'Containers should do one thing well — easier to scale, debug, and replace', + }, + { + practice: 'Never run as root', + why: 'Use USER directive in Dockerfile to run as non-root for security', + }, + { + practice: 'Use health checks', + why: 'HEALTHCHECK instruction lets K8s know when to restart unhealthy containers', + }, + { + practice: 'Pin image versions', + why: 'Use node:20.11-alpine, not node:latest — avoid surprise breaking changes', + }, + { + practice: 'Scan for vulnerabilities', + why: 'Use tools like Trivy, Snyk, or Docker Scout to find CVEs in your images', + }, + ].map((item, i) => ( +
+ +
+

{item.practice}

+

{item.why}

+
+
+ ))} +
+ + + {/* ELI10 */} +
+
+
+ +
+
+

+ Think of it like a shipping port 🚢 +

+

+ Docker containers are like shipping containers — they hold everything + your app needs in a standard box that works on any ship (server).{' '} + Kubernetes is the port authority — it decides which containers go on + which ships, replaces damaged containers, and makes sure everything arrives on time. + If one ship sinks, K8s moves the containers to another ship automatically! +

+
+
+
+
+ ); +}; + +export default ContainerOrchestration; diff --git a/src/features/devops/components/sections/InfrastructureAsCode.tsx b/src/features/devops/components/sections/InfrastructureAsCode.tsx new file mode 100644 index 0000000..83bbf0d --- /dev/null +++ b/src/features/devops/components/sections/InfrastructureAsCode.tsx @@ -0,0 +1,284 @@ +import React from 'react'; +import ThemeCard from '../../../../components/shared/ThemeCard'; +import InfrastructureAsCodeViz from '../visualizations/2d/InfrastructureAsCodeViz'; +import { FileCode, Lightbulb, CheckCircle, AlertTriangle } from 'lucide-react'; + +const InfrastructureAsCode: React.FC = () => { + return ( +
+ {/* Header */} +
+
+
+ +
+
+

Infrastructure as Code

+

Terraform, Ansible, CloudFormation & GitOps

+
+
+

+ Infrastructure as Code (IaC) treats infrastructure like software — define servers, + networks, and databases in code files that are version-controlled, code-reviewed, and + automatically provisioned. No more clicking through console GUIs. +

+
+ + {/* Interactive IaC Visualization */} + +

IaC Tools & Workflow

+

+ Explore different IaC tools, see example configurations, and understand the plan → apply → + detect drift → reconcile workflow. +

+ + + + {/* Declarative vs Imperative */} +
+ +

+ Declarative (WHAT) +

+

+ You describe the desired end state — the tool figures out how to get + there. If the infrastructure already matches, nothing happens (idempotent). +

+
+
# Terraform (declarative)
+
+ resource{' '} + "aws_instance"{' '} + "web" {'{'} +
+
+ {' '} + ami = "ami-0c55b31" +
+
+ {' '} + instance_type = "t3.micro" +
+
tags = {'{'}
+
+ {' '} + Name = "web-server" +
+
{'}'}
+
{'}'}
+
+
+ + Tools: Terraform, CloudFormation, Pulumi, Kubernetes YAML + +
+ + + +

+ Imperative (HOW) +

+

+ You write step-by-step instructions — the tool executes them in order. + More flexible but harder to make idempotent; order matters. +

+
+
# Ansible (imperative tasks)
+
+ - name: Install nginx +
+
+ {' '} + apt: +
+
+ {' '} + name: nginx +
+
+ {' '} + state: present +
+
+
+ - name: Start nginx +
+
+ {' '} + service: +
+
+ {' '} + name: nginx +
+
+ {' '} + state: started +
+
+
+ + Tools: Ansible, Chef, Puppet, Shell scripts + +
+ +
+ + {/* IaC Tool Comparison */} + +

IaC Tool Comparison

+
+ + + + + + + + + + + + {[ + { + tool: 'Terraform', + type: 'Declarative', + lang: 'HCL', + best: 'Multi-cloud infra', + provider: 'HashiCorp', + }, + { + tool: 'Pulumi', + type: 'Declarative', + lang: 'TS/Python/Go', + best: 'Developer-friendly IaC', + provider: 'Pulumi', + }, + { + tool: 'CloudFormation', + type: 'Declarative', + lang: 'YAML/JSON', + best: 'AWS-only infra', + provider: 'AWS', + }, + { + tool: 'Ansible', + type: 'Imperative', + lang: 'YAML', + best: 'Config management', + provider: 'Red Hat', + }, + { + tool: 'CDK', + type: 'Declarative', + lang: 'TS/Python/Java', + best: 'AWS with real code', + provider: 'AWS', + }, + { + tool: 'Crossplane', + type: 'Declarative', + lang: 'YAML (K8s)', + best: 'K8s-native IaC', + provider: 'CNCF', + }, + ].map((row, i) => ( + + + + + + + + ))} + +
ToolTypeLanguageBest ForProvider
{row.tool}{row.type}{row.lang}{row.best}{row.provider}
+
+ + + {/* GitOps */} + +

+ GitOps — Git as the Source of Truth +

+

+ GitOps is a practice where Git repositories are the single source of truth for both + application code AND infrastructure. Changes to infrastructure happen through pull + requests — the same workflow developers already know. +

+
+ {[ + { step: '1', title: 'Declare', desc: 'Define desired state in Git (YAML, HCL, etc.)' }, + { step: '2', title: 'Review', desc: 'Pull request, code review, approval' }, + { step: '3', title: 'Merge', desc: 'Merge to main branch triggers reconciliation' }, + { step: '4', title: 'Reconcile', desc: 'Operator ensures live state matches Git' }, + ].map((s, i) => ( +
+
+ {s.step} +
+

{s.title}

+

{s.desc}

+
+ ))} +
+
+ + Popular GitOps Tools: ArgoCD, Flux, Jenkins X + +
+ + + {/* Configuration Drift */} + +

+ Configuration Drift +

+

+ Drift occurs when live infrastructure diverges from the declared state — + someone manually changed a security group, scaled an instance, or modified a config. IaC + tools detect and fix drift automatically. +

+
+
+

🔴 Drift Detected

+

Live state differs from declared state in code

+
+
+

🟡 Plan Generated

+

Tool shows what will change to fix drift

+
+
+

🟢 Drift Resolved

+

Apply plan to reconcile state, or update code

+
+
+ + + {/* ELI10 */} +
+
+
+ +
+
+

+ Think of it like a recipe book 📖 +

+

+ Without IaC, setting up servers is like cooking without a recipe — you remember some + steps, forget others, and the result is different every time.{' '} + Infrastructure as Code is writing down the exact recipe. Anyone can + follow it and get the same result. If someone accidentally adds too much salt (changes + a setting), you just re-read the recipe (run{' '} + terraform apply) and + everything goes back to how it should be! +

+
+
+
+
+ ); +}; + +export default InfrastructureAsCode; diff --git a/src/features/devops/components/sections/Introduction.tsx b/src/features/devops/components/sections/Introduction.tsx new file mode 100644 index 0000000..e151d2a --- /dev/null +++ b/src/features/devops/components/sections/Introduction.tsx @@ -0,0 +1,394 @@ +import React from 'react'; +import SectionLayout from '../../../../components/shared/SectionLayout'; +import ThemeCard from '../../../../components/shared/ThemeCard'; +import NavigationCard from '../../../../components/shared/NavigationCard'; +import CTASection from '../../../../components/shared/CTASection'; +import StatsGrid from '../../../../components/shared/StatsGrid'; +import { + Cloud, + GitBranch, + Container, + Shield, + Zap, + Server, + Lightbulb, + RefreshCw, + Layers, + Eye, + Settings, + Users, +} from 'lucide-react'; +import DevOpsInfiniteLoop from '../visualizations/2d/DevOpsInfiniteLoop'; + +const Introduction: React.FC = () => { + const navigateToSection = (sectionName: string): void => { + const baseUrl = '/devops?section='; + const encodedSection = encodeURIComponent(sectionName); + window.location.href = baseUrl + encodedSection; + }; + + const stats = [ + { + value: '7', + label: 'Interactive Sections', + icon: , + }, + { + value: '6+', + label: 'Visualizations', + icon: , + }, + { + value: '99.5%', + label: 'Deploy Success (Netflix)', + icon: , + }, + ]; + + const heroContent = ( +
+
+
+ +
+
+

+ DevOps & Cloud Computing: From Culture to Infrastructure +

+

+ How did software delivery evolve from months-long release cycles to hundreds of daily + deployments? This module explores the DevOps revolution, cloud computing architectures, + CI/CD pipelines, and modern infrastructure — all through interactive visualizations. +

+ +
+ + ♾️ DevOps Lifecycle + + + ☁️ Cloud Models + + + 🐳 Containers + + + 🔄 CI/CD Pipelines + +
+
+ ); + + const mainContent = ( + <> + {/* ELI10 Explanation */} +
+
+
+ +
+
+

Explain Like I'm 10 🧒

+

+ Imagine a group of kids building the ultimate sandcastle on a busy beach. Some kids + are Builders who create the tallest towers. Other kids are{' '} + Guardians trying to protect the castle from ocean waves. Often they + get in each other's way! +

+

+ DevOps is like an older sibling who organizes everything. They + prepare the perfect wet sand, hand out the best buckets (tools), draw a safe boundary + line on the beach, and if a tower falls, they have a photograph of exactly what it + looked like five minutes ago, so it can be rebuilt instantly. +

+

+ The Cloud? It's like a magical toy box in the sky. It never gets + full, and you can take out or put in toys anytime, anywhere. When you play Minecraft, + your progress isn't saved on your tablet — it's saved in this magic box. You + can log in on a completely different computer and continue right where you left off! +

+
+
+
+ + {/* Interactive DevOps Infinite Loop */} + +

The DevOps Infinite Loop

+

+ DevOps is not a tool or a job title — it's a cultural movement that + emerged between 2007-2009 to fix the "Wall of Confusion" between developers and + operations teams. The infinite loop below represents the continuous cycle of planning, + building, deploying, and monitoring software. +

+ + + + {/* History Timeline */} + +

The Genesis of DevOps

+
+ {[ + { + year: '2007-2008', + event: 'The Dysfunction Identified', + desc: 'IT community recognized fatal dysfunction between Dev and Ops teams with separate leadership, competing KPIs, and botched releases.', + }, + { + year: 'June 2009', + event: 'The Velocity Conference Breakthrough', + desc: 'John Allspaw and Paul Hammond presented "10+ Deploys a Day: Dev and Ops Cooperation at Flickr" — proving seamless integration was possible.', + }, + { + year: 'Oct 2009', + event: 'DevOpsDays is Born', + desc: 'Patrick Debois organized the first DevOpsDays in Belgium. Twitter hashtag #DevOps was coined and spread globally.', + }, + { + year: 'March 2011', + event: 'Enterprise Recognition', + desc: 'Gartner analyst Cameron Haight recognized DevOps as the next major evolution in IT, following Agile methodologies.', + }, + { + year: 'Today', + event: '99% Confidence Rate', + desc: 'Surveys show 99% of DevOps teams feel highly confident in their production deployments. Netflix achieves 245 daily deployments.', + }, + ].map((item, i) => ( +
+
+ {item.year} +
+
+
+

{item.event}

+

{item.desc}

+
+
+ ))} +
+ + + {/* Key Problems Solved */} + +

What Problems Does DevOps Solve?

+
+ {[ + { + icon: , + title: 'Slow Release Cycles', + before: 'Monthly or quarterly releases with high failure rates', + after: 'Continuous delivery with automated pipelines — deploy daily or hourly', + }, + { + icon: , + title: 'Environment Mismatches', + before: '"Works on my machine" — dev and prod environments were different', + after: 'Infrastructure as Code ensures identical environments everywhere', + }, + { + icon: , + title: 'Slow Recovery (MTTR)', + before: 'Manual root cause analysis took hours or days', + after: 'Automated rollbacks and observability tools recover in minutes', + }, + { + icon: , + title: 'Siloed Teams', + before: 'Dev, Ops, QA, and Security worked in isolation', + after: 'Cross-functional collaboration with shared accountability', + }, + ].map((item, i) => ( +
+
+
{item.icon}
+

{item.title}

+
+
+
+ ✗ + {item.before} +
+
+ ✓ + {item.after} +
+
+
+ ))} +
+ + + {/* Cloud Computing Origins */} + +

The Rise of Cloud Computing

+
+
+

+ From Mainframes to the Cloud +

+

+ Historically, organizations purchased massive, expensive mainframe computers that + required specialized climate-controlled rooms. Procurement took months, and businesses + had to guess their capacity needs — over-purchasing meant wasted millions; + under-purchasing meant crashes during traffic spikes. +

+

+ Cloud computing solved this by transforming capital expenditures{' '} + (buying hardware) into operational expenses (renting compute power as + a utility). Organizations now scale automatically and pay only for what they use. +

+
+
+

Cloud History Milestones

+
+ {[ + { era: '1950s-60s', label: 'Time-sharing on mainframes' }, + { era: '1970s-80s', label: 'Virtual machines & VPNs emerge' }, + { era: 'Early 2000s', label: 'Amazon & Google offer public cloud' }, + { era: '2005-2011', label: 'SLAs, OpenStack, first-gen cloud' }, + { era: '2012+', label: 'Containers, streaming, serverless' }, + ].map((m, i) => ( +
+ + {m.era} + +
+ {m.label} +
+ ))} +
+
+
+ + {/* Netflix case study */} +
+

+ 🎬 Case Study: Netflix +

+
+
+
245
+
Daily Deployments
+
+
+
99.5%
+
Deploy Success Rate
+
+
+
71%
+
Fewer Incidents
+
+
+

+ Netflix uses Chaos Monkey (intentionally injecting failures) and Spinnaker (automated + deployments) to achieve industry-leading deployment reliability. +

+
+ + + ); + + const sidebar = ( +
+ +

+ + Explore Sections +

+
+ } + onClick={() => navigateToSection('CI/CD Pipeline')} + /> + } + onClick={() => navigateToSection('Cloud Service Models')} + /> + } + onClick={() => navigateToSection('Cloud Architecture')} + /> + } + onClick={() => navigateToSection('Container Orchestration')} + /> + } + onClick={() => navigateToSection('Infrastructure as Code')} + /> + } + onClick={() => navigateToSection('Modern Dev Roles')} + /> + } + onClick={() => navigateToSection('Observability')} + /> +
+ + + {/* Key Stats */} + +

+ 📊 Industry Impact +

+
+
+
300%
+
+ Increase in deployment frequency with DevOps +
+
+
+
80%
+
Reduction in change lead time
+
+
+
99%
+
Teams confidence in production deploys
+
+
+ +
+ ); + + return ( + <> + + navigateToSection('CI/CD Pipeline')} + colorScheme="sky" + /> + + ); +}; + +export default Introduction; diff --git a/src/features/devops/components/sections/ModernDevRoles.tsx b/src/features/devops/components/sections/ModernDevRoles.tsx new file mode 100644 index 0000000..573a178 --- /dev/null +++ b/src/features/devops/components/sections/ModernDevRoles.tsx @@ -0,0 +1,350 @@ +import React from 'react'; +import ThemeCard from '../../../../components/shared/ThemeCard'; +import { Users, Lightbulb, Code, Server, GitBranch, Cloud, Shield, Zap } from 'lucide-react'; + +const ModernDevRoles: React.FC = () => { + return ( +
+ {/* Header */} +
+
+
+ +
+
+

Modern DevOps Roles

+

How Cloud Computing Transformed Developer Roles

+
+
+

+ Cloud computing and DevOps didn't just change technology — they transformed how + development teams are structured. Gone are the rigid silos of "developers write code, + ops runs servers." Today, engineers wear multiple hats and embrace shared + responsibility. +

+
+ + {/* Role Cards */} +
+ {/* Frontend Cloud Developer */} + +
+
+ +
+
+

Frontend Cloud Developer

+

+ Modern frontend developers do far more than write HTML/CSS/JS. They configure CDNs, + set up edge functions, manage CI/CD pipelines for their SPAs, and optimize for + global performance through edge computing. +

+
+
+

Cloud Skills

+
    +
  • • Vercel / Netlify deployment
    • +
  • • CDN configuration (CloudFront)
    • +
  • • Edge functions / Workers
    • +
  • • JAMstack architecture
    • +
+
+
+

DevOps Skills

+
    +
  • • GitHub Actions CI/CD
    • +
  • • Lighthouse CI for performance
    • +
  • • Feature flags (LaunchDarkly)
    • +
  • • Error monitoring (Sentry)
    • +
+
+
+

Key Frameworks

+
    +
  • • Next.js, Nuxt, Remix
    • +
  • • React, Vue, Svelte
    • +
  • • Tailwind CSS, CSS-in-JS
    • +
  • • GraphQL, tRPC
    • +
+
+
+
+
+ + + {/* Backend Serverless Developer */} + +
+
+ +
+
+

+ Backend Serverless Developer +

+

+ Backend developers increasingly work in serverless environments — writing functions + that respond to events instead of managing long-running servers. They think in terms + of event-driven architectures and managed services. +

+
+
+

Core Technologies

+
    +
  • • AWS Lambda / Azure Functions
    • +
  • • API Gateway (REST/GraphQL)
    • +
  • • DynamoDB / Cosmos DB
    • +
  • • SQS / EventBridge / SNS
    • +
+
+
+

+ Architecture Patterns +

+
    +
  • • Event-driven architecture
    • +
  • • CQRS & Event Sourcing
    • +
  • • Saga pattern for transactions
    • +
  • • Fan-out / fan-in processing
    • +
+
+
+

Observability

+
    +
  • • Distributed tracing (X-Ray)
    • +
  • • Structured logging
    • +
  • • Custom CloudWatch metrics
    • +
  • • Cold start optimization
    • +
+
+
+
+
+ + + {/* DevOps / Platform Engineer */} + +
+
+ +
+
+

DevOps / Platform Engineer

+

+ Platform engineers build the "golden paths" — internal developer + platforms, CI/CD pipelines, infrastructure templates, and self-service tools that + make other developers 10x faster. They're the backbone of engineering + organizations. +

+
+
+

Infrastructure

+
    +
  • • Terraform / Pulumi IaC
    • +
  • • Kubernetes administration
    • +
  • • Service mesh (Istio, Linkerd)
    • +
  • • Multi-cloud strategy
    • +
+
+
+

Platform Building

+
    +
  • • Internal Developer Portals
    • +
  • • Backstage / Port
    • +
  • • Self-service templates
    • +
  • • Golden paths for teams
    • +
+
+
+

Reliability

+
    +
  • • SLOs / SLIs / Error budgets
    • +
  • • Incident management
    • +
  • • Chaos engineering
    • +
  • • On-call rotations
    • +
+
+
+
+
+ + + {/* SRE */} + +
+
+ +
+
+

+ Site Reliability Engineer (SRE) +

+

+ SREs treat operations as a software engineering problem. Originally coined by + Google, SREs use error budgets to balance reliability with feature velocity — if + your error budget is spent, you stop shipping and focus on reliability. +

+
+

The SRE Pillars:

+
+
+ + SLOs — Service Level Objectives (target uptime) + + + SLIs — Service Level Indicators (measured metrics) + +
+
+ + Error Budget — Allowed failure quota per period + + + Toil Reduction — Automate repetitive operational tasks + +
+
+
+
+
+ +
+ + {/* DevSecOps */} + +

+ DevSecOps — Security Everywhere +

+

+ DevSecOps integrates security into every phase of the DevOps lifecycle — from coding to + deployment. Security is no longer a gate at the end; it's baked into every step. +

+
+ {[ + { + phase: 'Code', + tools: 'SAST (Semgrep, SonarQube)', + action: 'Static analysis on every PR', + }, + { + phase: 'Build', + tools: 'SCA (Snyk, Dependabot)', + action: 'Dependency vulnerability scanning', + }, + { + phase: 'Test', + tools: 'DAST (OWASP ZAP)', + action: 'Dynamic application security testing', + }, + { + phase: 'Deploy', + tools: 'Image Scan (Trivy)', + action: 'Container image vulnerability scan', + }, + ].map((item, i) => ( +
+

{item.phase}

+

{item.tools}

+

{item.action}

+
+ ))} +
+ + + {/* Career Path */} + +

+ Career Path Progression +

+
+
+

Individual Contributor Track

+ {[ + { + level: 'Junior', + title: 'Junior DevOps Engineer', + desc: 'Learn CI/CD, basic IaC, monitoring', + }, + { + level: 'Mid', + title: 'DevOps Engineer', + desc: 'Own pipelines, K8s, infrastructure', + }, + { + level: 'Senior', + title: 'Senior DevOps / SRE', + desc: 'Architecture, reliability, mentoring', + }, + { + level: 'Staff', + title: 'Staff Platform Engineer', + desc: 'Org-wide platform strategy', + }, + { + level: 'Principal', + title: 'Principal Engineer', + desc: 'Industry thought leader, technical vision', + }, + ].map((item, i) => ( +
+
+ {item.level} +
+
+ {item.title} + {item.desc} +
+
+ ))} +
+
+

Certifications to Consider

+ {[ + { cert: 'AWS Solutions Architect', provider: 'Amazon', level: '⭐⭐⭐' }, + { cert: 'CKA (Kubernetes Admin)', provider: 'CNCF', level: '⭐⭐⭐' }, + { cert: 'HashiCorp Terraform Assoc.', provider: 'HashiCorp', level: '⭐⭐' }, + { cert: 'Azure DevOps Engineer', provider: 'Microsoft', level: '⭐⭐⭐' }, + { cert: 'Google Cloud Professional', provider: 'Google', level: '⭐⭐⭐' }, + ].map((item, i) => ( +
+ +
+ {item.cert} + {item.provider} +
+ {item.level} +
+ ))} +
+
+ + + {/* ELI10 */} +
+
+
+ +
+
+

+ Think of it like a school play 🎭 +

+

+ The Frontend Developer is the actor on stage — what the audience + sees. The Backend Developer writes the script and manages the story + behind the scenes. The DevOps Engineer is the stage manager — making + sure lights work, curtains open on time, and the show goes on even if something + breaks. The SRE is the safety inspector — making sure the stage + won't collapse and the audience is safe! +

+
+
+
+
+ ); +}; + +export default ModernDevRoles; diff --git a/src/features/devops/components/sections/Observability.tsx b/src/features/devops/components/sections/Observability.tsx new file mode 100644 index 0000000..629b267 --- /dev/null +++ b/src/features/devops/components/sections/Observability.tsx @@ -0,0 +1,400 @@ +import React, { useState } from 'react'; +import ThemeCard from '../../../../components/shared/ThemeCard'; +import { + Activity, + Lightbulb, + Eye, + BarChart3, + Bell, + Search, + LineChart, + AlertTriangle, +} from 'lucide-react'; + +const pillars = [ + { + title: 'Metrics', + icon: BarChart3, + color: 'sky', + description: + 'Numeric measurements collected over time — CPU usage, request latency, error rates, memory consumption.', + tools: ['Prometheus', 'Grafana', 'Datadog', 'CloudWatch'], + examples: [ + { metric: 'p99 latency', value: '< 200ms', status: 'good' }, + { metric: 'Error rate', value: '< 0.1%', status: 'good' }, + { metric: 'CPU usage', value: '< 70%', status: 'warning' }, + { metric: 'Memory', value: '< 80%', status: 'good' }, + ], + }, + { + title: 'Logs', + icon: Search, + color: 'cyan', + description: + 'Timestamped text records of discrete events — errors, warnings, info messages, audit trails.', + tools: ['ELK Stack', 'Loki + Grafana', 'Splunk', 'CloudWatch Logs'], + examples: [ + { level: 'INFO', msg: 'User login successful', time: '14:23:01' }, + { level: 'WARN', msg: 'DB query slow (2.3s)', time: '14:23:15' }, + { level: 'ERROR', msg: 'Payment gateway timeout', time: '14:23:22' }, + { level: 'INFO', msg: 'Cache hit ratio: 94%', time: '14:23:30' }, + ], + }, + { + title: 'Traces', + icon: LineChart, + color: 'teal', + description: + 'Follow a single request as it travels through multiple services — see where time is spent and where failures occur.', + tools: ['Jaeger', 'Zipkin', 'AWS X-Ray', 'OpenTelemetry'], + spans: [ + { service: 'API Gateway', duration: 5, color: 'sky' }, + { service: 'Auth Service', duration: 12, color: 'cyan' }, + { service: 'Order Service', duration: 45, color: 'teal' }, + { service: 'Payment API', duration: 120, color: 'rose' }, + { service: 'DB Write', duration: 8, color: 'emerald' }, + ], + }, +]; + +const Observability: React.FC = () => { + const [activePillar, setActivePillar] = useState(0); + const pillar = pillars[activePillar]; + + return ( +
+ {/* Header */} +
+
+
+ +
+
+

Observability & Monitoring

+

Metrics, Logs, Traces & the Future of Software

+
+
+

+ Observability is the ability to understand the internal state of your system by examining + its external outputs. In complex distributed systems, you can't debug by reading code + alone — you need Metrics, Logs, and Traces to understand what's happening in + production. +

+
+ + {/* Three Pillars Interactive */} + +

+ The Three Pillars of Observability +

+
+ {pillars.map((p, i) => { + const Icon = p.icon; + return ( + + ); + })} +
+ +
+

{pillar.description}

+ + {/* Metrics View */} + {activePillar === 0 && pillar.examples && 'metric' in pillar.examples[0] && ( +
+ {(pillar.examples as Array<{ metric: string; value: string; status: string }>).map( + (m, i) => ( +
+
+ {m.value} +
+
{m.metric}
+
+
+ ) + )} +
+ )} + + {/* Logs View */} + {activePillar === 1 && pillar.examples && 'level' in pillar.examples[0] && ( +
+ {(pillar.examples as Array<{ level: string; msg: string; time: string }>).map( + (log, i) => ( +
+ {log.time} + + [{log.level.padEnd(5)}] + + {log.msg} +
+ ) + )} +
+ )} + + {/* Traces View */} + {activePillar === 2 && pillar.spans && ( +
+ {pillar.spans.map((span, i) => ( +
+ + {span.service} + +
+
+ {span.duration}ms +
+
+
+ ))} +

+ Total trace duration: {pillar.spans.reduce((sum, s) => sum + s.duration, 0)}ms +

+
+ )} + +
+ {pillar.tools.map((tool, i) => ( + + {tool} + + ))} +
+
+ + + {/* Alerting */} + +

+ Alerting Best Practices +

+

+ Good alerting is critical — too many alerts cause "alert fatigue" (people ignore + them), too few means missing real incidents. +

+
+
+

✅ Do

+
    +
  • • Alert on symptoms, not causes (high latency, not high CPU)
    • +
  • • Use SLO-based alerting (error budget burn rate)
    • +
  • • Include runbook links in every alert
    • +
  • • Page only for customer-impacting issues
    • +
+
+
+

❌ Don't

+
    +
  • • Alert on every metric threshold
    • +
  • • Page for non-urgent issues at 3 AM
    • +
  • • Create alerts without clear ownership
    • +
  • • Ignore alert fatigue (it causes real outages)
    • +
+
+
+ + + {/* Incident Management */} + +

+ Incident Management Lifecycle +

+
+ {[ + { + step: '1', + phase: 'Detect', + desc: 'Alert fires, on-call engineer responds', + emoji: '🔔', + }, + { + step: '2', + phase: 'Triage', + desc: 'Assess severity, assign incident commander', + emoji: '🏥', + }, + { + step: '3', + phase: 'Mitigate', + desc: 'Stop the bleeding — rollback, scale, failover', + emoji: '🛡️', + }, + { step: '4', phase: 'Resolve', desc: 'Fix root cause, verify recovery', emoji: '🔧' }, + { step: '5', phase: 'Learn', desc: 'Blameless postmortem, action items', emoji: '📝' }, + ].map((item, i) => ( +
+ {item.emoji} +

{item.phase}

+

{item.desc}

+
+ ))} +
+ + + {/* Future of Software Delivery */} + +

+ The Future of Software Delivery +

+

+ DevOps continues to evolve. Here are the trends shaping the next decade of software + delivery: +

+
+ {[ + { + trend: 'Platform Engineering', + desc: 'Internal developer platforms replace ad-hoc DevOps tooling with self-service golden paths.', + maturity: 'Growing Rapidly', + }, + { + trend: 'AI-Powered Operations (AIOps)', + desc: 'ML models predict outages, auto-remediate issues, and optimize resource allocation.', + maturity: 'Emerging', + }, + { + trend: 'FinOps', + desc: 'Financial accountability for cloud spend — engineering teams own their cloud costs.', + maturity: 'Established', + }, + { + trend: 'GitOps Everything', + desc: 'Git as the single source of truth for infrastructure, policies, and configuration.', + maturity: 'Mainstream', + }, + { + trend: 'Edge Computing', + desc: 'Push compute to 300+ global edge locations for sub-10ms latency worldwide.', + maturity: 'Growing', + }, + { + trend: 'Green Computing', + desc: 'Carbon-aware scheduling — run batch jobs when the grid uses renewable energy.', + maturity: 'Emerging', + }, + ].map((item, i) => ( +
+
+

{item.trend}

+ + {item.maturity} + +
+

{item.desc}

+
+ ))} +
+ + + {/* DORA Metrics */} + +

+ DORA Metrics — Measuring DevOps Success +

+

+ The DORA (DevOps Research and Assessment) team identified 4 key metrics that predict + software delivery performance: +

+
+ {[ + { + metric: 'Deployment Frequency', + elite: 'Multiple/day', + low: 'Monthly', + desc: 'How often you deploy to production', + }, + { + metric: 'Lead Time', + elite: '< 1 hour', + low: '> 6 months', + desc: 'Time from commit to production', + }, + { + metric: 'Change Failure Rate', + elite: '< 5%', + low: '> 46%', + desc: '% of deployments causing failures', + }, + { + metric: 'MTTR', + elite: '< 1 hour', + low: '> 1 week', + desc: 'Time to restore service after an incident', + }, + ].map((m, i) => ( +
+

{m.metric}

+

{m.desc}

+
+
+ + Elite: {m.elite} +
+
+ + Low: {m.low} +
+
+
+ ))} +
+ + + {/* ELI10 */} +
+
+
+ +
+
+

+ Think of it like a doctor's checkup 🏥 +

+

+ Metrics are your vitals — heart rate, temperature, blood pressure + (the numbers). Logs are your medical history — what happened and + when. Traces are like following a single blood cell through your body + to see where it gets stuck. Together, they help the doctor (you!) figure out if the + patient (your app) is healthy or needs treatment. +

+
+
+
+
+ ); +}; + +export default Observability; diff --git a/src/features/devops/components/visualizations/2d/CICDPipelineViz.tsx b/src/features/devops/components/visualizations/2d/CICDPipelineViz.tsx new file mode 100644 index 0000000..d5cecaf --- /dev/null +++ b/src/features/devops/components/visualizations/2d/CICDPipelineViz.tsx @@ -0,0 +1,254 @@ +import React, { useState, useEffect, useCallback } from 'react'; +import { Play, Pause, RotateCcw } from 'lucide-react'; + +interface PipelineStage { + id: string; + label: string; + icon: string; + duration: string; + status: 'waiting' | 'running' | 'success' | 'failed'; + details: string[]; +} + +const INITIAL_STAGES: PipelineStage[] = [ + { + id: 'source', + label: 'Source', + icon: '📝', + duration: '~0s', + status: 'waiting', + details: ['Git push detected', 'Webhook triggered', 'Branch: main'], + }, + { + id: 'build', + label: 'Build', + icon: '🔨', + duration: '~2min', + status: 'waiting', + details: ['Install dependencies', 'Compile TypeScript', 'Bundle assets'], + }, + { + id: 'test', + label: 'Test', + icon: '🧪', + duration: '~5min', + status: 'waiting', + details: ['Unit tests (312 passed)', 'Integration tests', 'E2E tests (Playwright)'], + }, + { + id: 'security', + label: 'Security Scan', + icon: '🔒', + duration: '~1min', + status: 'waiting', + details: ['SAST analysis', 'Dependency audit', 'Container scan'], + }, + { + id: 'staging', + label: 'Deploy Staging', + icon: '🔄', + duration: '~3min', + status: 'waiting', + details: ['Container build', 'Push to registry', 'Rolling update'], + }, + { + id: 'approval', + label: 'Approval Gate', + icon: '✅', + duration: 'Manual', + status: 'waiting', + details: ['Code review approved', 'QA sign-off', 'Release manager OK'], + }, + { + id: 'production', + label: 'Deploy Prod', + icon: '🚀', + duration: '~2min', + status: 'waiting', + details: ['Blue-green deploy', 'Health checks pass', 'Traffic shifted 100%'], + }, +]; + +const CICDPipelineViz: React.FC = () => { + const [stages, setStages] = useState(INITIAL_STAGES); + const [currentStage, setCurrentStage] = useState(-1); + const [isPlaying, setIsPlaying] = useState(false); + const [logs, setLogs] = useState(['🟡 Pipeline ready. Press Play to start...']); + + useEffect(() => { + if (!isPlaying || currentStage >= stages.length) return; + + const timer = setTimeout(() => { + const nextStage = currentStage + 1; + if (nextStage >= stages.length) { + setIsPlaying(false); + setLogs((prev) => [...prev, '✅ Pipeline completed successfully!']); + return; + } + + setCurrentStage(nextStage); + setStages((prev) => + prev.map((s, i) => ({ + ...s, + status: i < nextStage ? 'success' : i === nextStage ? 'running' : 'waiting', + })) + ); + + const stage = INITIAL_STAGES[nextStage]; + setLogs((prev) => [ + ...prev, + `🔵 [${stage.label}] Starting...`, + ...stage.details.map((d) => ` ├─ ${d}`), + ]); + }, 1200); + + return () => clearTimeout(timer); + }, [isPlaying, currentStage, stages.length]); + + const reset = useCallback(() => { + setStages(INITIAL_STAGES); + setCurrentStage(-1); + setIsPlaying(false); + setLogs(['🟡 Pipeline ready. Press Play to start...']); + }, []); + + const getStatusColor = (status: PipelineStage['status']): string => { + switch (status) { + case 'success': + return 'bg-emerald-500 border-emerald-400'; + case 'running': + return 'bg-sky-500 border-sky-400 animate-pulse'; + case 'failed': + return 'bg-red-500 border-red-400'; + default: + return 'bg-slate-600 border-slate-500'; + } + }; + + const getConnectorColor = (index: number): string => { + if (index >= stages.length - 1) return ''; + const nextStage = stages[index + 1]; + if (stages[index].status === 'success' && nextStage.status !== 'waiting') + return 'bg-emerald-500'; + if (stages[index].status === 'success') return 'bg-emerald-500'; + return 'bg-slate-600'; + }; + + return ( +
+
+
+

CI/CD Pipeline Visualization

+

From code commit to production deployment

+
+ + {/* Pipeline stages - horizontal on desktop, vertical on mobile */} +
+ {stages.map((stage, index) => ( + +
+ {/* Node */} +
+ {stage.status === 'running' ? ( +
⏳
+ ) : stage.status === 'success' ? ( + '✓' + ) : ( + stage.icon + )} +
+ {/* Label */} +
+

{stage.label}

+

{stage.duration}

+
+
+ {/* Connector */} + {index < stages.length - 1 && ( +
+
+
+
+ )} + + ))} +
+ + {/* Mobile vertical view */} +
+ {stages.map((stage, index) => ( +
+
+
+ {stage.status === 'running' + ? '⏳' + : stage.status === 'success' + ? '✓' + : stage.icon} +
+ {index < stages.length - 1 && ( +
+ )} +
+
+

{stage.label}

+

{stage.duration}

+
+
+ ))} +
+ + {/* Log output - terminal style */} +
+
+
+
+
+ pipeline-output +
+ {logs.map((log, i) => ( +
+ {log} +
+ ))} +
+
+ + {/* Controls */} +
+ + +
+
+ ); +}; + +export default React.memo(CICDPipelineViz); diff --git a/src/features/devops/components/visualizations/2d/CloudArchitectureViz.tsx b/src/features/devops/components/visualizations/2d/CloudArchitectureViz.tsx new file mode 100644 index 0000000..c23e5d2 --- /dev/null +++ b/src/features/devops/components/visualizations/2d/CloudArchitectureViz.tsx @@ -0,0 +1,766 @@ +import React, { useState } from 'react'; + +interface ArchPattern { + id: string; + label: string; + icon: string; + color: string; + description: string; + pros: string[]; + cons: string[]; +} + +const PATTERNS: ArchPattern[] = [ + { + id: 'monolith', + label: 'Monolith', + icon: '🏢', + color: '#6b7280', + description: + 'A single deployable unit containing all application logic. Simple to develop and deploy initially.', + pros: ['Simple deployment', 'Easy debugging', 'Low latency (in-process calls)'], + cons: [ + 'Scaling requires duplicating everything', + 'Single point of failure', + 'Hard to adopt new tech', + ], + }, + { + id: 'microservices', + label: 'Microservices', + icon: '🧩', + color: '#3b82f6', + description: 'Application decomposed into small, independent services communicating via APIs.', + pros: ['Independent scaling', 'Team autonomy', 'Technology diversity'], + cons: ['Network complexity', 'Distributed debugging', 'Data consistency challenges'], + }, + { + id: 'serverless', + label: 'Serverless', + icon: '⚡', + color: '#f59e0b', + description: 'Event-driven functions that run on-demand. Provider manages all infrastructure.', + pros: ['Zero idle cost', 'Auto-scaling', 'No server management'], + cons: ['Cold starts', 'Vendor lock-in', 'Execution time limits'], + }, + { + id: 'loadbalanced', + label: 'Load Balanced', + icon: '⚖️', + color: '#10b981', + description: 'Distributes incoming traffic across multiple servers for high availability.', + pros: ['High availability', 'Horizontal scaling', 'No single bottleneck'], + cons: ['Session management', 'Configuration complexity', 'Cost overhead'], + }, +]; + +const CloudArchitectureViz: React.FC = () => { + const [activePattern, setActivePattern] = useState('microservices'); + + const pattern = PATTERNS.find((p) => p.id === activePattern) || PATTERNS[1]; + + return ( +
+
+
+

Cloud Architecture Patterns

+

+ Compare architectural approaches for cloud-native applications +

+
+ + {/* Pattern selector */} +
+ {PATTERNS.map((p) => ( + + ))} +
+ + {/* Architecture diagrams */} +
+ + + + + + + + {activePattern === 'monolith' && ( + + {/* Single large box */} + + + Monolithic Application + + + {/* Internal modules */} + {[ + 'Frontend UI', + 'Business Logic', + 'Data Access', + 'Auth Module', + 'API Layer', + 'Database', + ].map((mod, i) => ( + + + + {mod} + + + ))} + + {/* Users */} + + 👥 + + + Users + + + + {/* Single deploy arrow */} + + 🖥️ + + + Single Server + + + + )} + + {activePattern === 'microservices' && ( + + {/* API Gateway */} + + + API + + + Gateway + + + {/* Users */} + + 👥 + + + + {/* Microservices */} + {[ + { label: 'User\nService', y: 30, color: '#818cf8' }, + { label: 'Payment\nService', y: 110, color: '#60a5fa' }, + { label: 'Inventory\nService', y: 190, color: '#34d399' }, + ].map((svc, i) => ( + + + {svc.label.split('\n').map((line, li) => ( + + {line} + + ))} + {/* Connection from gateway */} + + + {/* Database for each */} + + + DB + + + + ))} + + {/* Message Queue */} + + + Message + + + Queue + + + 📨 + + + {/* Connections to queue */} + + + )} + + {activePattern === 'serverless' && ( + + {/* Event sources */} + {[ + { label: 'HTTP Request', icon: '🌐', y: 30 }, + { label: 'File Upload', icon: '📁', y: 110 }, + { label: 'Scheduled', icon: '⏰', y: 190 }, + ].map((src, i) => ( + + + + {src.icon} + + + {src.label} + + + ))} + + {/* Event Router */} + + + Event + + + Router + + + {/* Connections to router */} + {[57, 137, 217].map((y, i) => ( + + ))} + + {/* Lambda functions */} + {[ + { label: 'fn_auth()', y: 25 }, + { label: 'fn_process()', y: 100 }, + { label: 'fn_notify()', y: 175 }, + ].map((fn, i) => ( + + + + ⚡ + + + {fn.label} + + + + ))} + + {/* Managed services */} + + + Managed Services + + {['Database', 'Storage', 'Auth'].map((svc, i) => ( + + + + {svc} + + + ))} + + {/* Function to services connections */} + + + )} + + {activePattern === 'loadbalanced' && ( + + {/* Users */} + + 👥 + + + Traffic + + + {/* Load Balancer */} + + + ⚖️ + + + Load Balancer + + + + + {/* Server instances */} + {[ + { label: 'Server 1', y: 20, load: '35%' }, + { label: 'Server 2', y: 105, load: '40%' }, + { label: 'Server 3', y: 190, load: '25%' }, + ].map((srv, i) => ( + + + + {srv.label} + + {/* Load bar */} + + + + Load: {srv.load} + + {/* Connection */} + + + ))} + + {/* Database */} + + + Database + + + Replicated + + + {[55, 140, 225].map((y, i) => ( + + ))} + + )} + +
+ + {/* Pattern info cards */} +
+
+

+ ✅ Advantages +

+
    + {pattern.pros.map((pro, i) => ( +
  • + • + {pro} +
    • + ))} +
+
+
+

+ ⚠️ Trade-offs +

+
    + {pattern.cons.map((con, i) => ( +
  • + • + {con} +
    • + ))} +
+
+
+
+
+ ); +}; + +export default React.memo(CloudArchitectureViz); diff --git a/src/features/devops/components/visualizations/2d/CloudServiceModelsViz.tsx b/src/features/devops/components/visualizations/2d/CloudServiceModelsViz.tsx new file mode 100644 index 0000000..0c2d32a --- /dev/null +++ b/src/features/devops/components/visualizations/2d/CloudServiceModelsViz.tsx @@ -0,0 +1,307 @@ +import React, { useState } from 'react'; + +interface ServiceModel { + id: string; + label: string; + fullName: string; + color: string; + bgColor: string; + borderColor: string; + pizzaAnalogy: string; + pizzaIcon: string; + description: string; + layers: { name: string; managed: 'provider' | 'user' }[]; + examples: string[]; +} + +const SERVICE_MODELS: ServiceModel[] = [ + { + id: 'onprem', + label: 'On-Prem', + fullName: 'On-Premises', + color: '#6b7280', + bgColor: 'bg-gray-50', + borderColor: 'border-gray-300', + pizzaAnalogy: + 'Making pizza from scratch at home — you grow tomatoes, milk cows, knead dough, build the oven, and wash dishes.', + pizzaIcon: '🏠', + description: 'You manage everything: hardware, OS, runtime, middleware, and application.', + layers: [ + { name: 'Application', managed: 'user' }, + { name: 'Data', managed: 'user' }, + { name: 'Runtime', managed: 'user' }, + { name: 'Middleware', managed: 'user' }, + { name: 'OS', managed: 'user' }, + { name: 'Virtualization', managed: 'user' }, + { name: 'Servers', managed: 'user' }, + { name: 'Storage', managed: 'user' }, + { name: 'Networking', managed: 'user' }, + ], + examples: ['Private data centers', 'Self-managed servers'], + }, + { + id: 'iaas', + label: 'IaaS', + fullName: 'Infrastructure as a Service', + color: '#3b82f6', + bgColor: 'bg-blue-50', + borderColor: 'border-blue-300', + pizzaAnalogy: + 'Buying a frozen "take & bake" pizza — the store provides ingredients, but you still need your own oven.', + pizzaIcon: '🧊', + description: 'Provider manages infrastructure. You manage OS, runtime, and applications.', + layers: [ + { name: 'Application', managed: 'user' }, + { name: 'Data', managed: 'user' }, + { name: 'Runtime', managed: 'user' }, + { name: 'Middleware', managed: 'user' }, + { name: 'OS', managed: 'user' }, + { name: 'Virtualization', managed: 'provider' }, + { name: 'Servers', managed: 'provider' }, + { name: 'Storage', managed: 'provider' }, + { name: 'Networking', managed: 'provider' }, + ], + examples: ['AWS EC2', 'Google Compute Engine', 'Azure VMs'], + }, + { + id: 'paas', + label: 'PaaS', + fullName: 'Platform as a Service', + color: '#8b5cf6', + bgColor: 'bg-purple-50', + borderColor: 'border-purple-300', + pizzaAnalogy: + 'Ordering pizza delivery — the restaurant handles everything; you just set the table.', + pizzaIcon: '🛵', + description: 'Provider manages infrastructure and platform. You focus only on your code.', + layers: [ + { name: 'Application', managed: 'user' }, + { name: 'Data', managed: 'user' }, + { name: 'Runtime', managed: 'provider' }, + { name: 'Middleware', managed: 'provider' }, + { name: 'OS', managed: 'provider' }, + { name: 'Virtualization', managed: 'provider' }, + { name: 'Servers', managed: 'provider' }, + { name: 'Storage', managed: 'provider' }, + { name: 'Networking', managed: 'provider' }, + ], + examples: ['Heroku', 'Google App Engine', 'Azure App Service'], + }, + { + id: 'saas', + label: 'SaaS', + fullName: 'Software as a Service', + color: '#10b981', + bgColor: 'bg-emerald-50', + borderColor: 'border-emerald-300', + pizzaAnalogy: + 'Dining at a restaurant — just sit down, eat, and leave. Everything is handled for you.', + pizzaIcon: '🍕', + description: 'Provider manages everything. You just use the software via a browser.', + layers: [ + { name: 'Application', managed: 'provider' }, + { name: 'Data', managed: 'provider' }, + { name: 'Runtime', managed: 'provider' }, + { name: 'Middleware', managed: 'provider' }, + { name: 'OS', managed: 'provider' }, + { name: 'Virtualization', managed: 'provider' }, + { name: 'Servers', managed: 'provider' }, + { name: 'Storage', managed: 'provider' }, + { name: 'Networking', managed: 'provider' }, + ], + examples: ['Gmail', 'Slack', 'Salesforce'], + }, + { + id: 'faas', + label: 'FaaS', + fullName: 'Function as a Service', + color: '#f59e0b', + bgColor: 'bg-amber-50', + borderColor: 'border-amber-300', + pizzaAnalogy: + 'A pizza vending machine — just press a button, and a perfect slice appears instantly!', + pizzaIcon: '⚡', + description: + 'Just write functions. Provider handles everything else, scaling to zero when idle.', + layers: [ + { name: 'Function Code', managed: 'user' }, + { name: 'Event Triggers', managed: 'user' }, + { name: 'Runtime', managed: 'provider' }, + { name: 'Middleware', managed: 'provider' }, + { name: 'OS', managed: 'provider' }, + { name: 'Virtualization', managed: 'provider' }, + { name: 'Servers', managed: 'provider' }, + { name: 'Storage', managed: 'provider' }, + { name: 'Networking', managed: 'provider' }, + ], + examples: ['AWS Lambda', 'Cloud Run Functions', 'Azure Functions'], + }, +]; + +const CloudServiceModelsViz: React.FC = () => { + const [selectedModel, setSelectedModel] = useState('paas'); + const [showPizzaView, setShowPizzaView] = useState(false); + + const activeModel = SERVICE_MODELS.find((m) => m.id === selectedModel) || SERVICE_MODELS[2]; + + return ( +
+
+
+

Cloud Service Models

+

+ The shared responsibility spectrum — from full control to fully managed +

+
+ + {/* Toggle Pizza View */} +
+ +
+ + {/* Model selector tabs */} +
+ {SERVICE_MODELS.map((model) => ( + + ))} +
+ + {/* Main content */} +
+ {/* Layer stack visualization */} +
+

+ Responsibility Layers +

+
+ {activeModel.layers.map((layer, index) => ( +
+ {layer.name} + + {layer.managed === 'provider' ? '☁️ Provider' : '👤 You'} + +
+ ))} +
+ + {/* Legend */} +
+
+
+ Cloud Provider manages +
+
+
+ You manage +
+
+
+ + {/* Info panel */} +
+ {/* Model details */} +
+

{activeModel.fullName}

+

{activeModel.description}

+
+ + {/* Pizza analogy */} + {showPizzaView && ( +
+
+ {activeModel.pizzaIcon} +
+

Pizza Analogy

+

+ {activeModel.pizzaAnalogy} +

+
+
+
+ )} + + {/* Examples */} +
+

Real-World Examples

+
+ {activeModel.examples.map((ex, i) => ( + + {ex} + + ))} +
+
+ + {/* Responsibility meter */} +
+

Management Burden

+
+
l.managed === 'user').length / activeModel.layers.length) * 100}%`, + backgroundColor: activeModel.color, + }} + /> +
+
+ Fully Managed + Full Control +
+
+
+
+
+ + {/* CSS for animations */} + +
+ ); +}; + +export default React.memo(CloudServiceModelsViz); diff --git a/src/features/devops/components/visualizations/2d/ContainerOrchestrationViz.tsx b/src/features/devops/components/visualizations/2d/ContainerOrchestrationViz.tsx new file mode 100644 index 0000000..60b7e6b --- /dev/null +++ b/src/features/devops/components/visualizations/2d/ContainerOrchestrationViz.tsx @@ -0,0 +1,302 @@ +import React, { useState, useEffect, useCallback, useRef } from 'react'; +import { Play, Pause, RotateCcw } from 'lucide-react'; + +interface Container { + id: string; + name: string; + status: 'running' | 'creating' | 'terminating' | 'pending'; + cpu: number; + memory: number; + pod: string; +} + +const ContainerOrchestrationViz: React.FC = () => { + const [containers, setContainers] = useState([ + { id: 'c1', name: 'web-app-1', status: 'running', cpu: 45, memory: 62, pod: 'pod-1' }, + { id: 'c2', name: 'web-app-2', status: 'running', cpu: 38, memory: 55, pod: 'pod-1' }, + { id: 'c3', name: 'api-svc-1', status: 'running', cpu: 72, memory: 78, pod: 'pod-2' }, + { id: 'c4', name: 'api-svc-2', status: 'running', cpu: 65, memory: 70, pod: 'pod-2' }, + { id: 'c5', name: 'worker-1', status: 'running', cpu: 28, memory: 40, pod: 'pod-3' }, + ]); + const [isSimulating, setIsSimulating] = useState(false); + const [events, setEvents] = useState([ + '🟢 Cluster healthy - 5 containers running across 3 pods', + ]); + const [scalingDemo, setScalingDemo] = useState(false); + + // Simulate container metric changes + useEffect(() => { + if (!isSimulating) return; + const interval = setInterval(() => { + setContainers((prev) => + prev.map((c) => ({ + ...c, + cpu: Math.min(100, Math.max(5, c.cpu + (Math.random() - 0.5) * 20)), + memory: Math.min(100, Math.max(10, c.memory + (Math.random() - 0.5) * 10)), + })) + ); + }, 2000); + return () => clearInterval(interval); + }, [isSimulating]); + + const scaleUp = useCallback(() => { + const newId = `c${Date.now()}`; + const newContainer: Container = { + id: newId, + name: `web-app-${containers.length + 1}`, + status: 'creating', + cpu: 0, + memory: 0, + pod: `pod-${Math.ceil(containers.length / 2) + 1}`, + }; + setContainers((prev) => [...prev, newContainer]); + setEvents((prev) => [...prev, `📦 Scaling UP: Creating ${newContainer.name}...`]); + + setTimeout(() => { + setContainers((prev) => + prev.map((c) => (c.id === newId ? { ...c, status: 'running', cpu: 15, memory: 25 } : c)) + ); + setEvents((prev) => [...prev, `✅ ${newContainer.name} is now running`]); + }, 1500); + }, [containers.length]); + + const scaleDown = useCallback(() => { + if (containers.length <= 2) return; + const lastContainer = containers[containers.length - 1]; + setContainers((prev) => + prev.map((c) => (c.id === lastContainer.id ? { ...c, status: 'terminating' } : c)) + ); + setEvents((prev) => [...prev, `🔻 Scaling DOWN: Terminating ${lastContainer.name}...`]); + + setTimeout(() => { + setContainers((prev) => prev.filter((c) => c.id !== lastContainer.id)); + setEvents((prev) => [...prev, `🗑️ ${lastContainer.name} terminated`]); + }, 1200); + }, [containers]); + + // Keep refs to avoid restarting the effect when callbacks change + const scaleUpRef = useRef(scaleUp); + scaleUpRef.current = scaleUp; + const scaleDownRef = useRef(scaleDown); + scaleDownRef.current = scaleDown; + + // Auto-scaling demo + useEffect(() => { + if (!scalingDemo) return; + const sequence = [ + () => { + setEvents((p) => [...p, '📈 Traffic spike detected! CPU > 80%']); + }, + () => scaleUpRef.current(), + () => scaleUpRef.current(), + () => { + setEvents((p) => [...p, '📉 Traffic normalizing...']); + }, + () => scaleDownRef.current(), + () => scaleDownRef.current(), + () => { + setScalingDemo(false); + setEvents((p) => [...p, '✅ Auto-scaling complete']); + }, + ]; + + let i = 0; + const interval = setInterval(() => { + if (i < sequence.length) { + sequence[i](); + i++; + } else { + clearInterval(interval); + } + }, 2000); + + return () => clearInterval(interval); + }, [scalingDemo]); + + const reset = useCallback(() => { + setContainers([ + { id: 'c1', name: 'web-app-1', status: 'running', cpu: 45, memory: 62, pod: 'pod-1' }, + { id: 'c2', name: 'web-app-2', status: 'running', cpu: 38, memory: 55, pod: 'pod-1' }, + { id: 'c3', name: 'api-svc-1', status: 'running', cpu: 72, memory: 78, pod: 'pod-2' }, + { id: 'c4', name: 'api-svc-2', status: 'running', cpu: 65, memory: 70, pod: 'pod-2' }, + { id: 'c5', name: 'worker-1', status: 'running', cpu: 28, memory: 40, pod: 'pod-3' }, + ]); + setEvents(['🟢 Cluster healthy - 5 containers running across 3 pods']); + setIsSimulating(false); + setScalingDemo(false); + }, []); + + const getStatusColor = (status: Container['status']): string => { + switch (status) { + case 'running': + return 'bg-emerald-400 border-emerald-500'; + case 'creating': + return 'bg-sky-400 border-sky-500 animate-pulse'; + case 'terminating': + return 'bg-red-400 border-red-500 animate-pulse'; + case 'pending': + return 'bg-amber-400 border-amber-500'; + } + }; + + const getCpuBarColor = (cpu: number): string => { + if (cpu > 80) return 'bg-red-500'; + if (cpu > 60) return 'bg-amber-500'; + return 'bg-emerald-500'; + }; + + // Group containers by pod + const pods = containers.reduce>((acc, c) => { + if (!acc[c.pod]) acc[c.pod] = []; + acc[c.pod].push(c); + return acc; + }, {}); + + return ( +
+
+
+

Container Orchestration

+

Kubernetes-style pod management and auto-scaling

+
+ + {/* Cluster overview */} +
+
+
{containers.length}
+
Containers
+
+
+
{Object.keys(pods).length}
+
Pods
+
+
+
+ {Math.round(containers.reduce((s, c) => s + c.cpu, 0) / containers.length)}% +
+
Avg CPU
+
+
+ + {/* Pod visualization */} +
+ {Object.entries(pods).map(([podName, podContainers]) => ( +
+
+
+ {podName} + + {podContainers.length} container{podContainers.length > 1 ? 's' : ''} + +
+
+ {podContainers.map((container) => ( +
+
+
+ {container.name} +
+ {/* CPU bar */} +
+ CPU +
+
+
+ + {Math.round(container.cpu)}% + +
+ {/* Memory bar */} +
+ MEM +
+
+
+ + {Math.round(container.memory)}% + +
+
+ ))} +
+
+ ))} +
+ + {/* Event log */} +
+
+
+
+
+ kubectl events +
+ {events.slice(-8).map((evt, i) => ( +
+ {evt} +
+ ))} +
+
+ + {/* Controls */} +
+ + + + + +
+
+ ); +}; + +export default React.memo(ContainerOrchestrationViz); diff --git a/src/features/devops/components/visualizations/2d/DevOpsInfiniteLoop.tsx b/src/features/devops/components/visualizations/2d/DevOpsInfiniteLoop.tsx new file mode 100644 index 0000000..8fbd2f4 --- /dev/null +++ b/src/features/devops/components/visualizations/2d/DevOpsInfiniteLoop.tsx @@ -0,0 +1,399 @@ +import React, { useState, useEffect, useCallback } from 'react'; +import { Play, Pause, RotateCcw } from 'lucide-react'; + +const STAGES = [ + { + id: 'plan', + label: 'Plan', + icon: '📋', + color: '#6366f1', + desc: 'Define requirements & sprint goals', + }, + { + id: 'code', + label: 'Code', + icon: '💻', + color: '#818cf8', + desc: 'Write & review application code', + }, + { + id: 'build', + label: 'Build', + icon: '🔨', + color: '#3b82f6', + desc: 'Compile, bundle & create artifacts', + }, + { id: 'test', label: 'Test', icon: '🧪', color: '#2563eb', desc: 'Run automated test suites' }, + { + id: 'release', + label: 'Release', + icon: '📦', + color: '#10b981', + desc: 'Tag & version for deployment', + }, + { + id: 'deploy', + label: 'Deploy', + icon: '🚀', + color: '#059669', + desc: 'Push to production servers', + }, + { + id: 'operate', + label: 'Operate', + icon: '⚙️', + color: '#14b8a6', + desc: 'Run & maintain live systems', + }, + { + id: 'monitor', + label: 'Monitor', + icon: '📊', + color: '#0ea5e9', + desc: 'Observe metrics & alerting', + }, +]; + +const DevOpsInfiniteLoop: React.FC = () => { + const [activeStage, setActiveStage] = useState(0); + const [isPlaying, setIsPlaying] = useState(false); + const [hoveredStage, setHoveredStage] = useState(null); + + useEffect(() => { + if (!isPlaying) return; + const interval = setInterval(() => { + setActiveStage((prev) => (prev + 1) % STAGES.length); + }, 1500); + return () => clearInterval(interval); + }, [isPlaying]); + + const reset = useCallback(() => { + setActiveStage(0); + setIsPlaying(false); + }, []); + + // Generate infinity-path coordinates for 8 stages + const cx = 400; + const cy = 200; + const rx = 160; + const ry = 100; + + const getPosition = (index: number): { x: number; y: number } => { + // Map stages around an infinity / figure-8 shape + const t = (index / STAGES.length) * 2 * Math.PI; + const denom = 1 + Math.sin(t) * Math.sin(t); + const x = cx + (rx * Math.cos(t)) / denom; + const y = cy + (ry * Math.sin(t) * Math.cos(t)) / denom; + return { x, y }; + }; + + // Draw infinity path + const pathPoints: string[] = []; + for (let i = 0; i <= 200; i++) { + const t = (i / 200) * 2 * Math.PI; + const denom = 1 + Math.sin(t) * Math.sin(t); + const x = cx + (rx * Math.cos(t)) / denom; + const y = cy + (ry * Math.sin(t) * Math.cos(t)) / denom; + pathPoints.push(`${i === 0 ? 'M' : 'L'}${x},${y}`); + } + pathPoints.push('Z'); + const infinityPath = pathPoints.join(' '); + + const displayStage = hoveredStage !== null ? hoveredStage : activeStage; + + return ( +
+
+ {/* Animated background dots */} +
+ {Array.from({ length: 30 }).map((_, i) => ( +
+ ))} +
+ +
+ {/* Title */} +
+

DevOps Infinite Loop

+

Continuous Integration & Continuous Delivery

+
+ + {/* SVG Visualization */} + + + {/* Glow filter */} + + + + + {/* Pulse animation filter */} + + + + + + + + + + + + + + + + + {/* Side labels */} + + DEVELOPMENT + + + OPERATIONS + + + {/* Infinity path outline */} + + + {/* Animated moving dot along path */} + + + + + + + + {/* Connection lines between nodes */} + {STAGES.map((_, index) => { + const from = getPosition(index); + const to = getPosition((index + 1) % STAGES.length); + const isActive = index === displayStage; + return ( + + ); + })} + + {/* Stage nodes */} + {STAGES.map((stage, index) => { + const pos = getPosition(index); + const isActive = index === displayStage; + const nodeRadius = isActive ? 36 : 30; + + return ( + { + setActiveStage(index); + setIsPlaying(false); + }} + onMouseEnter={() => setHoveredStage(index)} + onMouseLeave={() => setHoveredStage(null)} + role="button" + aria-label={`${stage.label}: ${stage.desc}`} + tabIndex={0} + onKeyDown={(e) => { + if (e.key === 'Enter') { + setActiveStage(index); + setIsPlaying(false); + } + }} + > + {/* Active glow ring */} + {isActive && ( + + + + + )} + + {/* Node circle */} + + + {/* Emoji icon */} + + {stage.icon} + + + {/* Label */} + + {stage.label} + + + ); + })} + + {/* Center hub */} + + + CI/CD + + + Pipeline + + + + {/* Active stage detail card */} +
+
+ {STAGES[displayStage].icon} +
+

{STAGES[displayStage].label}

+

{STAGES[displayStage].desc}

+
+
+ Step {displayStage + 1}/8 +
+
+
+
+
+ + {/* Controls */} +
+ + + +
+
+ ); +}; + +export default React.memo(DevOpsInfiniteLoop); diff --git a/src/features/devops/components/visualizations/2d/InfrastructureAsCodeViz.tsx b/src/features/devops/components/visualizations/2d/InfrastructureAsCodeViz.tsx new file mode 100644 index 0000000..d068fc1 --- /dev/null +++ b/src/features/devops/components/visualizations/2d/InfrastructureAsCodeViz.tsx @@ -0,0 +1,270 @@ +import React, { useState } from 'react'; + +interface IaCTool { + id: string; + name: string; + icon: string; + type: 'provisioning' | 'configuration' | 'containerization'; + description: string; + codeExample: string; + language: string; +} + +const IAC_TOOLS: IaCTool[] = [ + { + id: 'terraform', + name: 'Terraform', + icon: '🏗️', + type: 'provisioning', + description: 'Declarative infrastructure provisioning across cloud providers', + language: 'HCL', + codeExample: `resource "aws_instance" "web" { + ami = "ami-0c55b159cbfafe1f0" + instance_type = "t3.micro" + + tags = { + Name = "web-server" + Environment = "production" + } +} + +resource "aws_lb" "main" { + name = "app-lb" + load_balancer_type = "application" + subnets = var.public_subnets +}`, + }, + { + id: 'ansible', + name: 'Ansible', + icon: '⚙️', + type: 'configuration', + description: 'Agentless configuration management and automation', + language: 'YAML', + codeExample: `- name: Configure Web Server + hosts: webservers + become: yes + tasks: + - name: Install Nginx + apt: + name: nginx + state: present + + - name: Start Nginx + service: + name: nginx + state: started + enabled: yes + + - name: Deploy Application + copy: + src: ./dist/ + dest: /var/www/html/`, + }, + { + id: 'docker', + name: 'Dockerfile', + icon: '🐳', + type: 'containerization', + description: 'Container image definition for reproducible environments', + language: 'Dockerfile', + codeExample: `FROM node:20-alpine AS builder +WORKDIR /app +COPY package*.json ./ +RUN npm ci --only=production + +FROM node:20-alpine +WORKDIR /app +COPY --from=builder /app/node_modules ./node_modules +COPY . . + +EXPOSE 3000 +HEALTHCHECK CMD curl -f http://localhost:3000/health +CMD ["node", "server.js"]`, + }, +]; + +const InfrastructureAsCodeViz: React.FC = () => { + const [activeTool, setActiveTool] = useState('terraform'); + const [showDriftDemo, setShowDriftDemo] = useState(false); + + const tool = IAC_TOOLS.find((t) => t.id === activeTool) || IAC_TOOLS[0]; + + return ( +
+
+
+

Infrastructure as Code

+

Define, version, and automate your infrastructure

+
+ + {/* IaC workflow diagram */} +
+ + {[ + { x: 60, icon: '📝', label: 'Write Code', color: '#6366f1' }, + { x: 220, icon: '📋', label: 'Plan', color: '#818cf8' }, + { x: 380, icon: '✅', label: 'Review', color: '#3b82f6' }, + { x: 540, icon: '🚀', label: 'Apply', color: '#10b981' }, + { x: 700, icon: '🔍', label: 'Verify', color: '#0ea5e9' }, + ].map((step, i, arr) => ( + + + + {step.icon} + + + {step.label} + + {i < arr.length - 1 && ( + + )} + + ))} + + + + + + +
+ + {/* Tool selector */} +
+ {IAC_TOOLS.map((t) => ( + + ))} +
+ + {/* Code preview */} +
+ {/* Code editor mockup */} +
+
+
+
+
+ + {tool.name.toLowerCase()}. + {tool.language === 'HCL' + ? 'tf' + : tool.language === 'YAML' + ? 'yml' + : tool.language.toLowerCase()} + +
+ 
+              {tool.codeExample}
+
+
+ + {/* Info panel */} +
+
+
+ {tool.icon} +
+

{tool.name}

+ + {tool.type} + +
+
+

{tool.description}

+
+ + {/* Drift detection demo */} +
+

+ 🔄 Configuration Drift +

+

+ {showDriftDemo + ? 'Drift detected! Someone manually changed a server setting. IaC tools detect this and can auto-remediate.' + : 'Infrastructure can "drift" from its defined state when manual changes are made.'} +

+ +
+ + {/* Key benefit */} +
+

🎯 Why IaC?

+
    +
  • + ✓ Version controlled like application code +
    • +
  • + ✓ Reproducible environments every time +
    • +
  • + ✓ Automated provisioning in minutes, not + days +
    • +
  • + ✓ Peer-reviewed infrastructure changes +
    • +
+
+
+
+
+
+ ); +}; + +export default React.memo(InfrastructureAsCodeViz); diff --git a/src/features/devops/index.ts b/src/features/devops/index.ts new file mode 100644 index 0000000..58c2f19 --- /dev/null +++ b/src/features/devops/index.ts @@ -0,0 +1,17 @@ +/** + * DevOps & Cloud Computing Feature Module + * Entry point for the DevOps & Cloud Computing learning module + * + * Covers DevOps and Cloud Computing concepts including: + * - DevOps History, Culture, and the Infinite Loop + * - CI/CD Pipelines and Automation + * - Cloud Service Models (IaaS, PaaS, SaaS, CaaS, FaaS) + * - Cloud Architecture Patterns (Microservices, Serverless, Load Balancing) + * - Infrastructure as Code (Terraform, Ansible) + * - Containerization and Orchestration (Docker, Kubernetes) + * - Modern Developer Roles (Frontend Cloud, Backend Serverless, DevOps Engineer) + * - Observability, Monitoring, and the Future of Software Delivery + */ + +export { default } from './DevOpsPage'; +export { default as DevOpsPage } from './DevOpsPage'; diff --git a/src/pages/Home.tsx b/src/pages/Home.tsx index 4fa4ee9..058d7af 100644 --- a/src/pages/Home.tsx +++ b/src/pages/Home.tsx @@ -26,6 +26,7 @@ import { Cpu, Network, Server, + Cloud, } from 'lucide-react'; import ThemeCard from '../components/shared/ThemeCard'; import { SEO } from '../shared/components/SEO/SEO'; @@ -185,11 +186,24 @@ const Home: React.FC = () => { level: 'Deep Dive', duration: '3-4 hours', }, + { + icon: , + title: 'DevOps & Cloud', + description: + 'CI/CD pipelines, cloud service models, container orchestration, Infrastructure as Code, and observability', + path: '/devops', + color: 'sky', + gradient: 'from-sky-600 to-cyan-600', + bgGradient: 'from-sky-50 to-cyan-50', + topics: ['CI/CD Pipeline', 'Cloud Models', 'Kubernetes', 'Infrastructure as Code'], + level: 'Intermediate', + duration: '3-4 hours', + }, ]; const stats = [ - { value: '12+', label: 'Interactive Modules', icon: }, - { value: '78+', label: 'Visualizations', icon: }, + { value: '13+', label: 'Interactive Modules', icon: }, + { value: '84+', label: 'Visualizations', icon: }, { value: '1000+', label: 'Code Examples', icon: }, { value: '24/7', label: 'Available Learning', icon: }, ]; @@ -218,11 +232,18 @@ const Home: React.FC = () => { }, { phase: 'Architecture & Systems', - modules: [allModules[7], allModules[8], allModules[9], allModules[10], allModules[11]], // Python, System Design, TypeScript, AI, Node.js + modules: [ + allModules[7], + allModules[8], + allModules[9], + allModules[10], + allModules[11], + allModules[12], + ], // Python, System Design, TypeScript, AI, Node.js, DevOps icon: , color: 'emerald', description: - 'Master system design patterns, multi-language architectures, AI fundamentals, and runtime ecosystems', + 'Master system design patterns, multi-language architectures, AI fundamentals, runtime ecosystems, and DevOps practices', }, ]; @@ -423,7 +444,7 @@ const Home: React.FC = () => { }} className="inline-flex items-center space-x-2 text-indigo-600 font-semibold hover:text-indigo-700 transition-colors" > - View All 12 Modules + View All 13 Modules
diff --git a/src/utils/theme.ts b/src/utils/theme.ts index 6e22655..b2bb478 100644 --- a/src/utils/theme.ts +++ b/src/utils/theme.ts @@ -100,6 +100,14 @@ export const theme = { border: 'green-100', shadow: 'green-200', }, + devops: { + primary: 'sky', + secondary: 'cyan', + accent: 'teal', + gradient: 'from-sky-50 via-white to-cyan-50', + border: 'sky-100', + shadow: 'sky-200', + }, playground: { primary: 'blue', secondary: 'indigo',