Internal Developer Platforms (IDPs) - Simply Explained

Hello everyone and welcome to another episode of Microsoft Knowledge Nuggets here on M365. FM, I'm Mirko Peters. Imagine you need to launch a new customer app. You need a place for the code. You need a database. You need access to Azure. You need a build and release pipeline. Then you need logs, alerts and a way to see if the app is working. That sounds like one request. But in many companies, it turns into tickets, handoffs, Azure portal screens, copied setup nodes, and a long wait for someone from another team. Developers want to build the feature. Instead, they can end up learning just enough Azure, Kubernetes, networking and security to get past the next blocker. An internal developer platform or IDP changes that experience. In plain English, we'll look at golden paths, service catalogs, guardrails and where Azure fits. And one question will stay with us. Is an IDP just a portal with buttons? Or is there much more working behind it? Why developers need a better way to get things done? Picture a small team that needs to release a new customer facing service. The business has a clear request. It does need a simple page where they can check the status of an order. The developer has the code ready. The team knows what the page should do and everyone expects it to go live soon. Then the setup work begins. Someone creates a git repository, which is the shared home for the code. Another person needs to find the right Azure subscription. The service needs a network connection. It needs an identity. So it can safely talk to other services. It needs a safe place for secrets such as connection details. It needs a build and release process. It's called CI/CD, which means the automated steps that test and publish changes. Finally, it needs monitoring so the team can see errors before customers start reporting them. None of these jobs are strange. They all need doing. The problem begins when every new service starts from zero and each team has to discover the same answers again. A developer might open a ticket for access, wait two days, then receive a link to an old document. The document points to a portal screen that changed last year. After that, another ticket asks for a database. A third request asks for a network rule. By the time the service reaches testing, the developer has spent more time joining systems together than building the customer feature. You've probably seen this in your own work. The developer's intention is simple. Release a useful service quickly. The obstacle is not the code. The obstacle is the queue of setup work, decisions, permissions, and different tools. If the team can't clear that path, a small request becomes a slow project and customers wait longer than they should, there's another cost as well. When each team creates its own setup, the company collects many slightly different ways of doing the same job. One service has a good release pipeline. Another has a pipeline that only one person understands. One team stores secrets safely. Another team puts a password in a configuration file because they were in a hurry. A service breaks at 2am, but nobody knows who owns it or where its logs live. Support becomes hard because every service looks different. Security becomes hard because people have to remember every setting every time. And new developers spend their first weeks asking where things are instead of learning the product they joined to build. This is where platform engineering comes in. A platform engineering team treats the tools and shared setup inside a company like an internal product. Developers are the customers. The team listens to repeated problems, creates simpler ways to do common work, and improves those ways based on feedback. It doesn't replace developers. It doesn't replace operations, cloud teams, security teams, or architects either. Those people still bring their skills. The platform team takes shared knowledge from across those groups and turns it into something other teams can use without rebuilding it themselves. So what is an internal developer platform? Think of it as the company's self-service front door to approved building blocks for software. A developer asks for something in a simple way. Behind that request, the platform connects the right people, rules, tools, and automation. The front door can be a website, a command line tool, an API, or even a form stored with the code, but self-service only helps when the root behind that front door is already clear. Golden paths. The paved road for common application work. The first building block is called a golden path. A golden path is an approved, repeatable route for a job that teams do often. It doesn't tell every developer how to write their code. It gives them a known way to turn that code into a running service without starting the setup from scratch. Think of a well-planned office building. Each office room has a standard layout. The lights work when you arrive. Power sockets are already in the walls. The door locks properly. And if there is an emergency, the fire exit is marked and ready. You can still arrange your desk how you like. But you don't need to install electricity, build a door, or work out the safety rules before you can start your day. A golden path does the same kind of work for a common application. Imagine your team needs a standard web service in Azure. The path might start by creating a Git repository, the shared place, where the team keeps its code. It can add starter code so the team doesn't begin with an empty folder. It can set up a built pipeline that checks the code and prepares it for release. From there the service needs a home in Azure. That could be Azure app servers for a regular web app, or another approved hosting choice that suits the company's needs. The path also connects logs and alerts, so the team can see whether the service is healthy after it goes live. There's one more part that people often miss at first. The service itself needs to prove who it is when it talks to other Azure services. Instead of keeping a password in code or a settings file, it can use a managed identity. Think of this like an employee badge for the application. Azure can recognize the service and give it only the access it needs. Notice how much setup sits behind one simple request. The developer should not need to choose every Azure resource, every security setting, every release rule, and every monitoring connection. Those choices matter, but most should already have a sensible answer. So the request can stay small. The developer might enter the service name, choose the team that owns it, select development or production, pick the programming runtime, and choose from a short list of approved options. That is enough for the platform to start the right setup. Behind the scenes, the platform creates the Azure resources. It applies access rules. It connects the service to a safe place for secrets. It adds the deployment settings. It links the service to monitoring. The developer sees the result, not the pile of setup work. This is why defaults help. People often think more choice always means more freedom. But when you're trying to release a small service, a long list of cloud choices can slow you down. You may not know which option fits. You may pick a setting that works today but becomes hard to support later. A good default removes choices that should not need a fresh debate every time. It gets the first deployment out faster. It means support teams recognize the setup when there is a problem. It also means a new developer can follow the same route as an experienced one, rather than relying on old notes or a helpful person in a chat channel. But a golden path must not become a locked hallway. Some applications have unusual needs. A team might need a different hosting model, a special network connection, or a service that the standard path does not cover. If the platform says no without a route forward, people will build their own workarounds outside the platform. That creates the exact confusion the platform was meant to reduce. So good golden paths include an escape hatch. This is a clear control process for special cases. The team explains what they need, the right people review it, and the result can become a new approved path later if other teams need the same thing. The golden path helps create a service. But after a company has hundreds of services, teams need another answer. How do you find a service, understand it, and know who looks after it? The service catalog. Your company's map of running software. Creating a service is only part of the job. A few months later, someone needs to change it, support it, or find out why it failed. That is where a service catalog helps. A service catalog is one place that records the software your company runs. For each service, it can show the name, the owning team, links to documentation, the services it depends on, its current status, and the right support links. Think of it as a filing cabinet with labeled folders. Without it, information ends up scattered across old chat messages, bookmarks, documents, and the memory of the person who built the service two years ago. That person may have moved to another team, the service is still running, but nobody feels responsible for it. A catalog gives the company a reliable record. You might open it because you need to use an API, which is a way for one application to talk to another. Before you use it, you need answers. Who owns this API? Where is its source code? Which database does it connect to? Is it healthy right now? And if it stops working overnight? Who receives the alert? Those are simple questions, yet they can take hours to answer when there is no shared place to look. Imagine you join a new team and are asked to update an order service. Instead of searching through team's messages from last year, you open the catalog. You find the service page. It shows the owner a link to the code in Azure DevOps or GitHub and the runbook, which is a set of instructions for handling common problems. The same page can link to an Azure Monitor dashboard and application insights, where you can see errors, response times, and live activity. It can point to the Azure resources the service uses. It can also list dependencies such as the payment service or the database it needs before it can work. That turns a mystery into a starting point. It also helps people see the difference between a catalog and a portal. A portal is usually where you go to ask for something or manage something. You might use a portal to create a new service, request access, or trigger a task. A catalog records what already exists and gives you the information needed to understand it. Sometimes the two sit in the same website. That is fine, but they do different jobs. One is the front desk where you make a request. The other is the company's map of the software already running. Microsoft tools fit naturally into this picture. A catalog entry can connect to Azure Monitor for health data, application insights for app details, Azure DevOps or GitHub for the code, Teams for the support channel, and Azure itself for the resources behind the service. You do not need every detail copied into one screen. You need clear links that take you to the right place without guessing. Ownership is the quiet benefit here. When every service needs an owner, fewer services become abandoned. During an incident, support staff can quickly find the team that knows the service. The team can see the dashboard, read the runbook, and check its dependencies instead of spending the first hour working out what they are looking at. A map helps people find the road, but it cannot stop unsafe driving. Guardrails, freedom inside safe boundaries. A service catalog helps you find what exists. Guardrails decide what can safely happen when someone creates or changes something. Guardrails are rules and approved, defaults built into the platform. They let teams work on their own while keeping the company's security access and cost rules in place. Without guardrails, there are usually two bad choices. The first is to approve every request by hand. A developer asks for a database, an Azure role, or a new environment, and the request waits for someone to check it. That may feel safe, but it creates queues, people lose time, and the people doing approvals spend their day checking the same routine requests. The other bad choice is to give everyone broad access and hope they remember every rule. That feels fast until a password appears in source code, a service is created in the wrong region, or a test environment produces an unexpected Azure build. Guardrails offer a better path. If a request follows the approved rules, it moves forward automatically. If it needs something unusual or risky, the platform stops it early and points the team toward the right process. Identity sits at the center of this, think of Microsoft Entra ID as the reception desk for your digital workplace. Before someone enters, the reception desk checks who they are. It also checks which rooms they can enter and what they are allowed to do once inside. A developer signs in with their company account. Azure ID can place that person in the right group based on their team or role. The platform can then allow that group to create a development service, view a dashboard, or manage a specific Azure resource. It does not need to give every developer permission to change everything. This is called least privilege. In plain English, people and applications receive only the access they need for the job in front of them. No more. Azure also gives platform teams ways to set rules across larger parts of the company. Management groups help organize Azure subscriptions under shared rules. Azure Policy checks whether resources follow those rules. A company may allow services only in approved Azure regions. It may limit certain resource types. It may require every resource to carry tags such as the owning team, cost center, and environment. Those tags sound small, but they answer questions later. Who owns this resource? Why are we paying for it? Is this for testing or production? Without those answers, Azure can quickly become difficult to manage. Policies can also check security settings before a resource is created. For example, a database may need encryption enabled or a storage account may need to block public access. The platform can apply these expectations every time, rather than asking every team to remember them from a document. Secrets need the same care. A secret could be a database password, an API key, or a connection string. It should not live in the application code. It should not sit in a pipeline file where more people can see it than necessary. Azure Key Vault provides a protected place to store those secrets. Even better, a service can often use a managed identity instead of a password. The application proves its identity to Azure, and as your grants the access already approved for that application, there is less secret handling for developers and fewer passwords that need replacing later. Security checks also continue after the service is running. Microsoft Defender can help spot risky code, weak cloud settings, exposed secrets, and signs of threats across the platform. This does not mean every developer becomes a security specialist. It means the platform brings useful checks closer to the normal work of building and running software. Cost needs boundaries too. The self-service request should not accidentally create the largest database size, run forever, or appear without an owner. Approved sizes, budgets, tags, spending alerts, and resource limits help teams see costs early, while there is still time to act. Good guardrails do not turn the platform into a ticket machine. They remove the slow approvals for normal work while keeping clear boundaries around access, security, and money. Teams can move faster because the safe choices are already built into the path. Those safe building blocks still need one more thing. When a developer makes a simple request, automation has to turn that request into a working service. What happens after you click Create Service? So a developer opens the platform and clicks Create Service. That request might come through a web portal that might come from a command line tool. It could be an API call from another system. Some teams may even make the request through a small form stored in their git repository. The front door can change. What matters is that the developer describes what they need in a short, clear way. You might ask for a web service called Order status owned by the checkout team with a test and production environment. Then the platform starts work behind the scenes. One request can create a new code repository with a standard folder layout. It can add a build and release pipeline. It can create the Azure resources the service needs. It can give the service the right permissions. It can connect monitoring. It can create a documentation page with links that help the next person understand the service. The developer asked for one service. The platform completed a chain of work that normally crosses several teams and tools. This works best when the request describes the result, not every technical action needed to reach it. For example, the developer says, I need a web service running in test. They do not need to say create these exact Azure resources, connect these settings, add these permissions, and run these scripts in this order. That approach is called desired state. In plain English, you describe what you want the finished setup to look like and automation creates it and keeps it that way. If the expected setup changes later, the platform can compare what should exist with what actually exists, then correct the difference. You can think of it as a written order for a service. The order says what the service needs. It does not ask the developer to personally visit every Azure screen and assemble the parts by hand. Many teams keep that order in Git. This is where GitOps fits into the picture. GitOps means the requested setup lives in a Git repository alongside a history of every change. Someone can review a proposed change before it takes effect. The change has a record. Automation reads the approved files and applies the setup. If a team changes a service from one environment to another or asks for a new database setting, the request does not disappear into a chat message. It becomes a tracked change that gives teams a clearer record of who changed what when they changed it and why. It also means the platform can rebuild a known setup instead of relying on somebody's memory. Azure gives you several tools that can sit behind this process. Bicep is one option for describing Azure resources in code. Terraform is another popular option that can describe Azure resources and resources from other cloud providers. The platform can use one of these tools to create the hosting, storage, databases and network settings that the service needs. For the build and release work, a company might use Azure DevOps pipelines or GitHub actions. Those automated jobs can test the code, build the application and release it through the approved environments. For hosting, a simple service might run in Azure App Service. A company with container-based applications may use Azure Kubernetes service usually called AKS. The developer does not need to become an AKS expert just to get a normal service running. A platform can provide approved application templates, ready to use namespace, which is a separated area inside Kubernetes or a prepared environment for a team to use. The deeper Kubernetes setup stays with the people who run the shared foundation. Sometimes the company needs stronger separation between teams while still sharing the same underlying Kubernetes capacity. A tool such as VCluster can help with that. It creates virtual Kubernetes spaces for separate teams on a shared host cluster. Each team gets an environment that feels more like its own cluster while the company avoids creating a full physical cluster for every small need. VCluster is one possible building block. It is not a requirement for an IDP. Neither is bicep, terraform, Azure DevOps, GitHub actions, AKS or any single portal product. Tool choices matter, but the bigger question is simpler. Does the platform remove real friction for the people building software or does it add another screen and another process? That question leads directly to the biggest myth around internal developer platforms. One IDP is not and where Microsoft 365 and Azure fit. An IDP is not backstage or any other single portal product. A portal can be the screen people use, but the platform includes the people who maintain it, the standards they agree on, the automation during the work and the ways developers interact with it. It also does not replace DevOps, cloud team security teams or architects. Instead, the platform team turns their shared knowledge into reusable paths that every development team can use. Azure supplies, much of the foundation behind those paths, compute storage, databases. Networking, monitoring, policy and security. Entra ID connects identity across Azure, Microsoft 365, developer tools and internal systems. Teams often becomes the everyday work layer where alerts arrive, approvals happen, support links live and service notifications reach the people who need them. Start small, pick one painful workflow, one team and one golden path. Listen before you build more. That brings us to the practical first move, start with one useful path. Find the request developers repeat most often and dislike doing by hand. It might be a standard web service, a background worker or a managed database. Choose one narrow offer, then make the request simple. A name, an owner, an environment and only the choices that truly matter. Behind that request build the approved Azure setup, identity, secret storage, deployment logs and ownership record. Put guardrails in early, require an owner, apply cost tags, limit locations, check the security baseline, create a catalog entry automatically with links to code, documentation, dashboards and the support contact. Then measure what changed, waiting time, repeat tickets, failed setup steps, adoption and developer feedback. Each useful path becomes another working part of your company's digital office building. An internal developer platform is an internal self-service system that helps teams build, release and run software safely. Its building blocks are simple to name, even if the work behind them takes care. Golden paths for common work, a service catalog for ownership, automation for repeatable setup, guardrails for safe choices, identity for access and visibility into what is running. Try one exercise this week, write down one developer request that appears again and again, then list every handoff ticket approval tool and person involved before that request becomes a working service. That list shows you where a first platform path could help. Before building a portal, learn the foundation beneath it. Look at Azure landing zones as your policy or as your DevOps foundations. A button only helps when the system behind it knows what to do.