Define platform service Pydantic models — lab audio overview

Host: Welcome back. You're in AI Developer Platform Engineering — a course about building the internal systems that let a company's AI developers ship fast without reinventing the wheel every time. This chapter is called Internal Developer Platform Vision. The big idea here is designing a central system where developers can browse available services, pick one, and get started in minutes instead of weeks. Today's exercise is the very first building block of that system. Expert: Let me paint the picture. Imagine you're on a platform team at a mid-sized company — maybe two hundred engineers, a dozen AI teams, all trying to ship features that use large language models, vector search, fine-tuned models, and so on. Without a central platform, every team ends up cobbling together their own setup. One team spins up their own vector database. Another team picks a different one. A third team writes custom code to call an external AI service. Six months in, nobody knows what's running, security can't audit it, costs are spiraling, and new hires take weeks just to find what's available. The fix is something called an internal developer platform — think of it as an internal app store for engineering services. Developers open a portal, see a catalog of approved building blocks, and pull them into their projects with confidence. But before you can show anything in that catalog, you need a clear, consistent way to describe what each service actually is. That's where this exercise comes in. You're building the shape of a catalog entry — the blueprint that every service in the platform will follow. Host: So this is the starting point for the whole chapter. The overview walked through the vision of a self-service platform. Now we get concrete. What exactly are we building? Expert: You're building a set of structured data blueprints — formal descriptions of what a platform service looks like. Think of it like designing the fields on a trading card. Every card for every service in your catalog will have the same slots: a name, a description, who owns it, what tier of service it is, what it depends on, and how you configure it. The tool you'll use for this is called Pydantic. Pydantic is a popular Python library whose whole job is to let you describe the shape of your data and then automatically check that any data you receive actually matches that shape. If someone tries to register a new service but forgets to include an owner, Pydantic catches it immediately and tells you exactly what's missing. You'll define four blueprints in total. First, the basic information about a service — its name, description, and who's responsible. Second, a way to describe how the service is configured, so teams know what settings they can tune. Third, a way to declare what other services this one depends on — for instance, a chatbot service might depend on a vector database and a language model gateway. And fourth, a tier classification — is this service experimental, supported, or critical production infrastructure? Each tier carries different expectations around reliability and support. Host: Before anyone starts, what's the thing that usually trips people up? Expert: The biggest trap is making the blueprints too loose or too strict. If you make every field optional and accept any value, you've basically built nothing — the catalog becomes a pile of inconsistent entries. But if you lock everything down too tightly, nobody can register their service because real-world services don't fit neat boxes. The sweet spot is being strict about the fields that matter for discovery and governance — the name, the owner, the tier — and more flexible about the internal configuration details, which vary hugely from service to service. A concrete tip: when you're defining the tier classification, use what's called an enumeration — a fixed list of allowed values, like experimental, supported, and critical. Don't let it be any arbitrary text. Otherwise one team will write "prod," another will write "production," a third will write "PROD," and your catalog becomes unsearchable. Pydantic makes enumerations easy, and this is exactly the kind of place where that strictness pays off. Host: Great. So what will the listener walk away able to do, and where does this go next? Expert: After this exercise, you'll be able to take any platform service at your company and describe it in a structured, validated way — a clean record that a portal can display, a search system can index, and an approval workflow can reason about. This is the foundation. Every other piece of the platform — the self-service portal, the cost tracking, the security audits — reads from these blueprints. It's the kind of work that sits quietly underneath a platform and makes everything else possible, and it's exactly the type of contribution your team will build on for years. In the next exercise, you'll extend this into what are called golden paths — pre-approved, opinionated templates that walk a developer through building something standard, like a retrieval chatbot or a document processing pipeline, using the services from this catalog. Then in the third exercise, you'll add a separate validation layer so that entries coming from outside your code — say, from a configuration file someone wrote by hand — also get checked rigorously before they enter the catalog. Host: Perfect. Go build the foundation of your platform's service catalog. Thanks for listening, and enjoy the drive.