Skip to content
academia.sh
tr
Log in

Course Advanced

Platform Engineering

Published Updated

By the end of this course

Start course

01

The Platform Approach

When abstraction pays off: the reason platform engineering exists at scale and the threshold it needs, setting up the internal customer and the feedback loop as a product, the scope of a recommended and supported golden path, tying the balance between mandate and freedom of choice to a number, and the cost of the self-service that removes the request queue.

  1. 01 What Is Platform Engineering Measuring the platform as an abstraction: the eighteen items that seven courses leave for every team to rebuild are listed by type, the rebuild work per team is counted, scanning the team count derives the threshold where the platform pays for itself, and the person-days the platform costs below that threshold appear in the same table.
  2. 02 Platform as a Product Measuring the internal customer and the feedback loop: the same twenty-four requests are run under an on-demand regime and a product-managed regime; adoption, the count of capabilities that go unused, the work spent on them, the time between a request and its fulfillment, and the gap the product approach opens in product teams are all counted.
  3. 03 Golden Paths Measuring the recommended and supported path as a scope: a golden path is defined along the axes of language, data store, and deployment format, applied to five teams' requirements, the support a team loses by stepping outside is counted item by item, and as the scope expands, the number of teams that fit, the maintenance load, and the combination count are scanned together.
  4. 04 Standardization and Autonomy Balance Measuring mandate and freedom of choice together: each of ten items is run in mandatory, default, and free modes, the number of distinct choices born and the number of items where the shared tool still works are counted side by side, how many teams' legitimate requirements mandate blocks is derived, and the gap between guardrail and wall is shown in person-days.
  5. 05 Self-Service Measuring what removing the request queue is worth: the same request set is run through a request queue and through a self-service regime, wait time and the platform team's interruptions are counted, the costs of writing the interface, misuse, and irreversible operations are derived, and the request type where automation does not pay off is named.

02

Platform Capabilities

The concrete capabilities the platform offers and the measurement of their effect: environment generation on demand, template and scaffold generation that starts a new service, the developer portal and service catalog that make ownership and dependencies visible, automating rules by embedding them in the pipeline, cost visibility through per-team resource accounting, staging platform migrations and adoption, and delivery speed and stability indicators.

  1. 01 On-Demand Environment Provisioning The same ninety-day request flow is run through two paths: a human-staffed request queue and an environment generated on demand. Wait time, environment lifespan, idle environment-days, and abandoned environments are counted; sweeping the lifespan limit derives the tradeoff between rebuild work and data loss.
  2. 02 Template and Scaffold Generation How many files, lines, and decisions it takes to start a new service by hand, and how many of those a scaffold removes. Five services are generated as real files and compared line by line against a hand-written service, then the number of services left behind once the template is updated, and what catching that drift costs, is measured.
  3. 03 Developer Portal and Service Catalog An ownership and dependency graph is built from twelve catalog records; unowned services, orphan dependencies, and unregistered services are counted. Time to reach the correct oncall list across five incidents is measured with and without the catalog, then the record's own cost is derived: how many fields are written by hand and how many records disagree with reality.
  4. 04 Policy and Compliance Automation The same six rules are run against the same twelve service definitions in two arrangements: publishing the rule as a document and embedding the rule in the pipeline. Compliance rate, violation count, and time teams spend are compared; the real measure is invisibility — how many teams comply without ever seeing the rule, how many ask for an exemption, and how long that exemption's lifespan runs.
  5. 05 Cost Visibility Team-based resource accounting: only 47.5% of a daily 1,376 fictional units can be directly assigned, each of three allocation rules misleads a different team in a different direction (the equal-share rule loads field +79.0 while the request rule loads meter-reading +140.7), only 15.6% of the bill drops after cost is shown while 29.7% never moves at all, and central accounting pays for itself at three teams but two teams opting out drags the five-team gain of 85 units down to 3 units.
  6. 06 Migration Strategies Splitting a platform migration into waves: when five fictional teams migrate in a single wave, the program drops from 65 days to 15 days while the number migrated drops from 4 to 2; the three reasons for being left behind (incompatible requirement, critical period, orphaned service) kick in one after another; dual-run load drops from 105.3 to 0, while peak support load stays under the 6-unit budget only in the single-team wave; and, because of the one team that never migrates, the legacy arrangement stays open indefinitely, costing 41,610 fictional units over 1,095 days.
  7. 07 Platform Metrics Measuring whether the platform actually works: only twenty-five of forty team-capability pairs are filled, two capabilities costing fifty-four work-days serve at most one team, 48%-77% of the raw gap in four delivery metrics comes from selection bias and the difference-in-differences stays smaller than the within-group spread in all four, the same 550-minute outage turns into 2,750 team-minutes under central adoption, and forcing adoption improves the metric by 60% while making work per usage 18% worse.

Final exam

Platform Engineering — Final Exam

In preparation

This course's question bank is not complete yet. The exam opens here automatically once enough questions are added.

Start typing to search.

↑↓ ↵ Esc navigate · open · close