Autonomous APIs

Slides used during my talk at API Conference Berlin 2018 https://apiconference.net/api-business-strategy/autonomous-apis/

Abstract:

The exponential growth of APIs, further accelerated by IoT, micro-services, and FaaS, brought many challenges both technical and economical. On the one hand, businesses are struggling with establishing successful API programs to connect with their customers. On the other side, engineering teams are facing out-of-the-scale complexity.

In this talk, we will explore the problems and shortcomings of current APIs, both with regards to the technical aspects and the API economy. We will discuss the possible solutions to these problems, and introduce Autonomous APIs.
In the second part, we will take a look at what Autonomous APIs are and how they can solve the problems for both businesses and engineering. We will introduce the classification of autonomous systems and take a peek at the building blocks of autonomous systems.

Transcript

1. goodapi.co AUTONOMOUS APIS Zdenek “Z” Nemec goodapi.co
2. goodapi.co I help businesses build APIs Zdenek “Z” Nemec @zdne zdne1
3. goodapi.co APIS: THE FIRST 30 YEARS CUSTOMER-SPECIFIC APIS one-to-one First Wave (2000) GENERIC APIS one-to-many Second Wave (2010) HARMONIZED APIS many-to-one, machine-to-machine Third Wave (2020) The Pattern 1990 2000 2010 2020
4. goodapi.co THE WAVES OF API TRANSFORMATION
5. goodapi.co goodapi.co CUSTOMER-SPECIFIC APIS First Wave
6. goodapi.co FIRST WAVE: ONE–TO–ONE Large organizations embracing IT (years 1990-2000s)
7. goodapi.co Primary Drivers Secondary Drivers Non-driver FIRST WAVE: ONE TO ONE ONE API consumed by ONE client
8. goodapi.co goodapi.co EVERY WAVE HAS ITS API ARCHITECTURE
9. goodapi.co SOAP, EDI, FTP & ESB CUSTOMER-SPECIFIC APIS FIRST WAVE ARCHITECTURE
10. goodapi.co FIRST WAVE COMPLEXITY FIRST-WAVE PROVIDERS FACING COMPLEXITY ISSUES FROM INCREASING NUMBER OF POINT TO POINT INTEGRATIONS AND/OR THE ESB SINGLE POINT OF FAILURE AND INCREASING DEPENDENCIES
11. goodapi.co NEW CONSUMERS FOUND THE FIRST-WAVE APIS TOO COMPLEX AND CUMBERSOME TO USE
12. goodapi.co THESE CUSTOMERS WERE OFTEN IGNORED, MISUNDERSTOOD AND UNDERSERVED BY INCUMBENTS
13. goodapi.co goodapi.co GENERIC APIS Second Wave
14. goodapi.co SECOND WAVE: ONE–TO–MANY Ubiquitous internet and software development (years 2005-2018+)
15. goodapi.co FIRST TO SECOND Two Groups of Customers–API Consumers CUSTOMER- SPECIFIC APIS GENERIC APIS one-to-many: many mid- or small- size customers one-to-one: few large established customers First Wave (2000) Second Wave (2010)
16. goodapi.co Primary Drivers Secondary Drivers Non-drivers SECOND WAVE: ONE TO MANY ONE API consumed by MANY clients
17. goodapi.co Fueled by the success, scalability and performance of the most successful API to date – Web SO-CALLED-REST & GRAPHQL SECOND WAVE (GENERIC APIS) SECOND WAVE ARCHITECTURE
18. goodapi.co THE (FORTUNE 500) WORLD STILL RUNS ON SOAP, EDI OR FTP, NOT REST …but the the third wave is already coming… However…
19. goodapi.co SECOND WAVE COMPLEXITY SECOND-WAVE PROVIDERS ARE FACING COMPLEXITY ISSUES FROM INCREASING NUMBER OF CLIENT INTEGRATIONS, NUMBER OF HOST AND CLIENT DEPLOYMENTS AND NUMBER OF API VERSIONS
20. goodapi.co NEW CONSUMERS FIND COMPLEX AND COSTLY TO INTEGRATE AND MAINTAIN THE INTEGRATIONS WITH MANY SECOND-WAVE APIS
21. goodapi.co THESE CUSTOMERS WERE OFTEN IGNORED, MISUNDERSTOOD AND UNDERSERVED BY INCUMBENTS
22. goodapi.co goodapi.co HARMONIZED APIS Third Wave
23. goodapi.co THIRD WAVE: MANY–TO–MANY Need for consuming many APIs, forming API Landscapes, Rise of IoT & AI (Year 2018+)
24. goodapi.co THERE IS TOO MANY APIS TO INTEGRATE WITH JUST ONE! B C D . . . e-shop IF I AM BUILDING AN E-SHOP DO I WANT TO INTEGRATE WITH 400 LOGISTICS PROVIDERS? THE NUMBER OF APIS IS GROWING STRONG
25. goodapi.co
26. goodapi.co
27. goodapi.co –Radek Novotny; CEO & founder MyStay “There are few integrators for hospitality APIs consolidating as many as 40 PMS but they are either not- duplex or slow in reactions” CHALLENGE: INTEGRATION WITH MANY PROPERTY MANAGEMENT SYSTEMS (PMS)
28. goodapi.co BUT 40+ PMS INTEGRATIONS ARE JUST ONE PART OF MYSTAY PROBLEMS. THE BIGGER ONE IS: HOW TO INTEGRATE WITH THOUSANDS OF “SMART HOSPITALITY” IOT DEVICES FROM DIFFERENT VENDORS AND IN DIFFERENT HOTEL CHAINS?
29. goodapi.co goodapi.co MULTIPLE DOMAINS The situation will get even worse with...
30. goodapi.co MANY APIS, CROSS-DOMAIN APIS Accommoda tion B Accommoda tion C Accommoda tion D Accommoda tion E API Consumer APIs Accommoda tion B Accommoda tion E
31. goodapi.co CROSS-DOMAIN Accommoda tion B Accommoda tion C Accommoda tion D Accommoda tion E Customer 3rd party
32. goodapi.co UNIVERSE OF CAPABILITIES This is what Amazon (Alexa skills), Google (Home skills) & VIV are doing… Database of knowledge and services with uniform interface
33. goodapi.co
34. goodapi.co THIRD WAVE Primary Drivers Secondary Drivers Non-drivers 1. Consuming more than one API 2. Cross-domain 3. Demanding reduction of complexity 4. Self-driving 5. Autonomous-decoupled from particular provider NEXT-GEN CUSTOMERS Partnership through discoverability Innovation driven by AI & IoT
35. goodapi.co UNIFORM INTERFACE, DECOUPLING, KNOWLEDGE SHARED AT RUNTIME, DECLARATIVE PROGRAMMING, AUTOMATION, AUTONOMY THIRD WAVE (AUTONOMOUS APIS) THIRD WAVE ARCHITECTURE
36. goodapi.co THE THIRD WAVE COMING… CUSTOMER-SPECIFIC APIS one-to-one: few large established customers First Wave (2000) GENERIC APIS one-to-many: many mid- or small- size customers Second Wave (2010) AUTONOMOUS APIS many-to-one & machine-to-machine: automatic, later autonomous APIs Third Wave (2020)
37. goodapi.co goodapi.co HOW ARE FIRST- AND SECOND- WAVE INCUMBENTS LOOSING THEIR CUSTOMERS
38. goodapi.co Incumbent Existing Customer Existing Customer Existing Customer FIRST WAVE First wave of API customers Point-to-point integrations one-to-one: few large established customers
39. goodapi.co Incumbent Existing Customer Existing Customer Existing Customer New Type of Customer Complex, legacy, point-to- point API interfaces difficult to use for new customers one(API)-to- many(consumers): many mid- or small- size customers SECOND WAVE Second wave of API customers
40. goodapi.co Incumbent Existing Customer Existing Customer Existing Customer Facilitator New Type of Customer Ignored at the start Second wave of API customers Facilitator - Disruptor A 3rd party between API customer and API provider. Unrecognized or ignored it is either an external provider or shadow IT. SECOND WAVE
41. goodapi.co Incumbent Existing Customer Existing Customer Existing Customer 3rd party New Type of Customer New Type of Customer New Type of Customer Second wave of API consumers SECOND WAVE
42. goodapi.co Incumbent Existing Customer Existing Customer Existing Customer 3rd party New Type of Customer New Type of Customer New Type of Customer FIRST WAVE CUSTOMERS MOVING TO 3RD PARTY
43. goodapi.co UNABLE TO ADAPT TO THE INCUMBENTS ARE LOOSING THEIR POSITIONS TO DISRUPTORS
44. goodapi.co Incumbent Existing Customer Existing Customer Existing Customer 3rd party New Type of Customer New Type of Customer New Type of Customer 2ND WAVE (GENERIC APIS) First wave customers moving to 3rd Party one-to-many: many mid- or small- size customers
45. goodapi.co Incumbent Existing Customer Existing Customer Existing Customer 3rd party New Type of Customer New Type of Customer New Type of Customer 3RD WAVE (HARMONIZED APIS) 3rd party providing integrations with many providers Incumbent Incumbent Incumbent Incumbent many-to-one & machine-to-machine: automatic, later autonomous APIs
46. goodapi.co THE FEAR OF BECOMING COMMODITY, LACK OF KNOWLEDGE LACK OF UNDERSTANDING AND INABILITY TO INNOVATE LEADS TO ISOLATION AND LEAVES INCUMBENTS ONCE AGAIN VULNERABLE TO THIRD PARTIES
47. goodapi.co IOT
48. goodapi.co Client Client Client Client Client Client HOSPITALITY Accommoda tion B Accommoda tion C Accommoda tion D Accommoda tion E
49. goodapi.co Accommoda tion B Accommoda tion C Accommoda tion D Accommoda tion E Existing Customer Existing Customer Existing Customer 3rd party New Type of Customer New Type of Customer New Type of Customer BANKING APIS Accelerated by PSD2
50. goodapi.co Accommoda tion B Accommoda tion C Accommoda tion D Accommoda tion E Existing Customer Existing Customer Existing Customer 3rd party New Type of Customer New Type of Customer New Type of Customer LOGISTICS Metapack integrates over 400 carriers Over 100 (!!!) 3rd Party vendors
51. goodapi.co Existing Customer Existing Customer 3rd party New Type of Customer New Type of Customer New Type of Customer Provider Provider Provider UNIFORM INTERFACE Uniform Interface to incumbents B C D e-shop 3rd party
52. goodapi.co THERE IS TOO MANY APIS TO INTEGRATE WITH JUST ONE! B C D e-shop B C D e-shop 3rd party VS. IF I AM BUILDING AN E-SHOP DO I WANT TO INTEGRATE WITH 400 LOGISTICS PROVIDERS? THE NUMBER OF APIS IS GROWING STRONG
53. goodapi.co Website A Client Client Client Client Client Client ARE YOUR CUSTOMERS REALLY YOURS? Website B Website C Website D Website E
54. goodapi.co COMPLEXITY
55. goodapi.co COMPLEXITY OF DISTRIBUTED COMPUTING SYSTEMS Task-structure Complexity How difficult it is understand how to perform a task in a distributed system Unpredictability How difficult is to predict effect of an action in distributed system, amount of entropy Size Complexity Size of the system implies cognitive complexity, large number of concepts and the knowledge required Chaotic Complexity Small variations in a certain part of the system can have large effects on overall system behavior Algorithmic Complexity Both traditional algorithm complexity in the term of time and space and cognitive complexity of understanding algorithm
56. goodapi.co COMPLEXITY EXERCISE 5. # of client deployments Different lifecycle of the deployment • Desktop app • Web app • Mobile app • Backend • Scripts / CLI 3. # of API implementations / deployments • Language • Provider • Protocol • API architectural style 1. # of API (designs) for a domain 2. # of versions of one API stripe.com API has over 70 versions 4. # of client integrations Single consumer / API key
57. goodapi.co API Designs x Versions x Deployment Hosts x Clients x Client Deployments IF THE NUMBER OF IS HIGHER THAN TWO You are likely to face complexity using, maintaining and evolving your API 130 APIs 3 x 6 (environments x availability zones) 70 versions 1500 integrations own deployments: 3 x 6 on-premise deployments: 1000 apps: 3 000 000 IoT: ????? = 1,10565×10^9
58. goodapi.co COST OF CHANGE 6,1% chance of breaking change every day (java library)
59. goodapi.co SOLUTIONS
60. goodapi.co 1. Hire more people 2. Standardization 3. Apply massive automation 4. Start building distributed systems differently– change the approach–autonomy of the components in API landscape SOLUTIONS TO COMPLEXITY
61. goodapi.co ROLE OF HUMANS IN APIS 1. Hire More People Mechanical turks, eyeballing documentation for changes in design, fixing clients and implementations accordingly.
62. goodapi.co WHAT WE THINK AN API IS MACHINE EXPOSES INTERFACE ANOTHER MACHINE LEARNS & USES INTERFACE MACHINES MEET OVER THE NETWORK discovery
63. goodapi.co REALITY MACHINE EXPOSES INTERFACE ANOTHER HUMAN READS DOCUMENTATION HUMAN WRITES DOCUMENTATION ANOTHER MACHINE IS TAUGHT TO USE INTERFACE HUMANS MEET discovery ! !
64. goodapi.co REALITY ! HUMANS INSIDE VS. • time and money spent • not scaling • chance of misinterpretation • error-prone
65. goodapi.co API DESIGN, LIFECYCLE, DEVELOPMENT STANDARDIZATION 2. Standardization
66. API IS BY- PRODUCT API DOCUMENTATION GENERATED FROM CODE API FIRST API TREATED AS PRODUCT API CONSISTENCY API MATURITY
67. goodapi.co DESIGN- CONSISTENCY API guidelines & style check automation
68. goodapi.co AUTOMATED, CONTRACT-DRIVEN API LIFECYCLE 3. Massive Automation
69. goodapi.co KEEPING THINGS IN SYNC IS HARD INTERFACE ACTUALLY EXPOSED INTERFACE DOCUMENTED INTERFACED USED are they the same? are they the same? are they the same?
70. goodapi.co https://goodapi.co/api-lifecycle
71. goodapi.co TOOLS ARE OUR LIMITS
72. goodapi.co TOOLS ARE OUR LIMITS • Existing investments (tools, infrastructure & processes) • Bloated API Management Tools • Missing automation • Lifecycle orchestration • Limiting API description formats • Data modeling from the past • Missing tooling for structured data
73. goodapi.co Components autonomy in an API Landscape reduces the complexity, enables scaling, and promotes the service commoditization. Autonomy is the solution to the difficulty of managing many components centrally. 4. Change the approach AUTONOMOUS APIS “Autonomy: freedom from external control or influence; independence; sovereignty in making decisions and changes.” –New Oxford American Dictionary
74. goodapi.co API LANDSCAPES APIs are no longer in silos
75. goodapi.co MANY APIS, CROSS-DOMAIN APIS Accommoda tion B Accommoda tion C Accommoda tion D Accommoda tion E API Consumer APIs Accommoda tion B Accommoda tion E
76. goodapi.co THE GOAL IS TO NAVIGATE SAFELY IN API LANDSCAPE Navigation through autonomic units Countries, Regions, Cities, City Quarters are autonomous regions but when you are driving from A to B you need to navigate through their roads A B Design-time & Runtime Navigation You need both to follow a map and traffic signs to navigate effectively
77. goodapi.co 5 LEVELS OF AUTONOMY
78. goodapi.co –Autonomous Client “The level of autonomy is the ability to safely navigate in the API landscape (where the only constraints are time and price)”
79. goodapi.co LEVEL 0 • Tightly coupled components • No semantics, interface or lifecycle data • Pros • Time to delivery for point to point integrations when complexity is low • Cons • Everything breaks when something changes • Not scaling with growing complexity Brittle System
80. goodapi.co LEVEL 1 • Tightly coupled components • Interface metadata available • Human only-semantics metadata available • No lifecycle metadata (is the documentation documenting the interface implementation?) • Pros • Possible API productization • Reusability • Cons • Lock on changes, unable to evolve Documented Brittle System
81. goodapi.co LEVEL 2 • Mostly tightly coupled components • Metadata are verified, valid and reliable • Metadata are human or machine readable • Advertisement of the interface, semantics and lifecycle metadata • Client subscription to future changes • Pros • Explicit understanding of price and risk of making changes in the API landscape • Quality Control • Cons • Advanced mindset change involving many people • Cultural denial, hard to get buy-in Automated System
82. goodapi.co LEVEL 3 • Decoupled components • Evolvability of the components in their respective environments • Share understanding-metadata at RUNTIME • Pros • Reducing price and risk of making changes (by design) • Cons • Difficult taking everything into account, prone to chaotic & size complexity Decoupled Automated System
83. goodapi.co LEVEL 4 • Self driving clients • Autonomy of the components • Leveraging learned data from simulation for infrastructure • Pros • Higher level of abstraction • Uniform interface • Cons • Cognitive (Algorithmic) Complexity • Demanding on computational power • Higher level of abstraction Autonomous System
84. goodapi.co LEVELS OF AUTONOMY Brittle System Documented Brittle System Automated System Decoupled Automated System Autonomous System Autonomy Autonomous APIs 0 1 2 3 4
85. goodapi.co BUILDING BLOCKS OF AUTONOMOUS APIS
86. goodapi.co BUILDING BLOCKS OF AUTONOMOUS APIS • Uniform Interface • Decoupled components • API understanding shared at run-time Level 4 Autonomous System Level 3 Decoupled Automated System • Client components programmed declaratively - self driving clients • Machine understanding • API Landscape understanding shared at run-time 4 3
87. goodapi.co goodapi.co Early four-engine jets required flight engineers. Later four-engine jets were designed with sufficient automation to eliminate the position. 747 FLIGHT ENGINEERS ...this will also happen in the world of APIs.
88. goodapi.co Level 3 Decoupled Automated System 3
89. goodapi.co UNIFORM INTERFACE decoupled automated system building block 1/3
90. goodapi.co ENGINEERING PRINCIPLE OF GENERALITY 1957 2018
91. goodapi.co A CONSISTENT, PREDICTABLE WAY TO QUERY DATA AND EXERCISE ACTIONS REGARDLESS OF THE SERVICE PROVIDER
92. goodapi.co Existing Customer Existing Customer 3rd party New Type of Customer New Type of Customer New Type of Customer Provider Provider Provider UNIFORM INTERFACE Uniform Interface to incumbents B C D e-shop 3rd party
93. goodapi.co UNIFORM INTERFACE HAS MANY BENEFITS • Simplifies architecture • Improves visibility of interactions • Decouple components, enables evolution • Improves interoperability, reduces cost of integration • Reduces costs and time to market • Enables autonomous service discovery • ENABLES FOR GENERAL AI • Automatic clients • Autonomous clients
94. goodapi.co CROSS-DOMAIN UNIFORM INTERFACE Accommoda tion B Accommoda tion C Accommoda tion D Accommoda tion E Customer Customer Customer 3rd party Customer Customer Customer Uniform Interface
95. goodapi.co PATH TO UNIFORM INTERFACE 1. Apply Modern Architectural Styles (REST) and Linked Data (JSON-LD)
 
 2. Leave it up to 3rd Party Vendors (Amazon, Google..) to become the intermediaries to the universe
