(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) Why Change IT?

• More changes, more opportunities, more threats → Digital Transformation [Why Digital Transformation? (1)]
• Modular designs are easier to change → APIs [Why APIs? (1)]
• Modular implementations are faster to change → Microservices [Why Microservices? (1)]

(24) The Platform Dilemma

• Platforms provide support but also create constraints
  • Support in the form of a foundation and shared services/infrastructure
  • Constraints in the form of removing certain design options
• Balancing support and constraints is not always done explicitly
  • Adding features is more immediately visible than removing options
  • Unavailable design options may constrain the design space dramatically
• Microservices for the first time in enterprise IT take a step back
  • Remove constraints to foster innovation and give teams more solution options
  • Add support mostly in an attempt to make the platform economically viable

(25) Shared Runtime for Services: ESB

• Platforms often are conceived as being actual infrastructure
  • Centralized components that provide capabilities and host services
  • They become convenient components where every infrastructure problem is solved
• Is the ESB platform pattern an inescapable vicious cycle?
  • What if every capability had to be an API-driven service itself?
  • What if the platform would focus on defining/providing APIs?
  • What if the platform is a set of shared ideas instead of shared artifacts?

(26) Principles/Protocols/Practices (P³): The Web Platform

• A set of shared principles, protocols, and practices
  • Principles govern the general architectural style (REST)
  • Protocols define the way in which components interact
  • Practices are design patterns for when/how to use certain protocols
• The Web is and always has been about microservices
  • Encapsulation and strict API-only interactions
  • Services can start/evolve/succeed/fail/disappear entirely on their own
  • Discovery is just another service
  • Description is part of a service itself
• Shared nothing architecture with no single point of contention

(27) ESB Platforms are Monoliths by Design

• Designed to provide shared tooling
• Tooling becomes the backdoor for coupling creep
• Resist the urge to provide an API platform
• Ignoring one of the two major API value propositions
  • APIs are valuable because they decouple service users and providers
  • APIs are valuable because they decouple service implementations

(28) Landscapes are Decentralized by Design

• Designed to use shared languages
• Communications/coupling can only happen through APIs
• Anything that needs to be shared must be openly communicated
• Satisfying the two major API value propositions
  • APIs are valuable because they decouple service users and providers
  • APIs are valuable because they decouple service implementations

(30) Microservices and the Web

• MSA replicates the most important success factors of the Web
  • Encapsulation of code, allowing polyglot implementations
  • Encapsulation of persistence, allowing polyglot storage
  • Encapsulation of models, making the API the only available model
• The only service dependency is through APIs
  • Works (mostly) well on the Web because of the uniform interface and HTML
  • Works (mostly) well on the service Web for well-designed APIs

(31) Jeff Bezos' Services Rant [https://gist.github.com/chitchcock/1281611]: The Rules

• Famous small set of SOA design rules
  • Teams must expose functionality through services
  • Communication happens only through service interfaces
  • There are no hard guidelines for service design
  • Internal/external service is a matter of policy, not one of design
• Going against the let's pick a platform spirit of old-school SOA

(32) Jeff Bezos' Services Rant: The Consequences [https://plus.google.com/+RipRowan/posts/eVeouesvaVX]

• With more freedom comes more responsibility
  • Monitoring and metrics are necessary for finding root causes
  • All APIs must be hardened against DoS attacks
  • Automated QA is necessary to really understand service health
  • Services must be documented and registered so that they can be discovered
  • Debugging becomes harder because of service dependencies
• Sophisticated tooling required to manage the new SOA landscape
• Much easier in today's technology landscape than 15 years ago

(33) Never Stop Evolving

• MSA is a style that should survive technologies
• Containerization will drive MSA adoption [https://www.youtube.com/watch?v=Wh4PpY0J9ZI]
  • A fully containerized service landscape needs MSA to function
  • Polyglot containers mean that language does not matter
  • Data encapsulation means isolated/opaque data management
• As persistence/languages/containers evolve, APIs remain the stable factor
  • The external perspective of MSA management is API management
  • The tools/languages/platforms for MSA service implementation evolve over time

(35) 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!

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