(5) SOA as a Bad Word

• Web Services have surprisingly little to do with the Web
  • Using XML as the first Internet/Web-scale structured data format
  • Ignoring everything else the Web as a service ecosystem could have taught
• SOAPy SOA has some fundamental design problems
  • Using system architecture instead of ecosystem architecture
  • Sacrificing evolution for RPC and code generation
  • Sacrificing decentralization for distribution
• The REST community [http://ws-rest.org/] set back and watched from a distance
  • Let's wait and see if/when Web Architecture is needed

(6) Microservice Architecture Focus

• Microservices are SOA based on Agile CD with DevOps processes [http://www.infoworld.com/article/3075880/application-development/microservice-architecture-is-agile-software-architecture.html]
• Speed and Safety at Scale in Harmony
  • Speed: The Speed of change of which a solution can evolve
  • Safety: The Safety of changes so that Speed doesn't kill you
  • Scale: Scaling the number of services and the capacity of a solution
  • Harmony: Have the freedom to balance Speed and Safety
• Focusing on addressing the SOAPy SOA [SOA as a Bad Word (1)] pain points
• De-focusing the question of how to manage the MSA landscape

(7) MS and the API Landscape

(8) Explaining the MS API Landscape

• MS and exposed APIs can be different
• APIM should be able to handle internal and exposed APIs
• What's internal and exposed can be a contextual question
• External API users might want to consume more than one set of APIs
• Exposing the landscape or an API gateway are two possible choices
  • Exposing the landscape exposes its diversity
  • Gateways can be centralized or become part of the MS fabric (e.g., a container)

(9) Scenario: Internet of Things

(10) Microservices Blind Spots

• The current focus has a few blind spots
  • How to find MS if an ecosystem grows beyond yell across cubicles size
  • How to manage the MS landscape once an MS ecosystem is developing
  • How design/evolve MS so that the landscape is robust and flexible
• An understandable reaction to SOAPy SOA's [SOA as a Bad Word (1)] top-down approach
  • It's important to focus on the central question: How are services created and implemented?
  • Not ignoring the questions of landscaping reduces the chances of MS hangover
• The Web can teach us some lessons about how to do some of these things
  • After all, the Web is the ultimate global-scale service landscape

(12) The Dreaded Monolith

(13) Microservices: The Starting Point

(14) Microservices Over Time

(15) Old School Discovery

• SOAP's answer to service discovery was UDDI
  • The biggest failure of the SOAP Web Services stack
  • Allowing only one specific kind of service design
  • Focusing on the function signature as a service's main description
• Building directories from carefully described and categorized entries
  • Feels like the Yahoo! of service discovery: The one true model approach
• What does a Google of Service Discovery look like?
  • Starting from services, find available description/documentation resources [https://tools.ietf.org/html/draft-wilde-service-link-rel]
  • Index description/documentation resources for subsequent discovery
  • Add support for additional description/documentation formats as required

(16) Decentralize Discovery

• MS is all about making services more independent and self-contained
  • Discovery should follow the same pattern: Avoid centralization, be polyglot
• 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

(18) Autonomy vs. Robustness

• MSA emphasizes independence and autonomy of teams
  • Allowing teams to design/implement/deploy autonomously increases speed
  • With no oversight at all the cost may add up on the consumer side
  • Finding a harmonious balance between autonomy and guidelines is key
• There are two critical sides to the evolution part
  1. When services change [Design for Service Evolution (1)], do consumers need to be aware of the changes?
  2. When the landscape changes [Design for Landscape Evolution (1)], do consumers need to discover the new services?

(19) Design for Service Evolution

• Services are designed with a certain goal and certain options
  • The goal is to satisfy the current requirements for a useful service
  • The options are based on assumptions on how the service might change
• Service design is a balance between simplicity and flexibility
• Building robust and extensible services [http://dret.typepad.com/dretblog/2016/04/robust-extensibility.html] is based on three factors
  • Meaningful and stable core: The service core must remain stable over time
  • Extension model: There are well-defined ways how the service core may evolve
  • Processing model: It is well-defined how clients have to process extensions

(20) Design for Landscape Evolution

• Application flow should be guided by discovered controls
  • A dynamic service landscape needs a dynamic way of discovering services
  • Hypermedia is a proven way how controls can be served dynamically
• Hypermedia is a good way for supporting service choreography
  • Microservice usage may change over time as the landscape evolves
  • Choreography exposes ways in which various services are combined to achieve a goal
• If nobody links to some microservices, these will disappear over time
  • Usage and linkage combined provide useful analysis data

(21) The Three V's of MSA

• Volume of available services: Scale [Scale (1)]
  • How big is the MS landscape and can I get an overview of what's around?
• Variety of service designs and interfaces: Diversity [Diversity (1)]
  • As a creator or consumer, how do I deal with different service designs?
• Velocity of service landscape evolution: Decentralization [Decentralization (1)]
  • As the landscape evolves, how stable are services and their designs?

(22) Scale

• Different environments have different ideas of MS scale
  • Small projects may have a handful of services
  • Large MS adopters may have several hundred services
• Exposed APIs and microservices combined mean a bigger API inventory
• Using any form of discovery may not be necessary from the start
  • Consider the possibility when starting the MSA effort
  • Having a plan helps teams to be aware of the need later on

(23) Diversity

• Not all services use the same technical foundations
  • Different communications mechanisms
  • Different metamodels for data structures
  • Different models for representing application concepts
  • In a Web context, these are concepts such as HTTP headers [https://github.com/dret/sedola/blob/master/MD/headers.md], media types [https://github.com/dret/sedola/blob/master/MD/mediatypes.md], and link relations [https://github.com/dret/sedola/blob/master/MD/linkrels.md]
• Handling diversity can be challenging because of different design universes
  • Depending on choice, similar concepts/models may be represented differently
  • Introducing a generalized abstraction layer is unlikely to be helpful
• Discovering documentation [Decentralize Discovery (1)] will allow you a better overview of your ecosystem
  • A reality-based overview of the technologies used in your landscape
  • A possible starting point or guideline for getting MSA teams started

(24) Decentralization

• Decentralization means no single point of control
• Decentralization means no automatic top-down visibility
  • API gateways are one way of improving visibility (and control)
  • Instrumenting the connective fabric is another way out of this
  • But this already introduces constraints for MSA design
• Complete and uncontrolled decentralization is an ideal
  • Observe how the MSA landscape develops
  • Identify pain points from the design and operational point of view
  • Identify popular patterns so that teams have a starting point
  • Convincing teams instead of mandatory guidelines

(26) Web Architecture Matters

• The line between system and ecosystem architecture is blurry
  • Ecosystems emphasize decentralization and loose coupling
  • Systems allow efficiencies by coupling things more tightly
• MSA is about the delicate balance of speed and safety
  • Anything goes may lead to a highly diverse ecosystem
  • Teams are likely to try to do the right thing
  • Demonstrating utility is a great way to promote MS design patterns

(27) Thanks!

• Me: http://dret.net/netdret/ [http://dret.net/netdret/], @dret [http://twitter.com/dret], and my blog [http://dret.typepad.com/dretblog/]
• Slides online: dret.net/lectures/api360-2016-nyc/ [http://dret.net/lectures/api360-2016-nyc/]
• Slide sources: dret/lectures [http://github.com/dret/lectures/tree/master/api360-2016-nyc] on GitHub [http://github.com/]