96. goodapi.co Do you want to provide an uniform interface or leave it to third-party vendor to do it? BUILDING YOUR NEXT API Client Client Client Client Client Client Provider Provider Provider Client Client Client Linked Data & Architecural Style Client Client Client Provider Provider Provider - OR -
97. goodapi.co DECOUPLED COMPONENTS decoupled automated system building block 2/3
98. goodapi.co A COMPONENT DOES NOT DUPLICATE OR RELY ON ANY OTHER COMPONENT INTERNAL LOGIC NEITHER IT RELIES ON ANY OTHER COMPONENT INFORMATION SHARED AHEAD OF TIME
99. goodapi.co API TASKS IS TO ABSTRACT AWAY THE INTERNALS OF SERVICE COMPONENT
100. goodapi.co DECOUPLED COMPONENTS Enable parts to evolve independently Abstraction Layer Comp-A Comp-B no welding of components
101. goodapi.co DEGRADED EFFICIENCY UI Transformation Comp-A Comp-B Transformation The Tradeoff of Decoupled components and Uniform interface
102. goodapi.co API UNDERSTANDING SHARED AT RUN-TIME decoupled automated system building block 3/3
103. goodapi.co API UNDERSTANDING SHARED AT RUN-TIME • Available HATEOAS state transitions • HAL, Siren, RESTful JSON • Non-authoritative parameter validations • JSON Schema, CoD • API Description - map • OpenAPI Specification, API Blueprint … • GraphQL Schema
104. goodapi.co BUILDING BLOCKS OF AUTONOMOUS APIS • Uniform Interface • Decoupled components • API understanding shared at run-time Level 3 Decoupled Automated System 3
105. goodapi.co Level 4 Autonomous System 4
106. goodapi.co DECLARATIVE CLIENT PROGRAMMING autonomous system building block 1/3
107. goodapi.co DECLARATIVE PROGRAMMING // HTTP Request GET /v1/balance HTTP/1.1 Host: api.stripe.com Authorization: Basic c2tfdGVzdF9CUW9raWtKT3ZCaUkySGxXZ0g0b2xmUTI // Imperative, hard-coded fetch(‘http://api.stripe.com/v1/balance‘, { ‘Authorization': 'Basic ' + base64.encode(username + ":" + password) } ).then.. // Declarative, decoupled if (hasAffordance(‘retrieve-balance’) { exerciseAffordance(‘retrieve-balance’).then.. }
108. goodapi.co MACHINE UNDERSTANDING autonomous system building block 2/3
109. goodapi.co API SEMANTIC LAYERS Protocol Message Application HTTP Protocol Semantics HAL Semantics Application Domain Semantics (e.g. Hospitality domain)
110. goodapi.co DATA MODELS & VOCABULARIES, ONTOLOGIES
111. goodapi.co CANONICAL DATA MODEL DOESN’T WORK goodapi.co
112. goodapi.co CANONICAL DATA MODEL IS ANTI-PATTERN IN THE WORLD OF MICROSERVICES & FAAS Use concern separation, bounded context, DDD techniques
113. goodapi.co DOMAIN-DRIVEN DESIGN Divide and conquer complexity by bounded context and context mapping images from Domain-Driven-Distilled
114. goodapi.co CONTEXT MAPPING images from Domain-Driven-Distilled
115. goodapi.co LINKED DATA - SEMANTICS FOR HUMANS & MACHINES
116. goodapi.co –Autonomous Client “I am looking for a person, but I see an user, should I treat it as person?”
117. goodapi.co SHARED VOCABULARIES
118. goodapi.co https://supermodel.io
119. goodapi.co PROGRAM FOR VOCABULARY NOT DATA STRUCTURE
120. goodapi.co CLIENT EXAMPLE // Programming for data structure if (todo.title) { display todo.title } // Programming for vocabulary if (todo.has(‘schemaorg:title’)) { display todo(‘schemaorg:title’) }
121. goodapi.co DISCOVERABLE BY MACHINES autonomous system building block 3/3
122. goodapi.co • Rapid API • Any API • APIS.json • Hitch HQ (acquired) • GraphQL Hub • … YAHOOS OF API WORLD • Internal Developer Portals • API Repositories (Apiary, SwaggerHub) Human-only, hand picked GLOBAL COMPANY-WIDE
123. goodapi.co • Netflix Zulu / Eureka • Apache / Kafka / Zookeper • Hashicorp / Consul • Linkerd MICROSERVICE DISCOVERY NO SEMANTICS METADATA DISCOVERY SERVICES
124. goodapi.co BUT THESE ARE NOT ENOUGH WE NEED PUBLISH-SUBSCRIBE MODEL FOR MACHINE-READABLE SEMANTICS, INTERFACE AND LIFECYCLE METADATA
125. goodapi.co AUTONOMOUS SERVICE DISCOVERY “Get me a service that knows weather in Paris.” “Get me a service that can fulfill the parcel logistics of 6 pallets from Prague to Paris.” “Get me a service that can play every movies by the director of movie Avatar.”
126. goodapi.co SERVICE DISCOVERY & DECLARATIVE CLIENT PROGRAMMING // Using a terms from schema.org dictionary, // find services that offers WeatherForecast. services = apiLandscape.find(WeatherForecast, { vocabulary: http:// schema.org}) // Query a service for WeatherForecast at GeoCoordinates. forecast = service.retrieve(WeatherForecast, { GeoCoordinates: … }) // Display Temperature display forecast(Temperature)
127. goodapi.co WHOLESALE PRESENCE & COMMODITIZATION Look for a service that has gs1:Offer where gs1:itemOffered gs1:gpcCategoryCode is MILK
128. goodapi.co apiLandscape.do(“Refill paper A4 100pcs in the printer on the 2nd floor”, “$10”, “24h”) => false => Promise NLP, DISCOVERY AND DECLARATIVE PROGRAMMING
129. goodapi.co BUILDING BLOCKS OF AUTONOMOUS APIS Level 4 Autonomous System 4 • Client components programmed declaratively - self driving clients • Machine understanding • API Landscape understanding shared at run-time
130. goodapi.co ATTACKING THE COMPLEXITY WITH AUTONOMY
131. goodapi.co ATTACKING THE COMPLEXITY WITH AUTONOMY Self-driving Clients Clients can self- navigate the API landscape, perform self- configuration, self- repair, self- optimization and make choices at various decisions points automatically High-level, declarative programming Reducing the cognitive algorithmic complexity, decoupling from components implementation, programming for domain, not service Automated, contract-driven API lifecycle Handling API provider complexity by keeping, versions, implementations and deployments in check Hierarchical and context-bound knowledge Divide and conquer size complexity with domain definitions and bounded contexts. Reusable representation of domain knowledge– ontologies– published language
132. goodapi.co WHAT WOULD MYSTAY DO? • Define Hospitality Domain • Define Hotel Room subdomain • “Train" MyStay Mobile app for the subdomain 
 
 if (room.roomService.available)
 display room.roomService.offer
 
 if (room.ac.available)
 display acControls
 • Deploy mobile clients • Provide IoT integration components-hubs for hotels
133. goodapi.co GOOD API INDEPENDENT API CONSULTING
134. IMAGES BY UNSPLASH.COM
135. goodapi.co BACKUP
136. goodapi.co COMPLEXITY OF DISTRIBUTED COMPUTING SYSTEMS https://www.ideals.illinois.edu/handle/2142/11022
137. goodapi.co AUTONOMOUS APIS • Self-driving clients • Navigation in landscape • Self-configuration • Resilience & Self-repair • Self-optimization • Self-decision making • High-level, declarative programming of the clients • Hierarchical and context-bound knowledge • Automated, contract driven API lifecycle
138. goodapi.co COMPLEXITY OF DISTRIBUTED COMPUTING SYSTEMS • How understandable a system is • How difficult it is to perform tasks in the system • Business tasks • Maintenance tasks • Change tasks (cost of making changes) • High complexity • High costs • High and reaction times • Low performance • High mental and cognitive effort to navigate and use • Fault-prone • Prevent evolution
139. goodapi.co THE NUMBER OF CLIENTS BROUGHT PROBLEMS WITH COMMUNICATING API DESIGN CHANGE, REACTING TO IT AND EVOLVING APIS