(4) About Me

• Ph.D. in Communications Systems [http://dret.net/netdret/publications#wil97b] from ETH Zürich [http://www.ethz.ch/]
• Working on Web Architecture after writing the first Web Technology book [http://dret.net/netdret/publications#wil98]
• UC Berkeley (2006-2011), working on Service Models for Open Government [http://dret.net/netdret/publications#wil09g]
• EMC (2011-2014), working on transforming software products into service platforms
• Siemens (2014-2015), working on using IoT to build WoT (APIs for Things)
• Joined CA [http://www.ca.com/]'s API Academy [http://www.apiacademy.co/] in 2016 and now all about API Strategy and Design
• Active in the usual places such as Twitter [http://twitter.com/dret], GitHub [http://github.com/dret], my blog [http://dret.typepad.com/dretblog/], LinkedIn [http://www.linkedin.com/in/netdret], and flickr [https://www.flickr.com/photos/dret/]

(5) @dret on Twitter/GitHub

(6) API Academy [http://www.apiacademy.co/]

• Global Team working on API Strategy and Design topics
  • Matt McLarty [http://www.apiacademy.co/team_member/matt-mclarty/] (Vancouver): @MattMcLartyBC [http://twitter.com/MattMcLartyBC]
  • Mike Amundsen [http://www.apiacademy.co/team_member/mike-amundsen/] (Cincinnati): @mamund [http://twitter.com/mamund]
  • Mehdi Medjaoui [http://www.apiacademy.co/team_member/mehdi-medjaoui/] (San Francisco): @medjawii [http://twitter.com/medjawii]
  • Ronnie Mitra [http://www.apiacademy.co/team_member/ronnie-mitra/] (London): @mitraman [http://twitter.com/mitraman]
  • Erik Wilde [http://www.apiacademy.co/team_member/erik-wilde/] (Zürich): @dret [http://twitter.com/dret]
• Evangelizing ideas and technologies
  • Speaking (conferences, events)
  • Teaching (workshops, bootcamps)
  • Publishing (blogs, articles, books, podcasts [https://soundcloud.com/user-426834320])
  • Doing (side projects on API-related topics)
  • Standardizing (participating in specification work)

(7) Microservice Architecture

• Microservice Architecture: Aligning Principles, Practices, and Culture
• Authored by [http://www.apiacademy.co/microservice-architecture-the-oreilly-book/] API Academy [http://www.apiacademy.co/] members Irakli Nadareishvili, Ronnie Mitra, Matt McLarty, and Mike Amundsen
  • Get free electronic version courtesy of CA Technologies [http://transform.ca.com/API-microservice-architecture-oreilly-book.html]
  • Get a hardcopy version [http://shop.oreilly.com/product/0636920050308.do]

(9) Motivation #1: Breaking up the Monolith

(10) Motivation #2: Speeding up Product Delivery

(11) Microservices and APIs

• APIs are a way to loosely coupled component interfaces
  • APIs allow removing dependencies between components
  • Loose coupling is influenced by a variety of design factors
• Microservices are a way to loosely coupled component implementations
  • Microservices allow implementing services with fewer constraints
  • APIs can be anything but some landscape coherence makes sense
• Microservice Architecture means trying to optimize the balance
  • Avoid slowing down teams because of constrained design options
  • Help teams to be faster by assisting their design/implementation efforts

(12) There is no "Microservice API"

(14) MSA 6V Executive Summary

• Variety: More design freedom for teams
• Volume: Make experimentation economical
• Velocity: No more slow coordinated release schedule
• Visibility: Teams work decentralized
• Vulnerability: More openness means a bigger attack surface
• Volatility: Manage dependencies with decentralization in mind

(15) Variety

• Increased diversity of the API and implementation landscape
• Manage API descriptions in extensible ways
  • Your API ecosystem will evolve and new types will appear
• Provide guidance and assistance for preferred API styles/types
  • Guidance should be driven by observed team preferences
  • API ecosystems tend to converge around few technology clusters

(16) Volume

• More services are created because there is less ceremony
• Make API management part of general MSA automation efforts
  • API landscaping should focus on scalable methods
• API landscape automation must be able to adapt
  • Build as little bias as possible into the foundation

(17) Velocity

• Services change more often (if required) because of agile practices
• Loose coupling should be one of the pillars of API design culture
  • Design practices for loose coupling depend a lot on style and technology
• Expose version information as a way how service evolution can be tracked
  • Versioning should be informational only (no breaking changes)
  • Semantic versioning [http://semver.org/] can be exposed through the API

(18) Visibility

• It should be easy to find and use services as building blocks for new ones
• Deployment needs to also deploy information about the API
  • Simple description/documentation models [https://tools.ietf.org/html/draft-wilde-service-link-rel-01] as a starting point
  • Alternative models or more sophistication as required by landscape
• Service discovery is both about finding and binding
  • Finding is based on searching for services by capability/feature
  • Binding is the ability to locate a running instance of a service

(19) Vulnerability

• Support service security so that teams can focus on value creation
• APIs add to an organization's attack surface
  • Any connection to an outside party is a potential attack point
• Microservices makes it harder to properly design and implement security
  • Teams should not have to bother with implementing security
• Security is the classical use case of API gateways
• Security as a Service can be provided in different configurations
  • Centralized: Service logic is split between service and gateway
  • Distributed: Configuration is centralized while enforcement is distributed
  • Decentralized: Services own both configuration and enforcement

(20) Volatility

• Service decentralization needs different dependency management models
• Less operational coherence because of DevOps and differing service levels
• Resilient services are necessary to avoid rolling failures
• Root cause analysis needs tracking through all involved services
  • This must work at landscape level and thus needs service cooperation
• Change management and decommissioning are part of API landscape management
  • Change management may be informational only (for non-breaking changes)
  • Decommissioning allows services to announce their retirement

(22) API your APIs

• Expose design-time and runtime API information in the API
  • Design-time allows automation of API landscape overview
  • Runtime allows automation of API landscape status
• Follow robust extensibility principles [http://dret.typepad.com/dretblog/2016/04/robust-extensibility.html] for these API APIs
  • Meaningful Core: Start with a simple but useful scenario
  • Extension Points: Think about how scenarios might evolve
  • Processing Model: Be clear about how extensions are handled

(23) Webby API Design

(24) Emerging API Patterns

• Self-description for APIs is increasing
• Problem details [http://webconcepts.info/specs/IETF/RFC/7807] as a way how APIs expose error information
  • Enables generic error handling but also allows additional information
• Home documents [http://webconcepts.info/specs/IETF/I-D/nottingham-json-home] as a way how APIs provide starting pages
  • Enables harvesting of API start points but also allows additional information
• Healthcheck reports [http://webconcepts.info/specs/IETF/I-D/inadarei-api-health-check] as a way how APIs expose status information
  • Enables landscape-level status reports but also allows additional information

(26) Thanks! Questions?

• Slides online: dret.net/lectures/london-2018 [http://dret.net/lectures/london-2018]
• Slide sources: dret/lectures [http://github.com/dret/lectures/tree/master/london-2018] on GitHub [http://github.com/]
• Me: http://dret.net/netdret/ [http://dret.net/netdret/]
• Twitter: @dret [http://twitter.com/dret]