Featured Issues

Tired of TicketOps? Here’s how to break free. CloudPro #109: How MCP Turns Your IDP into an Actual Teammate Your runbooks live in wikis. Your SLOs live in monitoring dashboards. Your approval workflows live in ticketing systems. And you, the developer who actually needs to ship things, you're stuck stitching all of this together manually, one step at a time. This is where most cloud teams still operate. And it's exhausting. I realized this after our AI-Powered Platform Engineering workshop last week. If you were there, you know it was packed. We had George Hantzaras (Director of Engineering, MongoDB) and Ajay Chankramath (Founder, Platformetrics)up there walking through how AI, golden paths, and internal developer platforms are completely reshaping the way modern teams ship software. The energy in the session was incredible. And the conversations didn’t stop when the session ended. But here’s the thing that stuck with me the most: MCP (Model Context Protocol) turns your platform into something an AI can actually do things with, not just talk about. This is the difference between TicketOps and brittle runbooks versus workflows like provisioning, rolling back, and scaling that become assistant-triggered actions with guardrails and full visibility into what’s happening. Your AI goes from being a really smart search engine to being an actual teammate. That’s the jump I think a lot of us have been waiting for. So in this issue, I’m going to dig into what that actually looks like, and give you a practical starter pack you can adapt to your own stack. Because if you’ve been wondering how to move from AI as “a chat window” to AI as “a teammate who actually does the work,” this is a good place to start. Cheers, Shreyans Singh Editor-in-Chief Bookmark This Article for Later Join Snyk on October 22, 2025 at DevSecCon25 - Securing the Shift to AI Native Save Your Spot The Problem We’re All Facing Let me paint a picture of how most cloud teams still operate today. You write a ticket. You wait for approvals. You hunt through runbooks to find the right commands to copy-paste. You watch CI/CD spin up. You cross your fingers that the safety nets catch anything that could go wrong. Documentation and internal portals help you find things, sure. But they rarely do things. That gap, between knowing what to do and actually doing it, creates this constant context switching, slow feedback loops, and inconsistent safety guardrails. The result is messy. Really messy. Brittle handoffs. Workflows duplicated across teams. And what should be “golden paths” that empower teams end up becoming “golden cages” that block velocity instead of enabling it. Here’s what I think is the real core issue: we’ve separated knowledge from action. Your runbooks live in wikis. Your SLOs live in monitoring dashboards. Your approval workflows live in ticketing systems. And your developers, the people who actually need to ship things, they’re stuck stitching all of this together manually, one step at a time. This friction doesn’t just slow shipping down. It creates inconsistency. One team deploys with proper approvals; another skips them. One team checks SLO impact before scaling; another scales blind. You end up with fragmented practices across your org, and nobody likes that. We need a different model. Instead of “read the docs, then run the steps,” we should be asking our systems: “propose a plan, then execute it with guardrails.” Here’s What Changed: The solution rests on two foundational ideas working together, and honestly, the way they complement each other is elegant. First: golden paths. These reduce decision fatigue without sacrificing flexibility. Think of a golden path as an end-to-end workflow with sensible defaults, something like: stateless service → preview environment → automated checks → production. These paths capture your team’s collective knowledge about how to do things safely. But they’re not straightjackets. You build in escape hatches for the 20% of cases that don’t fit the mold. Golden paths let you standardize without fossilizing your processes, and they’re the antidote to “TicketOps.” Second: the Model Context Protocol (MCP). This is the glue that makes it all work. MCP is a standard that exposes your golden paths as tools that an AI assistant can actually call. Think of it as an adapter layer between your assistant and your platform. The assistant can observe your systems: what services exist, what their SLOs are, what incidents are open right now. It can propose a plan (“I’ll deploy this to preview, run tests, then promote to prod”). And it can execute approved actions while logging everything for audit and observability. MCP turns your platform into a set of composable, auditable operations. Here’s what this looks like in the real world. An engineer types: “Spin up a preview environment and load our staging data.” The assistant gathers context. What’s the service’s dependency tree? What are the current SLO baselines? Who owns this service? What recent incidents or postmortems should I know about? It drafts a plan that respects your runbooks and standards. It shows you the diffs and policy checks that apply. Then it either executes immediately (low-risk actions) or routes to the right approver (medium/high-risk actions). Everything gets logged. This isn’t theoretical anymore. It works. Bookmark This Article for Later How You Actually Build This The architecture starts simple: pick one golden path. One high-value workflow, like service deployment, that you want to standardize. Next, you build MCP servers that act as adapters to your existing systems. Your runtime layer exposes Kubernetes operations (deploy, scale, health checks) and feature flags as callable tools. Your delivery layer connects to Git, GitHub Actions, or GitLab CI to handle builds, promotions, and canary deployments. Your reliability layer taps into SLO systems, alerting platforms, and observability tools so the assistant can query metrics, create SLOs, and mute alerts with proper context. Your change control layer enforces approvals and integrates with compliance workflows. Underneath all of this runs retrieval-augmented generation (RAG). Before the assistant proposes any action, it indexes and searches your runbooks, compliance standards, postmortems, and architectural guidelines. The plan that comes back doesn’t just say “deploy the service”, it references your procedures. “Deploy using our standard blue-green pattern [link to runbook]. SLO impact: +2% latency at p99 (within budget). Dependencies: notify the data team [link to postmortem]. Policy check: OK, proceed.” Safety gets enforced as policy-as-code, not friction. You define risk tiers: low-risk actions (like querying logs) auto-execute. Medium-risk actions (like scaling a service) require human approval. High-risk actions (like deleting a database) are blocked unless routed through a formal approval path. Standards violations get auto-fixed when confidence is high, or escalated when not. Everything is logged. The user experience ties it all together. An engineer uses chat or a slash command to describe what they need. The assistant gathers context from your systems and knowledge base, drafts a plan with full diffs and impact estimates, shows what policy checks apply, and executes: staying in the loop for decisions that matter (approvals, tradeoffs) but handling the rote work. Everything that happened gets logged: the initial request, the plan, who approved it, what actually ran, what the outcome was. The Real Payoff Over time, this architecture unifies your platform. Your internal developer platform (IDP) becomes more than a portal where people click and read documentation. It becomes an actor that moves with your engineers, understanding context, respecting guardrails, and turning workflows into outcomes. You measure it differently too. Not by pageviews to your portal, but by lead time to production. By mean time to recovery when things break. By consistency of safety across teams. You tie actions to business impact: AI-assisted scaling and predictive capacity planning can deliver up to 25% cost optimization while keeping SLOs intact. The shift from ticket-based workflows to action-based workflows with AI assistance and policy-driven safety doesn’t happen overnight. Start with one golden path. Build the MCP adapters for one system at a time. Add guardrails incrementally. But the direction is clear. Push intelligence and safety down into your platform so that doing the right thing becomes the easy thing. And the hard work, decision-making, tradeoff analysis, exception handling, stays where it belongs: with your engineers. That’s where we’re headed. And honestly? I think it’s going to change how we all work. 📢 If your company is interested in reaching an audience of developers and, technical professionals, and decision makers, you may want toadvertise with us. If you have any comments or feedback, just reply back to this email. Thanks for reading and have a great day! *{box-sizing:border-box}body{margin:0;padding:0}a[x-apple-data-detectors]{color:inherit!important;text-decoration:inherit!important}#MessageViewBody a{color:inherit;text-decoration:none}p{line-height:inherit}.desktop_hide,.desktop_hide table{mso-hide:all;display:none;max-height:0;overflow:hidden}.image_block img+div{display:none}sub,sup{font-size:75%;line-height:0} @media (max-width: 100%;display:block}.mobile_hide{min-height:0;max-height:0;max-width: 100%;overflow:hidden;font-size:0}.desktop_hide,.desktop_hide table{display:table!important;max-height:none!important}}

