API World + AI DevWorld

Designing APIs that will enable developers to be truly inventive and business to expand into new contexts and experiences is a technical challenge. This talk is on public API design and governance process. It is meant for technical people involved in creating interfaces that empower 3rd party developers. After dealing with legacy APIs for years, we went on a journey to revamp our API program. Challenges that we faced are typical for all public API providers. The audience will learn about the overall governance process with a focus on design, compliance with standards, relying on patterns and OpenAPI specification, and significance of accurate terminology and non-ambiguous use of nouns and verbs. Following consumer-centric approach, providing predictable and understandable names across capabilities, and trying not to reinvent the wheel on every new API is common to any API development. API standards and design process are true elements of success.

As someone once said, “the only constant in the API world is change.” Whether you’re designing, building, testing, or using an API, things will change. Great API design is essential, but more critical to success is effective, ongoing collaboration. During API . design and development, it is nearly impossible for a designer to anticipate all of the possible needs, issues, and potential blockers alone. Having the tools necessary for teams to develop in parallel, communicate with each other, and maintain a single source of truth can make the difference between API failure and success. This talk will break down the main components of successful collaboration in API design and development, including examples of tooling, standards, and actual use cases. He will address how you can create better team workflows, track feedback, maintain multiple API versions, and effectively develop in parallel so that your API development team remains effective.

Microservices is all the rage, as it gives you agility, flexibility and separation of concerns as you move away from a monolithic architecture. However, it is not without its pitfalls, and doing it at scale with a running system is a bit like changing the engine while the car is running. I'll talk about lessons I've learned at Shippo and past gigs in trying to go for a microservices design. It's not a panacea and could end up hurting your product if you do it wrong.

When Capital One embarked on the enormous microservices journey, crossing path with kubernetes became inevitable. This session discusses in detail about the various design criteria that were taken into consideration in coming up with a target cluster design, team setup, support model in the most adopted 'You buil it, You own it' devops culture.