Maximizing API Management Efficiency: The Power of Shifting Down with APIOps - Dominic Lüchinger, SIX Group

Editor's Notes

• #1: Ask questions right away?
• #2: Short intro about me. Building platforms since almost two decades. I worked in the hosting industry, insurance and now finance. Automation is always key. Make technology accessable with a good user expirience. Also interested in security topics.
• #3: Mentioning Software Development => Full Software Development Lifecycle (SDLC) Devops = Collaboration + Automation + Continuous Improvement (Embrace failure) + Customer-centric action + End-to-End responsibility Monoliths are replaced by independent Microservice All this trends enable independence and agility of teams When executed well, it has a lot of benefits. Less coordination, better Lead Time for Changes, increased Deployment frequency
• #4: Shift left and Opsification are here to help to cope with the new responsiblities of software development teams. Shifting left involves moving tasks, processes, or responsibilities earlier in the software development lifecycle. Opsification is the integration of operational principles and practices into various aspects of software development disciplines. DevOps, FinOps, DevSecOps, MlOps, GitOps Look at this supernatural creatures that are called fullstack developers that are now doing all the Ops work shiften on them. Very nice. Big thumbs up.
• #5: Cognitive load or overload refers to the excessive mental strain experienced due to managing complex tasks. The cognitive load increased significantly as new responsibilities were shifted onto the team's shoulders. Skill siloing limits knowledge sharing and collaboration, resulting in inefficiencies and dependency on specific individuals or teams. Islands of Divergence: Within the software development landscape, there exist islands of divergence where unique methodologies, compliance considerations, and interpretations of standards thrive.
• #6: This were shifting up come to play Add abstractions. Build up dedicated teams support the platform. But how to get started?
• #7: When talking about a platform I would think of a software or infrastructure component glued together by code and presented with UI to the user. I'd like this definition because it's has no emphasis on the how and what. Instead it focus on the aspect that a platform needs to be treated and managed like a product.
• #8: It's obsification, all over again. Ask who is familiar with GitOps. Otherwise explain it. Why start with API? The responsibility of API's are exchanging data. Data is at the core of every business process. APIOps combines DevOps and GitOps principles, led by a specialized platform engineering team. This ensures streamlined processes, consistent outcomes, and a renewed focus on quality throughout the API lifecycle. By embracing APIOps, we unlock benefits like standardized contracts, seamless collaboration, and automated CI/CD pipelines. It's not just a buzzword—it's a pathway to success in API development.
• #9: The typical start is to create a centralized catalog on Confluence or your Collaboration ​Tool of your choice. If it's well maintained and supported, congratulation, you have a platform. If this catalog fulfills all your organization needs, even better. But the changes are high that while your organization grows the platform also needs to keep up. Think of it like a maturity model.
• #10: Putting your API catalog (formly OpenAPI definitions) in a git repository ​will quickly result in a lot of benefits. My assumption is, that you use a tool like Github, GitLab or Bitbucket, which itself are already good enough platform at your disposal. With the help of this platform is easy to structure the catalog, define basic authorization restriction. Eg. give people different roles to a repository, protect certain branches, demand Pullrequest for changes. Most of this platform come with a UI and an editor. Simple edits can be performed by anyone in the browser. In addition to the API specification I would recommend storing a metadata file alongside. This YAML/JSON/Text file contains information about the owner of an API and any other relevant data. Don't forget the benefit that all the changes are now under version control and can help with audit requirements. The next step from here is obvious.
• #11: Keywords: Linting, validation (compliance), documentation, dependency management, security scanning, automated testing Highlight the importance of integrating compliance measures into the APIOps platform to ensure regulatory adherence. All this codified parts will reduce the cognitive load of your development teams.
• #12: The next step and probably the most difficult is going from reading the API data and validating them (the CI part) to the rollout of API changes. In the most basic version this could be a regeneration of a API documentation. In the case of SIX we go multiple steps further. The holy grail of the maturity model is an self-service platform with little or no human interaction in the rollout process.
• #13: Sheduled change, auto register in change management (compliance)
• #14: Some stats: Overall 850 Published 600 PROD approx 170 13 clusters => 90 Namespace => 14 envs + 1 Azure
• #16: Overall it reduces kognitive load, moves the dedicated API knowladge to the platform team, the platform unifies
• #17: You need more then OpenAPI specification to provide some benefit. Metadata and sometimes multiple OpenAPI specs are required. We also figured out, that you might need multiple git repositories. One to store the meta data and OpenAPI specs arranged in folders like one per app. This data is then transformed with the help of a simple templating engine to the desired controle plane config or what ever post processing you might need. YAML, terraform rules, API calls. Explain MVC principle. Changes can be made easier. When starting our, introduce guidelines and compliance rules like formating and required meta data from the start. Try to aim for a single source of truth. Avoid manual overwrites not stored in the single source of truth. Most tools nowadays allow for UI access. All our admin users are read only. Break the glass procedure.
• #18: Now to the question. Do I need a platform team to be successful. Fake it until you make it. The minimum viable product (MVP) represents the smallest version of a product that can be released to satisfy initial customer needs, but a lot of things are mocked and faked, while the thinnest viable platform (TVP) focuses on creating the minimal infrastructure necessary to support product development and delivery. Iterate, Iterate.