Real-world insights for sharper web dev decisions Advertise with Us|Sign Up to the Newsletter @media only screen and (max-width: 100%;} #pad-desktop {display: none !important;} } @media only screen and (max-width: 100%;} #pad-desktop {display: none !important;} } WebDevPro #113 Building Scalable Django Apps Real-world insights for sharper web dev decisions Hi , Modern teams ship fast under real pressure. Django helps them stay disciplined and ship reliable and scalable applications. This article starts from that reality and lays out a path that a small team applies without detours. We build on three fundamentals: the Model View Template pattern provides structure, the data model sets the contract, and the ORM turns relationships and constraints into clear code. To keep those fundamentals consistent across development, staging, and production, migrations record every change as a readable history. As the application’s surface area expands with more models, views, and endpoints, your team shapes the Django admin into an internal product with purposeful list views, filters, and task pages that match operator workflows. This article shows how to design clear models and write migrations alongside each change so every environment stays aligned. You use bulk operations and Q objects for honest queries, shape the admin for operators with purposeful lists, search, filters, and focused views, and configure sessions, sign in, and group-based permissions that keep access consistent. You give uploads a predictable path with validation and privacy, keep views thin with rules in models or services, and write readable templates. With that foundation, you add REST endpoints and selected packages and test each addition against a migration history that records intent. But let’s catch up first. Here are the top links from the last issue in case you missed them: ⚡Angular now supports generating apps in Google AI Studio ⚛️React 19.2 focuses on stability and polish ⚛️Trying SolidJS made me rethink React 🤖Introducing Claude Sonnet 4.5 Have any ideas you want to see in the next article? Hit Reply! Advertise with us Interested in reaching our audience? Reply to this email or write to kinnaric@packt.com. Learn more about our sponsorship opportunities here. Start with the model as the single source of truth Everything you expose to users flows from a coherent model. Django’s ORM gives you a crisp vocabulary for entities, relationships, and constraints. Migrations record that vocabulary as an auditable timeline. The material stresses a simple rule that pays off across teams and environments. Define models and migrations early. Let queries and views grow out of those decisions. The payoff shows up in these everyday moments: CRUD that reads like prose through well-named fields and relationships Bulk create and bulk update when ingesting or repairing data Complex lookups with Q objects that remain readable because the underlying model is clean The immediate habit to adopt is writing migrations alongside model changes rather than after the fact. This keeps development databases, staging, and production honest. Teams that do this avoid slow-moving shape drift and reduce rework. You also gain the freedom to write expressive query code. A mature model collapses the need for ad hoc SQL while still giving you the option to drop down when necessary. Working guidelines for the data layer Prefer explicit foreign keys and related names that read well in templates Keep validation close to the model so forms and APIs inherit the same rules Reach for bulk operations when you are touching large sets of rows Use Q objects to encode business logic into queries without burying it in loops These are not advanced techniques. They are the day to day moves that keep your application fast and legible. The material returns to them at every step, which is why the example app remains steady as features stack up. Treat migrations as narrative, not overhead Migrations are the memory of your system. The chapters highlight how a careful migration sequence documents intent. You can see why a field changed type, why a constraint appeared, and where a relationship split. Teams often rush past this and pay for it later. A good rule is to read your migration diff out loud. Create and apply migrations in sequence across development, staging, and production. If the story is hard to follow, the change may need another pass. Clear migrations reduce onboarding time for new contributors and drop the risk of nighttime surprises in production. Make the admin a product that serves operators The default admin is a gift for internal users, but it becomes great when you shape it around real workflows. The content shows how to customize the admin site, extend ModelAdmin with form enhancements, and even add purpose built views into the admin app. This lets you promote operational chores to first class UI: Curated list displays that surface the fields your team actually uses Filters and search that mirror how support and editorial teams think Inline editing where it makes sense to reduce navigation time. Dedicated views for tasks that do not fit the stock create or change screens Here is a focused admin changelist that puts bulk actions and filters where operators need them: Changelist view with row selection, bulk actions, search, and a filter panel for staff status, superuser status, active, and groups. Operators act on multiple users at once and reach the right records quickly. The right mental model is to see the admin as an internal product with users, goals, and cost of delay. The sample material reinforces that by showing how to modify the user model when the defaults fall short and how to wire custom pages into the admin when a workflow needs more guidance. Time invested here pays immediate dividends in lower support friction and fewer mistakes. Sessions and authentication that earn user trust Sessions, sign in, and permission checks become invisible when they are handled well. They become painful when the details are fuzzy. The session and authentication chapter anchors three essentials: A session stores state you actually need and nothing else Authentication identifies the user with clarity and secure defaults Authorization expresses what the user may do through roles and permissions Here is how Django exposes user permissions in the admin: Permission flags in the user screen make access rules visible and easy to audit. Use groups for most cases so these choices stay consistent across pages and APIs. Django gives you strong primitives in all three areas. Sessions keep track of user context without leaking private data. Authentication plugs into built in views or custom flows. Permissions and groups let you express access rules at the level of the real world. The material emphasizes groups because they scale better than managing flags one user at a time. As requirements grow, you can adjust a group once and bring many users along safely. A common failure mode is to let permission logic scatter across views and templates. The guidance here is to keep those checks close to the model and leverage the framework’s permission hooks. Your templates stay simple and your API endpoints remain predictable. Media uploads and serving without drama Media is everything your users add after deployment. Images, documents, and audio need a clear path from the browser to storage to display. The content frames media as a space between dynamic data and static files. It is not compiled into your build and it is not just another row in your database. That middle nature matters because it affects storage, caching, and security. The playbook you can lift is straightforward: Give media a dedicated storage location and URL path Validate uploads at the form and model levels Render media through templates that respect permissions Offload heavy lifting to a file service when traffic justifies it This keeps media a friend rather than a source of fragility. Teams often overcomplicate this and end up with slow pages or leaky access patterns. The material’s stance is pragmatic. Get the basics right and grow the solution only when traffic and file size force the issue. Join Snyk on October 22, 2025 at DevSecCon25 - Securing the Shift to AI Native Join Snyk October 22, 2025 for this one-day event to hear from leading AI and security experts from Qodo, Ragie.ai, Casco, Arcade.dev, and more! The agenda includes inspiring Mainstage keynotes, a hands-on AI Demos track on building secure AI, Snyk's very FIRST AI Developer Challenge and more! Save your spot now! Views and templates that explain themselves Django’s View and Template layer remains effective because it stays close to the mental model of request in, response out. The instructional flow leans on conventional views where they shine and uses class based views when reuse becomes valuable. Templates present state with clarity rather than cleverness. A few principles stand out: Keep view logic thin by pushing business rules to models and services Choose class based views when you are repeating the same structure Keep templates boring and predictable to help readers and translators Avoid hidden work in template tags unless you need it The examples connect back to the data layer. A crisp model keeps views light. Your templates then focus on presentation rather than computation. A pragmatic path to APIs and third party integrations The material touches on building REST APIs and integrating third party modules once your core web views feel solid. Django’s ecosystem gives you well maintained packages for serialization, authentication, pagination, and testing. The advice is to reach for these building blocks when you need them rather than rolling your own. Strong defaults reduce risk. A small team can ship features faster and spend less time on edge cases. This is also where your earlier work in models and migrations pays off. A clean model maps to a stable API. Permissions flow from the same rules you apply to templates. The admin remains your internal cockpit for support and data fixes. Put it together in a project that grows with you The book-review site that runs through the content is a smart teaching choice. It forces you to care about readers, editors, and administrators. It touches the full stack without getting lost in novelty. If you follow the sequence, you end up with a system that feels simple because its pieces are simple: Add APIs and third-party packages when the foundation is steady. Stability at the core makes integrations fit cleanly and keeps the codebase easy to reason about as the product grows. That is how Django 5 supports teams that ship fast without letting the edges fray. Models that capture books, reviews, and relationships clearly Migrations that document change as the site evolves Views and templates that present content without hidden work An admin tailored to how your team actually operates Sessions and authentication that protect users and data Media handling that stays out of the way until it needs to scale That is the heart of a calm Django 5 application. Got 60 seconds? Tell us what clicked (or didn’t) Implementation checklist for your next sprint Define or refine your core models and generate migrations on the same branch Audit queries and upgrade any heavy loops to ORM expressions or bulk operations Review the admin with your operators and add the two improvements that save them the most time Map your session data and remove anything unnecessary Review permissions and move ad hoc checks into model level rules Trace your media flow from upload to display and document it in one page Treat this as a loop you run each quarter. The foundation will stay healthy while features keep landing. Final words A calm Django app starts with the model. Treat it as the contract, keep entities and relationships clear, and let migrations tell the story of change so intent stays visible and releases stay safe. The admin earns its place when it behaves like an internal product. Curate lists, tune filters and search, and add a few targeted pages so operators work quickly and make fewer mistakes. Sessions, authentication, and permissions deserve the same discipline. Use groups to express access rules that remain consistent across templates and APIs, and store only the session state you truly need. Give uploads a simple plan from form to storage to template with validation at sensible layers, then keep views thin and push rules toward models or services so templates read cleanly. Add APIs and third-party packages when the foundation is steady. Stability at the core makes integrations fit cleanly and keeps the codebase easy to reason about as the product grows. That is how Django 5 supports teams that ship fast without letting the edges fray. Got 60 seconds? Tell us what clicked (or didn’t) Cheers! Editor-in-chief, Kinnari Chohan SUBSCRIBE FOR MORE AND SHARE IT WITH A FRIEND! *{box-sizing:border-box}body{margin:0;padding:0}a[x-apple-data-detectors]{color:inherit!important;text-decoration:inherit!important}#MessageViewBody a{color:inherit;text-decoration:none}p{line-height:inherit}.desktop_hide,.desktop_hide table{mso-hide:all;display:none;max-height:0;overflow:hidden}.image_block img+div{display:none}sub,sup{font-size:75%;line-height:0}#converted-body .list_block ol,#converted-body .list_block ul,.body [class~=x_list_block] ol,.body [class~=x_list_block] ul,u+.body .list_block ol,u+.body .list_block ul{padding-left:20px} @media (max-width: 100%;display:block}.mobile_hide{min-height:0;max-height:0;max-width: 100%;overflow:hidden;font-size:0}.desktop_hide,.desktop_hide table{display:table!important;max-height:none!important}} @media only screen and (max-width: 100%;} #pad-desktop {display: none !important;} } @media only screen and (max-width: 100%;} #pad-desktop {display: none !important;} }