(4) Motivation #1: Breaking up the Monolith

(5) Motivation #2: Market Participation and Innovation

(6) 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

(7) There is no "Microservice API"

(9) 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

(10) 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

(11) 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

(12) 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

(13) 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

(14) 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

(15) 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

(17) 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

(18) Webby API Design

(19) 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

(21) What is an API?

• An API is a product
  • APIs are created and designed and developed
  • APIs have typical product lifecycles
• An API provides access to a capability
  • The API is not the interesting thing
  • The value is in the functionality of the API
• An API is a language
  • API users utilize API functionality by accessing the API
  • Using APIs is a conversation between service providers and consumers

(22) API Design

• APIs need to be designed just like any other product
  • Design starts with an architectural style and associated patterns
  • The style sets the framework but leaves a lot of freedom
  • Some design elements can be reused from existing APIs
  • Some design elements have to be created for the new API
• Design works best when it reuses familiar interface concepts
  • For UI design this allows end users to make educated guesses for better UX
  • For API design the same concept of familiarity is helpful for DX

(23) Interface Design

(24) Continuous Architecture

(26) SOAP: The Dark Age

• API design was practiced relatively little
  • Developers exposed implementation internals as Web services
  • Many APIs were exposed from a shared monolithic codebase
• SOAPy SOA promised webby nirvana without delivering
  • The main failure was the lack of focus on loosely coupled implementation
  • Evolution needs ecosystems where individuals can flourish or wane

(27) Microservices: Enlightenment

• The first time enterprise IT gets the Web
  • Decouple implementations for speed and agility at scale
  • Embrace diversity so that teams can focus on solving problems
• What do microservices mean for scale and longevity?
  • Design decisions need context for the best possible products
  • Designing into the void never is the best strategy

(28) The Middle Ground: Guide and Help

• Create Design Guidelines [http://apistylebook.com/design/guidelines/] that teams can use
  • Ideally based on existing practice
  • Ideally continuously changed based on the evolving landscape
• Writing as a form of communication
  • Writing guidelines forces teams to talk about design practices
  • Reading guidelines allows teams to understand the current practice

(29) Language and Design and Culture

• Culture emerges as a set of shared principles and patterns
  • Culture cannot be created from the top-down
  • Culture can be observed and nudged over time
• Design culture for APIs uses shared language building blocks
  • Documenting what APIs and teams are using
  • Helping teams in the API design efforts
• Documenting API design culture is a continuous process
  • Feedback cycle based on practice and design guidance

(31) Platforms Need Evolution

• MSA decouples implementations for improved velocity
• MSA needs a platform that teams can build on
• Build extensibility and openness into the platform
• MSA platforms never stop evolving

(32) Thanks! Q&A

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