(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]
• While at UC Berkeley, working on Service Models for Open Government [http://dret.net/netdret/publications#wil09g]
• While at EMC, working on transforming software products into service platforms
• While at Siemens, working on using IoT to build WoT (APIs for Things)
• Joined CA [http://www.ca.com/]'s API Academy [http://www.apiacademy.co/] in May 2016 and now all about API Design and Strategy
• Active in the usual places such as Twitter [http://twitter.com/dret], GitHub [http://github.com/dret], flickr [https://www.flickr.com/photos/dret/], and my blog [http://dret.typepad.com/dretblog/]

(5) API Academy

• Global Team working on API Strategy and Design topics
  • Matt McLarty [http://www.apiacademy.co/team_member/matt-mclarty/] (Vancouver)
  • Mike Amundsen [http://www.apiacademy.co/team_member/mike-amundsen/] (Cincinnati)
  • Ronnie Mitra [http://www.apiacademy.co/team_member/ronnie-mitra/] (London)
  • Erik Wilde [http://www.apiacademy.co/team_member/erik-wilde/] (Zürich)
• Evangelizing ideas and technologies
  • Speaking (conferences, events)
  • Teaching (workshops, bootcamps)
  • Writing (blogs, articles, books)
  • Doing (side projects on API-related topics)
  • Standardizing (participating in specification work)

(6) 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 electronic version for free 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]

(7) Microservices are SOA!

(9) The Castle

(10) Bureaucracy

• Bureaucracy evolved for a reason
  • Clearly defined model of input and output of processing units
  • Implementation issues of the processing units are hidden
  • Processing units can scale because of encapsulation and statelessness
  • Processing steps can be easily composed while keeping steps separate
• Well-designed service landscapes have the exact same properties
  • Messaging models instead of paper forms
  • Message models are as shallow as possible
  • Stateless interactions allow for easy load balancing
  • Resource identifiers and hypermedia allow interlinked workflows

(11) APIs are Front and Center

• The only visibility into a service is its API
• APIs should avoid letting their implementation shine through
• The two main goals of an API are interaction and encapsulation
  • Interaction should be as simple/easy as possible through the API
  • Encapsulation ensures that the implementation is invisible
• Help developers to navigate the evolving landscape of interlinked APIs

(12) Be Superficial

• The only thing that matters is the Service Surface
  • Make the surface as shallow as possible to reduce coupling
  • Resist the temptation to expose your model just because you can
• Concepts must be well-defined but not necessarily deeply modeled

(13) Bimodal IT

(14) Kafka and Bimodal IT

• The Castle is not going anywhere anytime soon
  • Establishing rules of engagement make interactions well-defined
  • Natural transition possible (if required) using the Strangler Pattern
• Customers/consumers do not know how/where APIs are implemented
  • Establish uniform documentation/description/discovery strategy
  • Embrace diversity to cover old as well as new services
• APIs are connective tissue and protective insulation layers

(16) Discoverable Concepts

• There is not one single API documentation format
  • API style and tooling affect the choice of API documentation format
  • Microservices allow teams to pick their preferred format/tools
• Manage diversity by focusing on the surface
  • Webby API documentation should be able to clearly markup Web concepts
• Harvesting Web concepts should be relatively easy
  • Microformats/RDFa/Microdata or similar tooling might be helpful
  • Building becomes a natural part of API design and documentation

(17) Extend the Surface

• Web Concepts are different for different communities
• Adding concepts should be relatively easy
  • Adding individual values just requires adding specifications/services
  • Adding concepts introduces a new class of concepts
• What is the best way to add and manage and discover extensions?
  • A registry [http://tools.ietf.org/html/draft-wilde-registries] is one possible way of managing extensions
  • Web Concepts [http://webconcepts.info/concepts/] could be the initial registry contents

(19) The Dreaded Monolith

(20) Microservices: The Starting Point

(21) Microservices Over Time

(22) Decentralize Documentation/Discovery

• MS is all about making services more independent and self-contained
  • Documentation is under control and responsibility of service owners
  • Decentralized documentation means polyglot documentation
  • Discovery has to support polyglotism and decentralization
• Decentralized discovery is based on pulling/crawling diverse data
  1. Start by finding available description/documentation resources [https://tools.ietf.org/html/draft-wilde-service-link-rel]
  2. Process these based on supported description/documentation formats
  3. Increase support if required by the evolving ecosystem
  4. Provide discovery services based on the resulting service ecosystem snapshot
• Added benefit: Reality-based view on description/documentation/service ecosystem

(24) Data-Driven API Landscaping

• Keep track of API design and behavior and make it visible
  • Design instrumentation allows to keep track of service design
  • Run-time instrumentation allows to keep track of service behavior
• Understand the history, status, and direction of the API landscape
  • Avoid tight coupling between landscaping and service designs and behaviors
  • All tooling should be based on open (and extensible) standards

(25) Thanks! Q&A

• Me: http://dret.net/netdret/ [http://dret.net/netdret/]
• Slides online: dret.net/lectures/nordic-apis-2016/ [http://dret.net/lectures/nordic-apis-2016/]
• Slide sources: dret/lectures [http://github.com/dret/lectures/tree/master/nordic-apis-2016] on GitHub [http://github.com/]