(3) @dret on Twitter/GitHub

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

(5) 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]

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

(8) APIs are Languages

• APIs in their current sense evolved from the original API
  • Local APIs originated as a way to build systems (i.e., one big thing)
  • Network APIs were invented decades ago but nobody found the silver bullet
  • Web APIs are a loose and evolving collection of principles and patterns
• Languages become necessary when coordination is required
  • Human language is a result of improving ecological fitness
  • Human written language is a result of new organizational challenges
• Same problems/approaches/answers like other language problems
  • Domain-only: Domains figure out their problems and their languages
  • Universal: Find the universal grammar and use it everywhere
  • Hybrid: Establish principles and patterns but avoid überformats

(9) APIs: Who's Talking?

• Languages both establish and cross domain boundaries
• System/ecosystem boundaries are blurry
  • System/ecosystem perspective is a question of perspective
• APIs provide a foundation for communications in an ecosystem
  • Internal: Value is in system changeability
  • External: Value is in system interoperability
• API discussions should always be aware of both perspectives
  • Separate internal/external API strategies are counter-productive

(10) APIs are a Pattern

(12) API Driver #1: Push

• Many environments change at increasing velocities
  • Economics change
  • Incentives change
  • Technologies change
• Organizations are pushed to better handle change
  • They have to become better at reacting to external changes
  • They have to become better at executing internal changes
  • They have to become better at embracing changing

(13) API Driver #2: Pull

• External: Participating in the API economy becomes increasingly beneficial
  • Interfacing with customers/partners becomes easier
  • The number of API-ready customers/partners keeps increasing
  • The network effect [https://en.wikipedia.org/wiki/Metcalfe%27s_law] guarantees for the trend to continue
• Internal: Being able to plan and execute changing quickly improves fitness
  • Traditionally, IT is perceived as sluggish and heavyweight
  • Increasingly, IT becomes the lube for the organizational machinery
  • Additionally, IT can allow completely new classes of business models

(14) API Driver #3: Follow

• Having an API strategy becomes increasingly important
  • Organizations have executed on this for a long time (Amazon API memo: 2002)
  • Organizations share experiences and tooling around API strategies
• Using APIs becomes less of an if and more of a how
  • Business pushes IT to make sure strategy can be executed quickly
  • IT can leverage others as justification and leaders

(15) Two Views of API Scope/Focus

• Internal: Using APIs to break up monolithic systems
  • Focus on systems/software engineering and better modularization
  • Turn a system into an ecosystem.
  • Use Private APIs as a way to reduce tight coupling
• External: Using APIs to build up ecosystems
  • Focus on distributed/decentralized systems and better connectivity
  • Enable an ecosystem by loosely coupling systems.
  • Use Public APIs as a way to (better) interface with partners/public
• Both views are complementary and mostly a difference in perspective

(16) One Management Lifecycle

(18) The Wonders of APIs

(19) Two Perspectives of API Scope/Focus

• Internal: Using APIs to break up monolithic systems
  • Focus on systems/software engineering and better modularization
  • Turn a system into an ecosystem.
• External: Using APIs to build up ecosystems
  • Focus on decentralized systems and better connectivity
  • Enable an ecosystem by loosely coupling systems.
• Both views are complementary and mostly a difference in perspective
  • The internal perspective tends to gravitate towards building a system
  • The external perspective tends to ignore the complexities of decentralization

(20) APIs Serve a Purpose

Do not try to find the right business model for your APIs; instead, try to find the right APIs for your business model.

Mehdi Medjaoui [http://www.apiacademy.co/team_member/mehdi-medjaoui/]: @medjawii [http://twitter.com/medjawii]

(22) The Web Works

• MSA is about service autonomy in service-oriented landscapes
  • Developer autonomy is the freedom to choose the best tools for the job
  • Operations autonomy means that every service is operated standalone
• MSA is also about effectiveness in autonomy-focused service-oriented landscapes
  • Rapid provisioning means that getting started is an easy task
  • Basic monitoring establishes visibility into service operations
  • Rapid deployment increases the velocity of service landscape evolution

(23) The Web, Industrialized

• MSA applies Web Architecture's loose coupling [http://dret.net/netdret/publications#pau09a] to the API space
  • Build services with no hidden dependencies
  • Choose the best tool for the job
  • Decouple service provisioning from delivery architecture
  • Monitor service state and usage
  • React quickly when customers or market demand change
  • Experiment ruthlessly and keep experimentation cost low
• MSA is all about being webby while minimizing the cost

(24) Microservices Cargo Cult

(25) Separating the What from the How

• Why do organizations use MSA and what are their goals?
• Microservices are a pattern for achieving API agility/velocity
  • Loosely coupled services to allow services to evolve independently
  • DevOps to allow services to emerge/evolve faster
  • Infrastructure augmentation for management and visibility of services
• Focus on the what instead of simply choosing a how
  • Many MSA advantages can be realized in non-MSA architectures
  • More architectural discipline may be required to realize long-term gains

(27) Transformation is a Process

• Always keep in mind why you are transforming
• Pick what to transform based on current/strategic needs
• Learn how to transform based on experience and feedback
• Never stop evolving!

(28) Thanks! Q&A

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