SlideShare a Scribd company logo

A Journey from API Versioning to Canary Release | Nordic APIs Platform Summit 2017

Download as PPTX, PDF
••
Patrice Krakow, profile picture
Patrice Krakow

The document discusses the importance of API versioning and the canary release strategy as a means to mitigate risks associated with introducing new software versions by gradually rolling them out. It describes various terminologies related to APIs, including definitions of endpoints, specifications, and the significance of semantic versioning for both API specifications and services. The canary release technique is likened to a safety measure used in mining, serving as an early warning for potential issues before impacting the broader user base.

Software
Related topics:
Insights on Software Development
1 of 134
Downloaded 34 times
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
A Journey from API Versioning to Canary Release Patrice Krakow | ING | Lead Architect | APIs Nordic APIs – The 2017 Platform Summit Stockholm | 2017, October 10 (2.2.1)
We want to be a tech company with a banking license! Ralph Hamers, CEO and chairman Executive Board ING Group source: https://www.ing.com/Newsroom/All-news/We-want-to-be-a-tech-company-with-a-banking-license-Ralph-Hamers.htm
Patrice Krakow 3 • Sep 2016 – Present • ING | Lead Architect of the API Platform • Jul 2012 – Aug 2016 • ING Belgium | SOA Architect • Jun 2012 – Apr 2013 • Eligible | Co-founder • Aug 2001 – Jun 2012 • SCA Package (DS Smith) | System Integration Coordinator … • Sep 1990 – Jun 1995 • University of Liège | Master of Physics
A Journey from API Versioning to Canary Release 4
Why? 5
Why? 6
Why? 7 API Providers API Consumers
Why? 8 API Providers API Consumers want to change their APIs as soon as they have a new brilliant idea want the APIs they are using to stay stable as long as they are not interested by the new brilliant ideas of the API Providers!
Why? 9 API Providers API Consumers What!? want to change their APIs as soon as they have a new brilliant idea want the APIs they are using to stay stable as long as they are not interested by the new brilliant ideas of the API Providers!
Why? 10 API Providers API Consumers API Versionin g want to change their APIs as soon as they have a new brilliant idea want the APIs they are using to stay stable as long as they are not interested by the new brilliant ideas of the API Providers!
Why? 11 API Providers API Consumers want to change their APIs as soon as they have a new brilliant idea want the APIs they are using to stay stable as long as they are not interested by the new brilliant ideas of the API Providers! DON’ T
Why? 12 API Providers API Consumers want to change their APIs as soon as they have a new brilliant idea want the APIs they are using to stay stable as long as they are not interested by the new brilliant ideas of the API Providers!
Why? 13 API Providers API Consumers want to change their APIs as soon as they have a new brilliant idea want the APIs they are using to stay stable as long as they are not interested by the new brilliant ideas of the API Providers!
The canary release is a technique to reduce the risk of introducing a new software version in production by slowly rolling out the change to a small subset of users before making it available to everybody. Canary Release 14
The canary release is a technique to reduce the risk of introducing a new software version in production by slowly rolling out the change to a small subset of users before making it available to everybody. The name for this technique originates from miners who would carry a canary in a cage down the coal mines. If toxic gases leaked into the mine, it would kill the canary before killing the miners. A canary release provides a similar form of early warning for potential problems before impacting your user base. Canary Release 15
Canary Release 16 Application~1 Router Instance of Service~1 v1.0.0
Canary Release 17 Application~1 Router Instance of Service~1 v1.1.0 Instance of Service~1 v1.0.0
Canary Release 18 Application~1 Router Instance of Service~1 v1.1.0 Instance of Service~1 v1.0.0 100% 10% 90%
Canary Release 19 Application~1 Router Instance of Service~1 v1.1.0 Instance of Service~1 v1.0.0 100% 50% 50%
Canary Release 20 Application~1 Router Instance of Service~1 v1.1.0 Instance of Service~1 v1.0.0 100% 90% 10%
Canary Release 21 Application~1 Router Instance of Service~1 v1.1.0 Instance of Service~1 v1.0.0 100% 100%
Meta-Model and Terminology for APIs 22
• API is a set of API endpoints. • API endpoint is an interface; when using HTTP, an API endpoint is identified by the triplet {HTTP method, host, URL Path Template}. • API specification is a precise and comprehensive documentation of the API endpoints part of the API. We use the OpenAPI/Swagger standard. • Service is a piece of software, a piece of code, to be run in an out-of- process component, so it cannot be a library! • Service version is a version of a service. • Instance is a running process of a service version. As the running processes are addressable on TCP/IP network, you can call them via a socket identified by an IP address and a TCP port. 23 Meta-Model and Terminology for APIs Service API
• API is a set of API endpoints. • API endpoint is an interface; when using HTTP, an API endpoint is identified by the triplet {HTTP method, host, URL Path Template}. • API specification is a precise and comprehensive documentation of the API endpoints part of the API. We use the OpenAPI/Swagger standard. • Service is a piece of software, a piece of code, to be run in an out-of- process component, so it cannot be a library! • Service version is a version of a service. • Instance is a running process of a service version. As the running processes are addressable on TCP/IP network, you can call them via a socket identified by an IP address and a TCP port. 24 Meta-Model and Terminology for APIs Service API
• API is a set of API endpoints. • API endpoint is an interface; when using HTTP, an API endpoint is identified by the triplet {HTTP method, host, URL Path Template}. • API specification is a precise and comprehensive documentation of the API endpoints part of the API. We use the OpenAPI/Swagger standard. • Service is a piece of software, a piece of code, to be run in an out-of- process component, so it cannot be a library! • Service version is a version of a service. • Instance is a running process of a service version. As the running processes are addressable on TCP/IP network, you can call them via a socket identified by an IP address and a TCP port. 25 Meta-Model and Terminology for APIs API endpoint Service API
• API is a set of API endpoints that share a common purpose. • API endpoint is an interface; when using HTTP, an API endpoint is identified by the triplet {HTTP method, host, URL Path Template}. • API specification is a precise and comprehensive documentation of the API endpoints part of the API. We use the OpenAPI/Swagger standard. • Service is a piece of software, a piece of code, to be run in an out-of- process component, so it cannot be a library! • Service version is a version of a service. • Instance is a running process of a service version. As the running processes are addressable on TCP/IP network, you can call them via a socket identified by an IP address and a TCP port. 26 Meta-Model and Terminology for APIs API endpoint Service API
• API is a set of API endpoints that share a common purpose. • API endpoint is an interface; when using HTTP, an API endpoint is identified by the triplet {HTTP method, host, URL Path Template}. • API specification is a precise and comprehensive documentation of the API endpoints part of the API. We use the OpenAPI/Swagger standard. • Service is a piece of software, a piece of code, to be run in an out-of- process component, so it cannot be a library! • Service version is a version of a service. • Instance is a running process of a service version. As the running processes are addressable on TCP/IP network, you can call them via a socket identified by an IP address and a TCP port. 27 Meta-Model and Terminology for APIs API endpoint API specification Service API
• API is a set of API endpoints that share a common purpose. • API endpoint is an interface; when using HTTP, an API endpoint is identified by the triplet {HTTP method, host, URL Path Template}. • API specification is a precise and comprehensive documentation of the API endpoints part of the API. We use the OpenAPI/Swagger standard. • Service is a piece of software, a piece of code, to be run in an out-of- process component, so it cannot be a library! • Service version is a version of a service. • Instance is a running process of a service version. As the running processes are addressable on TCP/IP network, you can call them via a socket identified by an IP address and a TCP port. 28 Meta-Model and Terminology for APIs API endpoint API specification Service API
• API is a set of API endpoints that share a common purpose. • API endpoint is an interface; when using HTTP, an API endpoint is identified by the triplet {HTTP method, host, URL Path Template}. • API specification is a precise and comprehensive documentation of the API endpoints part of the API. We use the OpenAPI/Swagger standard. • Service is a piece of software, a piece of code, to be run in an out-of- process component, so it cannot be a library! • Service version is a version of a service. • Instance is a running process of a service version. As the running processes are addressable on TCP/IP network, you can call them via a socket identified by an IP address and a TCP port. 29 Meta-Model and Terminology for APIs API endpoint API specification Service Service version API
• API is a set of API endpoints that share a common purpose. • API endpoint is an interface; when using HTTP, an API endpoint is identified by the triplet {HTTP method, host, URL Path Template}. • API specification is a precise and comprehensive documentation of the API endpoints part of the API. We use the OpenAPI/Swagger standard. • Service is a piece of software, a piece of code, to be run in an out-of- process component, so it cannot be a library! • Service version is a version of a service. • Instance is a running process of a service version. As the running processes are addressable on TCP/IP network, you can call them via a socket identified by an IP address and a TCP port. 30 Meta-Model and Terminology for APIs API endpoint API specification Service Service version Instance API
• API is a set of API endpoints that share a common purpose. • API endpoint is an interface; when using HTTP, an API endpoint is identified by the triplet {HTTP method, host, URL Path Template}. • API specification is a precise and comprehensive documentation of the API endpoints part of the API. We use the OpenAPI/Swagger standard. • Service is a piece of software, a piece of code, to be run in an out-of- process component, so it cannot be a library! • Service version is a version of a service. • Instance is a running process of a service version. As the running processes are addressable on TCP/IP network, you can call them via a socket identified by an IP address and a TCP port. 31 Meta-Model and Terminology for APIs API endpoint API specification Service Service version Xs.Ys.Zs Instance API
• API is a set of API endpoints that share a common purpose. • API endpoint is an interface; when using HTTP, an API endpoint is identified by the triplet {HTTP method, host, URL Path Template}. • API specification is a precise and comprehensive documentation of the API endpoints part of the API. We use the OpenAPI/Swagger standard. • Service is a piece of software, a piece of code, to be run in an out-of- process component, so it cannot be a library! • Service version is a version of a service. • Instance is a running process of a service version. As the running processes are addressable on TCP/IP network, you can call them via a socket identified by an IP address and a TCP port. 32 Meta-Model and Terminology for APIs API endpoint API specification Xa.Ya.Za Service Service version Xs.Ys.Zs Instance API
Semantic Versioning is a de-facto standard way – proposed by Tom Preston-Werner, co- founder of GitHub – to format version numbers of software packages. You can find the full specification at http://semver.org/. Semantic Versioning for both API Specifications and Services 33
Semantic Versioning is a de-facto standard way – proposed by Tom Preston-Werner, co- founder of GitHub – to format version numbers of software packages. You can find the full specification at http://semver.org/. MAJOR.MINOR.PATCH or X.Y.Z where X, Y and Z are non-negative integers 1. MAJOR version when you make incompatible API changes, 2. MINOR version when you add functionality in a backwards-compatible manner, and 3. PATCH version when you make backwards-compatible bug fixes. Semantic Versioning for both API Specifications and Services 34
Semantic Versioning is a de-facto standard way – proposed by Tom Preston-Werner, co- founder of GitHub – to format version numbers of software packages. You can find the full specification at http://semver.org/. MAJOR.MINOR.PATCH or X.Y.Z where X, Y and Z are non-negative integers 1. MAJOR version when you make incompatible API changes, 2. MINOR version when you add functionality in a backwards-compatible manner, and 3. PATCH version when you make backwards-compatible bug fixes. Software using Semantic Versioning MUST declare a public API. This API could be declared in the code itself or exist strictly in documentation. However it is done, it should be precise and comprehensive. Semantic Versioning for both API Specifications and Services 35
Semantic Versioning is a de-facto standard way – proposed by Tom Preston-Werner, co- founder of GitHub – to format version numbers of software packages. You can find the full specification at http://semver.org/. MAJOR.MINOR.PATCH or X.Y.Z where X, Y and Z are non-negative integers 1. MAJOR version when you make incompatible API changes, 2. MINOR version when you add functionality in a backwards-compatible manner, and 3. PATCH version when you make backwards-compatible bug fixes. Software using Semantic Versioning MUST declare a public API. This API could be declared in the code itself or exist strictly in documentation. However it is done, it should be precise and comprehensive. Swagger/OpenAPI 2.0 specification – https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md Semantic Versioning for both API Specifications and Services 36
10. Patch version Z(a) (x(a).y(a).Z(a) | x(a) > 0) of the Swagger/OpenAPI file MUST be incremented if changes that do not require any services implementing the API to be changed, are introduced. 11. Patch version Z(s) (x(s).y(s).Z(s) | x(s) > 0) of a service MUST be incremented if only backwards compatible bug fixes are introduced. A bug fix is defined as an internal change that fixes incorrect behavior and MUST NOT require any changes to the Swagger/OpenAPI file. The patch version Z(s) of a service MUST NOT be constrained by the patch version Z(a) of the Swagger/OpenAPI file, and vice-versa. 12. Minor version Y(a) (x(a).Y(a).z(a) | x(a) > 0) of the Swagger/OpenAPI file MUST be incremented if new, backwards compatible functionality is introduced to the API. It MUST be incremented if any API functionality is marked as deprecated. It MAY include patch level changes. Patch version MUST be reset to 0 when minor version is incremented. 13. Minor version Y(s) (x(s).Y(s).z(s) | x(s) > 0) of a service MUST be incremented, together with the Swagger/OpenAPI file one, if new, backwards compatible functionality is introduced by the API changes. It MUST NOT be incremented if the minor version of the Swagger/OpenAPI file is not incremented. It MAY include patch level changes. Patch version MUST be reset to 0 when minor version is incremented. The minor version Y(s) of a service MUST always be less than or equal to the minor version Y(a) of the Swagger/OpenAPI file, Y(s) ≤ Y(a). Semantic Versioning for both API Specifications and Services 37
10. Patch version Z(a) (x(a).y(a).Z(a) | x(a) > 0) of the Swagger/OpenAPI file MUST be incremented if changes that do not require any services implementing the API to be changed, are introduced. 11. Patch version Z(s) (x(s).y(s).Z(s) | x(s) > 0) of a service MUST be incremented if only backwards compatible bug fixes are introduced. A bug fix is defined as an internal change that fixes incorrect behavior and MUST NOT require any changes to the Swagger/OpenAPI file. The patch version Z(s) of a service MUST NOT be constrained by the patch version Z(a) of the Swagger/OpenAPI file, and vice-versa. 12. Minor version Y(a) (x(a).Y(a).z(a) | x(a) > 0) of the Swagger/OpenAPI file MUST be incremented if new, backwards compatible functionality is introduced to the API. It MUST be incremented if any API functionality is marked as deprecated. It MAY include patch level changes. Patch version MUST be reset to 0 when minor version is incremented. 13. Minor version Y(s) (x(s).Y(s).z(s) | x(s) > 0) of a service MUST be incremented, together with the Swagger/OpenAPI file one, if new, backwards compatible functionality is introduced by the API changes. It MUST NOT be incremented if the minor version of the Swagger/OpenAPI file is not incremented. It MAY include patch level changes. Patch version MUST be reset to 0 when minor version is incremented. The minor version Y(s) of a service MUST always be less than or equal to the minor version Y(a) of the Swagger/OpenAPI file, Y(s) ≤ Y(a). Semantic Versioning for both API Specifications and Services 38
API Gateway 39
API Gateway 40 Outside Inside
API Gateway 41 Outside Inside
API Gateway 42 Outside Inside Office
API Gateway 43 Outside Inside Office
API Gateway 44 Outside Inside Office API Gateway on the external edge
API Gateway 45 Outside Inside Office API Gateway on the external edge API Gateway on the internal edge
API Service Discovery and Client-Side Load Balancing 46 API Service Discovery
API Service Discovery and Client-Side Load Balancing 47 API Service Discovery Instance of Service~1 10.0.0.1:9001
API Service Discovery and Client-Side Load Balancing 48 API Service Discovery Instance of Service~1 10.0.0.1:9001 Application~1
API Service Discovery and Client-Side Load Balancing 49 Router API Service Discovery Instance of Service~1 10.0.0.1:9001 Application~1
API Service Discovery and Client-Side Load Balancing 50 Router API Service Discovery Instance of Service~1 10.0.0.1:9001 Application~1
API Service Discovery and Client-Side Load Balancing 51 Router API Service Discovery Instance of Service~1 10.0.0.1:9001 Application~1
API Service Discovery and Client-Side Load Balancing 52 Router Instance of Service~1 API Service Discovery Instance of Service~1 10.0.0.1:9001 10.0.0.2:9001 Application~1
API Service Discovery and Client-Side Load Balancing 53 Router Instance of Service~1 API Service Discovery Instance of Service~1 10.0.0.1:9001 10.0.0.2:9001 Application~1
API Service Discovery and Client-Side Load Balancing 54 Router Instance of Service~1 API Service Discovery Instance of Service~1 10.0.0.1:9001 10.0.0.2:9001 Application~1
API Service Discovery and Client-Side Load Balancing 55
API Service Discovery and Client-Side Load Balancing 56
In particular, [Baker Street] creates a simpler management model: there is a 1:1 mapping between a microservice instance and local load balancer (no central load balancer required!), which means every microservice can be configured and set up in exactly the same way using a default configuration that works for most services. In addition, the distributed architecture exhibits linear scale: each new microservice instance adds new load balancing capacity. Thus, the system is self-provisioning and automatically provides the capacity needed to handle the available instances of a service. Finally, by storing availability information locally with each load balancer instance, [Baker Street] ensures that all active microservice instances can still route traffic, even if some instances of the microservice or instances of [Baker Street] components. Source: https://thenewstack.io/baker-street-avoiding-bottlenecks-with-a-client-side-load-balancer-for-microservices/ API Service Discovery and Client-Side Load Balancing 57
Within our organization, we want to control which service is implementing which part of an API. The Manifest 58 API endpoint API specification Xa.Ya.Za Service Service version Xs.Ys.Zs Instance API
Within our organization, we want to control which service is implementing which part of an API. We can implement this control by creating a structure making an explicit link between a service and a list of API endpoints part of an API. We will call such a structure our manifest. The Manifest 59 API endpoint API specification Xa.Ya.Za Service Service version Xs.Ys.Zs Instance API Manifest
Within our organization, we want to control which service is implementing which part of an API. We can implement this control by creating a structure making an explicit link between a service and a list of API endpoints part of an API. We will call such a structure our manifest. When we generate a manifest, we store/remember the version of the API specification that documents API endpoint at the moment the manifest is generated. The Manifest 60 API endpoint API specification Xa.Ya.Za Service Service version Xs.Ys.Zs Instance API Manifest
{ "serviceName": "<Name of the service = client certificate OU>", "endpoints": [ { "method": "<paths/{path} of the Swagger/OpenAPI file>", "host": "<host of the Swagger/OpenAPI file>", "urlPathTemplate": "<paths of the Swagger/OpenAPI file>", "apiSpecificationVersion": "<info/version of the Swagger/OpenAPI file>" }, ... ] } The Manifest 61
When a software package wants to call an API endpoint, it has first to declare its intention to do so. Subscription and Peer Token 62 API endpoint API specification Xa.Ya.Za Service Service version Xs.Ys.Zs Instance API
When a software package wants to call an API endpoint, it has first to declare its intention to do so. We call subscription this relation between the software package, called an application, and a specific API endpoint. Subscription and Peer Token 63 API endpoint API specification Xa.Ya.Za Service Service version Xs.Ys.Zs Instance API SubscriptionApplication
When a software package wants to call an API endpoint, it has first to declare its intention to do so. We call subscription this relation between the software package, called an application, and a specific API endpoint. When we generate a peer-token, we store/remember the version of the API specification that documents the API endpoint at the moment the subscription is created. Subscription and Peer Token 64 API endpoint API specification Xa.Ya.Za Service Service version Xs.Ys.Zs Instance API SubscriptionApplication
{ "applicationName": "<if application == service = client certificate OU>", "endpoints": [ { "method": "<paths/{path} of the Swagger/OpenAPI file>", "host": "<host of the Swagger/OpenAPI file>", "urlPathTemplate": "<paths of the Swagger/OpenAPI file>", "apiSpecificationVersion": "<info/version of the Swagger/OpenAPI file>" }, ... ] } Subscription and Peer Token 65
{ "applicationName": "<if application == service = client certificate OU>", "endpoints": [ { "method": "<paths/{path} of the Swagger/OpenAPI file>", "host": "<host of the Swagger/OpenAPI file>", "urlPathTemplate": "<paths of the Swagger/OpenAPI file>", "apiSpecificationVersion": "<info/version of the Swagger/OpenAPI file>" }, ... ] } Subscription and Peer Token 66 This is the exact same structure as the manifest ;-)
We can now implement the Canary Release, but let’s be careful Application (API Specification x.Y.z)  (Yes)API endpoint (API Specification x.Y.z) Application (API Specification x.Y.z)  (Yes)API endpoint (API Specification x.Y+1.z) Application (API Specification x.Y+1.z)  (Yes)API endpoint (API Specification x.Y+1.z) Application (API Specification x.Y+1.z)  (No) API endpoint (API Specification x.Y.z) But, we can handle that by building the routing rules with information form both the API Registry and the API Service Discovery ;-) Routing 67
We can now implement the Canary Release, but let’s be careful 1. Application (API Specification x.Y.z)  (Yes)service (API Specification x.Y.z) Application (API Specification x.Y.z)  (Yes)API endpoint (API Specification x.Y+1.z) Application (API Specification x.Y+1.z)  (Yes)API endpoint (API Specification x.Y+1.z) Application (API Specification x.Y+1.z)  (No) API endpoint (API Specification x.Y.z) But, we can handle that by building the routing rules with information form both the API Registry and the API Service Discovery ;-) Routing 68
We can now implement the Canary Release, but let’s be careful 1. Application (API Specification x.Y.z)  (Yes)service (API Specification x.Y.z) 2. Application (API Specification x.Y.z)  (Yes)service (API Specification x.Y+1.z) Application (API Specification x.Y+1.z)  (Yes)API endpoint (API Specification x.Y+1.z) Application (API Specification x.Y+1.z)  (No) API endpoint (API Specification x.Y.z) But, we can handle that by building the routing rules with information form both the API Registry and the API Service Discovery ;-) Routing 69
We can now implement the Canary Release, but let’s be careful 1. Application (API Specification x.Y.z)  (Yes)service (API Specification x.Y.z) 2. Application (API Specification x.Y.z)  (Yes)service (API Specification x.Y+1.z) 3. Application (API Specification x.Y+1.z)  (Yes)service (API Specification x.Y+1.z) Application (API Specification x.Y+1.z)  (No) API endpoint (API Specification x.Y.z) But, we can handle that by building the routing rules with information form both the API Registry and the API Service Discovery ;-) Routing 70
We can now implement the Canary Release, but let’s be careful 1. Application (API Specification x.Y.z)  (Yes)service (API Specification x.Y.z) 2. Application (API Specification x.Y.z)  (Yes)service (API Specification x.Y+1.z) 3. Application (API Specification x.Y+1.z)  (Yes)service (API Specification x.Y+1.z) 4. Application (API Specification x.Y+1.z)  (No) service (API Specification x.Y.z) But, we can handle that by building the routing rules with information form both the API Registry and the API Service Discovery ;-) Routing 71
We can now implement the Canary Release, but let’s be careful 1. Application (API Specification x.Y.z)  (Yes)service (API Specification x.Y.z) 2. Application (API Specification x.Y.z)  (Yes)service (API Specification x.Y+1.z) 3. Application (API Specification x.Y+1.z)  (Yes)service (API Specification x.Y+1.z) 4. Application (API Specification x.Y+1.z)  (No) service (API Specification x.Y.z) But, we can handle that by building the routing rules with information form both the API Registry and the API Service Discovery ;-) Routing 72
We can now implement the Canary Release, but let’s be careful 1. Application (API Specification x.Y.z)  (Yes)service (API Specification x.Y.z) 2. Application (API Specification x.Y.z)  (Yes)service (API Specification x.Y+1.z) 3. Application (API Specification x.Y+1.z)  (Yes)service (API Specification x.Y+1.z) 4. Application (API Specification x.Y+1.z)  (No) service (API Specification x.Y.z) But, we can handle that by building the routing rules with information from both API Registry and API Service Discovery ;-) Routing 73
Routing 74
Routing 75 v1.0.3
Routing 76 v1.0.3 swagger: '2.0‘ info: title: My API version: 1.0.3 ...
Routing 77 API Registry v1.0.3 swagger: '2.0‘ info: title: My API version: 1.0.3 ...
Routing 78 API Registry v1.0.3
Routing 79 Service~1 API Registry v1.0.3
Routing 80 Service~1 API Registry v1.0.3 Manifest
Routing 81 Service~1 API Registry v1.0.3 { "serviceName": "Service~1", "endpoints": [ { "method": "...", "host": "...", "urlPathTemplate": "...", "apiSpecificationVersion": "1.0.3" } ] } Manifest
Routing 82 Service~1 API Registry v1.0.3 Manifest
Routing 83 Instance of Service~1 v1.0.5 API Registry 10.0.0.1:9001 v1.0.3 Manifest
Routing 84 API Service Discovery Instance of Service~1 v1.0.5 API Registry 10.0.0.1:9001 v1.0.3 Manifest
Routing 85 API Service Discovery Instance of Service~1 v1.0.5 API Registry 10.0.0.1:9001 v1.0.3 Manifest { "ip": "10.0.0.1:9001", "port": "9001" }
Routing 86 API Service Discovery Instance of Service~1 v1.0.5 API Registry 10.0.0.1:9001 v1.0.3 Manifest { "ip": "10.0.0.1:9001", "port": "9001", "manifest": { "serviceName": "Service~1", "endpoints": [ { "method": "...", "host": "...", "urlPathTemplate": "...", "apiSpecificationVersion": "1.0.3" } ] } }
Routing 87 API Service Discovery Instance of Service~1 v1.0.5 API Registry 10.0.0.1:9001 v1.0.3 Manifest
Routing 88 Application~1 API Service Discovery Instance of Service~1 v1.0.5 API Registry 10.0.0.1:9001 v1.0.3 Manifest
Routing 89 Application~1 (when v1.0.3) API Service Discovery Instance of Service~1 v1.0.5 API Registry 10.0.0.1:9001 v1.0.3 Manifest Subscription
Routing 90 Application~1 (when v1.0.3) API Service Discovery Instance of Service~1 v1.0.5 API Registry 10.0.0.1:9001 v1.0.3 Manifest Subscription { “applicationName": "Application~1", "endpoints": [ { "method": "...", "host": "...", "urlPathTemplate": "...", "apiSpecificationVersion": "1.0.3" } ] }
Routing 91 Application~1 (when v1.0.3) API Service Discovery Instance of Service~1 v1.0.5 API Registry 10.0.0.1:9001 v1.0.3 Manifest Subscription
Routing 92 Instance of Application~1 (when v1.0.3) API Service Discovery Instance of Service~1 v1.0.5 API Registry 10.0.0.1:9001 v1.0.3 Manifest Subscription
Routing 93 Instance of Application~1 (when v1.0.3) Router API Service Discovery Instance of Service~1 v1.0.5 API Registry 10.0.0.1:9001 v1.0.3 Manifest Subscription
Routing 94 Instance of Application~1 (when v1.0.3) Router API Service Discovery Instance of Service~1 v1.0.5 API Registry 10.0.0.1:9001 v1.0.3 Manifest Subscription
Routing 95 Router API Service Discovery Instance of Service~1 v1.0.5 API Registry 10.0.0.1:9001 v1.0.3 Manifest Subscription { “applicationName": "Application~1", "endpoints": [ { "method": "...", "host": "...", "urlPathTemplate": "...", "apiSpecificationVersion": "1.0.3" } ] } Instance of Application~1 (when v1.0.3)
Routing 96 Router API Service Discovery Instance of Service~1 v1.0.5 API Registry 10.0.0.1:9001 v1.0.3 Manifest Subscription { “applicationName": "Application~1", "endpoints": [ { "method": "...", "host": "...", "urlPathTemplate": "...", "apiSpecificationVersion": "1.0.3" } ] } Instance of Application~1 (when v1.0.3)
Routing 97 API Service Discovery Instance of Service~1 v1.0.5 API Registry 10.0.0.1:9001 v1.0.3 Manifest Subscription { “applicationName": "Application~1", "endpoints": [ { "method": "...", "host": "...", "urlPathTemplate": "...", "apiSpecificationVersion": "1.0.3" } ] } [ { "ip": “10.0.0.1", "port": “9001", "apiSpecificationVersion": “1.0.3" } ] Router Instance of Application~1 (when v1.0.3)
Routing 98 API Service Discovery Instance of Service~1 v1.0.5 API Registry 10.0.0.1:9001 v1.0.3 Manifest Subscription { “applicationName": "Application~1", "endpoints": [ { "method": "...", "host": "...", "urlPathTemplate": "...", "apiSpecificationVersion": "1.0.3" } ] } [ { "ip": “10.0.0.1", "port": “9001", "apiSpecificationVersion": “1.0.3" } ] Instance of Application~1 (when v1.0.3) Router
Routing 99 API Service Discovery Instance of Service~1 v1.0.5 API Registry 10.0.0.1:9001 v1.0.3 Manifest Subscription { “applicationName": "Application~1", "endpoints": [ { "method": "...", "host": "...", "urlPathTemplate": "...", "apiSpecificationVersion": "1.0.3" } ] } [ { "ip": “10.0.0.1", "port": “9001", "apiSpecificationVersion": “1.0.3" } ] Router Instance of Application~1 (when v1.0.3)
Routing 100 API Service Discovery Instance of Service~1 v1.0.5 API Registry 10.0.0.1:9001 v1.0.3 Manifest Subscription { “applicationName": "Application~1", "endpoints": [ { "method": "...", "host": "...", "urlPathTemplate": "...", "apiSpecificationVersion": "1.0.3" } ] } [ { "ip": “10.0.0.1", "port": “9001", "apiSpecificationVersion": “1.0.3" } ] Router v1.1.0 Instance of Application~1 (when v1.0.3)
Routing 101 API Service Discovery Instance of Service~1 v1.0.5 API Registry 10.0.0.1:9001 v1.0.3 Manifest Subscription { “applicationName": "Application~1", "endpoints": [ { "method": "...", "host": "...", "urlPathTemplate": "...", "apiSpecificationVersion": "1.0.3" } ] } [ { "ip": “10.0.0.1", "port": “9001", "apiSpecificationVersion": “1.0.3" } ] Router v1.1.0 Service~1 v1.1.2 Instance of Application~1 (when v1.0.3)
Routing 102 API Service Discovery Instance of Service~1 v1.0.5 API Registry 10.0.0.1:9001 v1.0.3 Manifest Subscription { “applicationName": "Application~1", "endpoints": [ { "method": "...", "host": "...", "urlPathTemplate": "...", "apiSpecificationVersion": "1.0.3" } ] } [ { "ip": “10.0.0.1", "port": “9001", "apiSpecificationVersion": “1.0.3" } ] Router v1.1.0 Instance of Service~1 v1.1.2 10.0.0.2:9001 Instance of Application~1 (when v1.0.3)
Routing 103 API Service Discovery Instance of Service~1 v1.0.5 API Registry 10.0.0.1:9001 v1.0.3 Manifest Subscription { “applicationName": "Application~1", "endpoints": [ { "method": "...", "host": "...", "urlPathTemplate": "...", "apiSpecificationVersion": "1.0.3" } ] } [ { "ip": “10.0.0.1", "port": “9001", "apiSpecificationVersion": “1.0.3" } ] Router v1.1.0 Instance of Service~1 v1.1.2 10.0.0.2:9001 Instance of Application~1 (when v1.0.3)
Routing 104 API Service Discovery Instance of Service~1 v1.0.5 API Registry 10.0.0.1:9001 v1.0.3 Manifest Subscription { “applicationName": "Application~1", "endpoints": [ { "method": "...", "host": "...", "urlPathTemplate": "...", "apiSpecificationVersion": "1.0.3" } ] } [ { "ip": “10.0.0.1", "port": “9001", "apiSpecificationVersion": “1.0.3" } ] Router v1.1.0 Instance of Service~1 v1.1.2 10.0.0.2:9001 Instance of Application~1 (when v1.0.3)
Routing 105 API Service Discovery Instance of Service~1 v1.0.5 API Registry 10.0.0.1:9001 v1.0.3 Manifest Subscription { “applicationName": "Application~1", "endpoints": [ { "method": "...", "host": "...", "urlPathTemplate": "...", "apiSpecificationVersion": "1.0.3" } ] } [ { "ip": “10.0.0.1", "port": “9001", "apiSpecificationVersion": “1.0.3" }, { "ip": “10.0.0.2", "port": “9001", "apiSpecificationVersion": “1.1.0" } ] Router Instance of Application~1 (when v1.0.3) v1.1.0 Instance of Service~1 v1.1.2 10.0.0.2:9001
Routing 106 API Service Discovery Instance of Service~1 v1.0.5 API Registry 10.0.0.1:9001 v1.0.3 Manifest Subscription { “applicationName": "Application~1", "endpoints": [ { "method": "...", "host": "...", "urlPathTemplate": "...", "apiSpecificationVersion": "1.0.3" } ] } [ { "ip": “10.0.0.1", "port": “9001", "apiSpecificationVersion": “1.0.3" }, { "ip": “10.0.0.2", "port": “9001", "apiSpecificationVersion": “1.1.0" } ] Router Instance of Application~1 (when v1.0.3) v1.1.0 Instance of Service~1 v1.1.2 10.0.0.2:9001
Routing 107 Instance of Service~1 v1.1.2 API Service Discovery Instance of Service~1 v1.0.5 API Registry 10.0.0.1:9001 10.0.0.2:9001 v1.0.3 v1.1.0 Manifest
Routing 108 Application~2 Instance of Service~1 v1.1.2 API Service Discovery Instance of Service~1 v1.0.5 API Registry 10.0.0.1:9001 10.0.0.2:9001 v1.0.3 v1.1.0 Manifest
Routing 109 Application~2 (when v1.1.0) Instance of Service~1 v1.1.2 API Service Discovery Instance of Service~1 v1.0.5 API Registry 10.0.0.1:9001 10.0.0.2:9001 v1.0.3 v1.1.0 Manifest Subscription
Routing 110 Application~2 (when v1.1.0) Instance of Service~1 v1.1.2 API Service Discovery Instance of Service~1 v1.0.5 API Registry 10.0.0.1:9001 10.0.0.2:9001 v1.0.3 v1.1.0 Manifest Subscription { “applicationName": "Application~2", "endpoints": [ { "method": "...", "host": "...", "urlPathTemplate": "...", "apiSpecificationVersion": "1.1.0" } ] }
Routing 111 Application~2 (when v1.1.0) Instance of Service~1 v1.1.2 API Service Discovery Instance of Service~1 v1.0.5 API Registry 10.0.0.1:9001 10.0.0.2:9001 v1.0.3 v1.1.0 Manifest Subscription
Routing 112 Router Instance of Service~1 v1.1.2 API Service Discovery Instance of Service~1 v1.0.5 10.0.0.1:9001 10.0.0.2:9001 v1.0.3 v1.1.0 API Registry Instance of Application~2 (when v1.1.0) Manifest Subscription
Routing 113 Router Instance of Service~1 v1.1.2 API Service Discovery Instance of Service~1 v1.0.5 10.0.0.1:9001 10.0.0.2:9001 v1.0.3 v1.1.0 API Registry Instance of Application~2 (when v1.1.0) Manifest Subscription
Routing 114 Router Instance of Service~1 v1.1.2 API Service Discovery Instance of Service~1 v1.0.5 10.0.0.1:9001 10.0.0.2:9001 v1.0.3 v1.1.0 { “applicationName": "Application~2", "endpoints": [ { "method": "...", "host": "...", "urlPathTemplate": "...", "apiSpecificationVersion": "1.1.0" } ] } API Registry Instance of Application~2 (when v1.1.0) Manifest Subscription
Routing 115 Router Instance of Service~1 v1.1.2 API Service Discovery Instance of Service~1 v1.0.5 10.0.0.1:9001 10.0.0.2:9001 v1.0.3 v1.1.0 { “applicationName": "Application~2", "endpoints": [ { "method": "...", "host": "...", "urlPathTemplate": "...", "apiSpecificationVersion": "1.1.0" } ] } API Registry Instance of Application~2 (when v1.1.0) Manifest Subscription
Routing 116 Router Instance of Service~1 v1.1.2 API Service Discovery Instance of Service~1 v1.0.5 10.0.0.1:9001 10.0.0.2:9001 v1.0.3 v1.1.0 { “applicationName": "Application~2", "endpoints": [ { "method": "...", "host": "...", "urlPathTemplate": "...", "apiSpecificationVersion": "1.1.0" } ] } [ { "ip": “10.0.0.1", "port": “9001", "apiSpecificationVersion": “1.0.3" }, { "ip": “10.0.0.2", "port": “9001", "apiSpecificationVersion": “1.1.0" } ] API Registry Instance of Application~2 (when v1.1.0) Manifest Subscription
Routing 117 Router Instance of Service~1 v1.1.2 API Service Discovery Instance of Service~1 v1.0.5 10.0.0.1:9001 10.0.0.2:9001 v1.0.3 v1.1.0 { “applicationName": "Application~2", "endpoints": [ { "method": "...", "host": "...", "urlPathTemplate": "...", "apiSpecificationVersion": "1.1.0" } ] } [ { "ip": “10.0.0.1", "port": “9001", "apiSpecificationVersion": “1.0.3" }, { "ip": “10.0.0.2", "port": “9001", "apiSpecificationVersion": “1.1.0" } ] API Registry Instance of Application~2 (when v1.1.0) Manifest Subscription
Routing 118 Router Instance of Service~1 v1.1.2 API Service Discovery Instance of Service~1 v1.0.5 10.0.0.1:9001 10.0.0.2:9001 v1.0.3 v1.1.0 { “applicationName": "Application~2", "endpoints": [ { "method": "...", "host": "...", "urlPathTemplate": "...", "apiSpecificationVersion": "1.1.0" } ] } [ { "ip": “10.0.0.1", "port": “9001", "apiSpecificationVersion": “1.0.3" }, { "ip": “10.0.0.2", "port": “9001", "apiSpecificationVersion": “1.1.0" } ] API Registry Instance of Application~2 (when v1.1.0) Manifest Subscription
Routing 119 Router Instance of Service~1 v1.1.2 API Service Discovery Instance of Service~1 v1.0.5 10.0.0.1:9001 10.0.0.2:9001 v1.0.3 v1.1.0 { “applicationName": "Application~2", "endpoints": [ { "method": "...", "host": "...", "urlPathTemplate": "...", "apiSpecificationVersion": "1.1.0" } ] } [ { "ip": “10.0.0.1", "port": “9001", "apiSpecificationVersion": “1.0.3" }, { "ip": “10.0.0.2", "port": “9001", "apiSpecificationVersion": “1.1.0" } ] API Registry Instance of Application~2 (when v1.1.0) Manifest Subscription
Summary 120
• Make an explicit distinction between API (endpoints) and services Summary 121
• Make an explicit distinction between API (endpoints) and services Summary 122
• Make an explicit distinction between API (endpoints) and services • Use semantic versioning for both API specifications (OpenAPI/Swagger) and services Summary 123
• Make an explicit distinction between API (endpoints) and services • Use semantic versioning for both API specifications (OpenAPI/Swagger) and services • Make an explicit link between service and API endpoints within a manifest* Summary 124
• Make an explicit distinction between API (endpoints) and services • Use semantic versioning for both API specifications (OpenAPI/Swagger) and services • Make an explicit link between service and API endpoints within a manifest* • Register instances at run-time by sending the manifest to API Service Discovery • Get the physical addresses of your running services (instances) via API Service Discovery Summary 125
• Make an explicit distinction between API (endpoints) and services • Use semantic versioning for both API specifications (OpenAPI/Swagger) and services • Make an explicit link between service and API endpoints within a manifest* • Register instances at run-time by sending the manifest to API Service Discovery • Get the physical addresses of your running services (instances) via API Service Discovery • Request explicit subscriptions to API endpoints at design-time, and store them in API Registry • Make subscriptions available at run-time with peer-tokens* Summary 126
• Make an explicit distinction between API (endpoints) and services • Use semantic versioning for both API specifications (OpenAPI/Swagger) and services • Make an explicit link between service and API endpoints within a manifest* • Register instances at run-time by sending the manifest to API Service Discovery • Get the physical addresses of your running services (instances) via API Service Discovery • Request explicit subscriptions to API endpoints at design-time, and store them in API Registry • Make subscriptions available at run-time with peer-tokens* • Let the (client-side) router make a wise decision about which instance to call by combining information coming from API Registry and API Service Discovery * The structure of a manifest and a peer-token is the same – exploit the symmetry – and, for both, the trick is to remember/store the version of API specification ;-) Summary 127
• Make an explicit distinction between API (endpoints) and services • Use semantic versioning for both API specifications (OpenAPI/Swagger) and services • Make an explicit link between service and API endpoints within a manifest* • Register instances at run-time by sending the manifest to API Service Discovery • Get the physical addresses of your running services (instances) via API Service Discovery • Request explicit subscriptions to API endpoints at design-time, and store them in API Registry • Make subscriptions available at run-time with peer-tokens* • Let the (client-side) router make a wise decision about which instance to call by combining information coming from API Registry and API Service Discovery * The structure of a manifest and a peer-token is the same – exploit the symmetry – and, for both, the trick is to remember/store the version of API specification ;-) Summary 128
• Make an explicit distinction between API (endpoints) and services • Use semantic versioning for both API specifications (OpenAPI/Swagger) and services • Make an explicit link between service and API endpoints within a manifest* • Register instances at run-time by sending the manifest to API Service Discovery • Get the physical addresses of your running services (instances) via API Service Discovery • Request explicit subscriptions to API endpoints at design-time, and store them in API Registry • Make subscriptions available at run-time with peer-tokens* • Let the (client-side) router make a wise decision about which instance to call by combining information coming from API Registry and API Service Discovery * The structure of a manifest and a peer-token is the same – exploit the symmetry – and, for both, the trick is to remember/store the version of API specification ;-) • Extend this technique to Confidence Check and A/B testing, it’s a unified way to handle any special routing mechanisms you want to implement ;-) Summary 129
• Make an explicit distinction between API (endpoints) and services Summary 130
• Make an explicit distinction between API (endpoints) and services • Make an explicit distinction between the interface and the code Summary 131 Click to edit Master title style
API Versioning, DON’T bother your consumers with it ;-) Thank You! Patrice Krakow, Lead Architect, APIs, ING https://www.linkedin.com/in/patricekrakow/ @patricekrakow
API Versioning, DON’T bother your consumers with it ;-) Thank You! Patrice Krakow, Lead Architect, APIs, ING https://www.linkedin.com/in/patricekrakow/ @patricekrakow
API Versioning, DON’T bother your consumers with it ;-) Thank You! Patrice Krakow, Lead Architect, APIs, ING https://www.linkedin.com/in/patricekrakow/ @patricekrakow

More Related Content

PPTX
2.3.anypoint exchange
Prakash Chakravarthi
 
DOC
Resume_Krishnendu_Ghosh
Krishnendu Ghosh
 
PDF
Atks (Arabic Toolkit services)
faculty of computing and information system
 
PDF
Using the Java Client Library by Noah Crowley, DevRel | InfluxData
InfluxData
 
PDF
Build pipelines with TeamCity and Kotlin DSL
Anton Arhipov
 
PPTX
INTERFACE by apidays_What's your Type? Understanding API Types and Choosing t...
apidays
 
PDF
4 Major Advantages of API Testing
QASource
 
PPTX
Getting to Grips with RESTful APIs
Petko Mikhailov
 
2.3.anypoint exchange
Prakash Chakravarthi
 
Resume_Krishnendu_Ghosh
Krishnendu Ghosh
 
Atks (Arabic Toolkit services)
faculty of computing and information system
 
Using the Java Client Library by Noah Crowley, DevRel | InfluxData
InfluxData
 
Build pipelines with TeamCity and Kotlin DSL
Anton Arhipov
 
INTERFACE by apidays_What's your Type? Understanding API Types and Choosing t...
apidays
 
4 Major Advantages of API Testing
QASource
 
Getting to Grips with RESTful APIs
Petko Mikhailov
 

What's hot (18)

PPTX
Api testing
HamzaMajid13
 
PDF
Beautiful APIs - SOSE2021 Keynote
Cesare Pautasso
 
PDF
Mocking APIs Collaboratively with Postman
Nordic APIs
 
PPSX
Community Tech Days C# 4.0
SANKARSAN BOSE
 
PPTX
apidays LIVE Australia 2020 - Have your cake and eat it too: GraphQL? REST? W...
apidays
 
PPTX
Lambda Behave - Java 8's Testing Framework
sara stanford
 
PDF
Api FUNdamentals #MHA2017
JoEllen Carter
 
PPTX
Meetup #5 API Testing World
Malang QA Community
 
PDF
REST vs. GraphQL: Critical Look
Nordic APIs
 
PDF
Tutorial for developing SILOptimizer Pass
秋 勇紀
 
PPTX
Extend soa with api management spoug- Madrid
Vinay Kumar
 
PDF
Beyond 49x Transformers: Don't be afraid of (the) Python!
Safe Software
 
PPTX
Data Driven API Testing: Best Practices for Real-World Testing Scenarios
SmartBear
 
PPTX
Evaluating and Testing Web APIs
SmartBear
 
PPTX
Tech Days 2015: Ada 2012 and Spark Crazyflie and Railway Demo
AdaCore
 
PPTX
Speech to text software
RDI Egypt
 
PDF
API Testing: Answers to Your Top 3 Questions
QASource
 
PPTX
Raml part 1
venkata20k
 
Api testing
HamzaMajid13
 
Beautiful APIs - SOSE2021 Keynote
Cesare Pautasso
 
Mocking APIs Collaboratively with Postman
Nordic APIs
 
Community Tech Days C# 4.0
SANKARSAN BOSE
 
apidays LIVE Australia 2020 - Have your cake and eat it too: GraphQL? REST? W...
apidays
 
Lambda Behave - Java 8's Testing Framework
sara stanford
 
Api FUNdamentals #MHA2017
JoEllen Carter
 
Meetup #5 API Testing World
Malang QA Community
 
REST vs. GraphQL: Critical Look
Nordic APIs
 
Tutorial for developing SILOptimizer Pass
秋 勇紀
 
Extend soa with api management spoug- Madrid
Vinay Kumar
 
Beyond 49x Transformers: Don't be afraid of (the) Python!
Safe Software
 
Data Driven API Testing: Best Practices for Real-World Testing Scenarios
SmartBear
 
Evaluating and Testing Web APIs
SmartBear
 
Tech Days 2015: Ada 2012 and Spark Crazyflie and Railway Demo
AdaCore
 
Speech to text software
RDI Egypt
 
API Testing: Answers to Your Top 3 Questions
QASource
 
Raml part 1
venkata20k
 
Ad

Similar to A Journey from API Versioning to Canary Release | Nordic APIs Platform Summit 2017 (20)

PPTX
A Journey from API Versioning to Canary Release | APIDays Zurich 2017
Patrice Krakow
 
PPTX
API Versioning for Zero Downtime | Devoxx Belgium 2017
Patrice Krakow
 
PDF
Practices and tools for building better API (JFall 2013)
Peter Hendriks
 
PDF
Practices and tools for building better APIs
NLJUG
 
PDF
Apicurio Registry: Event-driven APIs & Schema governance for Apache Kafka | F...
HostedbyConfluent
 
PDF
Extend soa with api management Sangam18
Vinay Kumar
 
PPTX
API Documentation.pptx
RahulCR31
 
PPTX
API Documentation.pptx
RahulCR31
 
PDF
Introduction to Apache Beam
Knoldus Inc.
 
PDF
apidays LIVE Hong Kong 2021 - Multi-Protocol APIs at Scale in Adidas by Jesus...
apidays
 
PPTX
REST-API's for architects and managers
Patrick Savalle
 
PPTX
API Conference 2021
José Haro Peralta
 
PPTX
mulesoft birmingham meetup_api_designing_with_raml
mohammadsakifuddin
 
PPTX
Api design part 1
Ibrahim Elsawaf
 
PDF
RefCard API Architecture Strategy
OCTO Technology
 
PDF
Schema-First API Design
Yos Riady
 
PPT
Effective API Design
Bansilal Haudakari
 
PDF
Extend soa with api management Doag18
Vinay Kumar
 
PPT
How to design effective APIs
Bansilal Haudakari
 
PPTX
APIdays Paris 2014 - Workshop - Craft and Deploy Your API in a Few Clicks Wit...
Restlet
 
A Journey from API Versioning to Canary Release | APIDays Zurich 2017
Patrice Krakow
 
API Versioning for Zero Downtime | Devoxx Belgium 2017
Patrice Krakow
 
Practices and tools for building better API (JFall 2013)
Peter Hendriks
 
Practices and tools for building better APIs
NLJUG
 
Apicurio Registry: Event-driven APIs & Schema governance for Apache Kafka | F...
HostedbyConfluent
 
Extend soa with api management Sangam18
Vinay Kumar
 
API Documentation.pptx
RahulCR31
 
API Documentation.pptx
RahulCR31
 
Introduction to Apache Beam
Knoldus Inc.
 
apidays LIVE Hong Kong 2021 - Multi-Protocol APIs at Scale in Adidas by Jesus...
apidays
 
REST-API's for architects and managers
Patrick Savalle
 
API Conference 2021
José Haro Peralta
 
mulesoft birmingham meetup_api_designing_with_raml
mohammadsakifuddin
 
Api design part 1
Ibrahim Elsawaf
 
RefCard API Architecture Strategy
OCTO Technology
 
Schema-First API Design
Yos Riady
 
Effective API Design
Bansilal Haudakari
 
Extend soa with api management Doag18
Vinay Kumar
 
How to design effective APIs
Bansilal Haudakari
 
APIdays Paris 2014 - Workshop - Craft and Deploy Your API in a Few Clicks Wit...
Restlet
 
Ad

Recently uploaded (20)

PDF
Jenkins: An open-source automation server powering CI/CD Automation
SaikatBasu37
 
PPTX
Maximizing Revenue with Marketo Measure: A Deep Dive into Multi-Touch Attribu...
bbedford2
 
PDF
Generating Union types w/ Static Analysis
K. Matthew Dupree
 
PDF
Protecting the Digital World Cyber Securit
dnthakkar16
 
PDF
Key Features to Look for in Arizona App Development Services
Net-Craft.com
 
PPTX
GALILEO CRS SYSTEM | GALILEO TRAVEL SOFTWARE
philipnathen82
 
PPTX
AI-Ready Handoff: Auto-Summaries & Draft Emails from MQL to Slack in One Flow
bbedford2
 
PDF
vAdobe Premiere Pro 2025 (v25.2.3.004) Crack Pre-Activated Latest
imang66g
 
PPTX
ASSIGNMENT_1[1][1][1][1][1] (1) variables.pptx
kr2589474
 
PPTX
classification of computer and basic part of digital computer
ravisinghrajpurohit3
 
PDF
Applitools Platform Pulse: What's New and What's Coming - July 2025
Applitools
 
PDF
Exploring AI Agents in Process Industries
amoreira6
 
PDF
advancepresentationskillshdhdhhdhdhdhhfhf
jasmenrojas249
 
PPTX
Explanation about Structures in C language.pptx
Veeral Rathod
 
PPTX
Visualising Data with Scatterplots in IBM SPSS Statistics.pptx
Version 1 Analytics
 
DOCX
Can You Build Dashboards Using Open Source Visualization Tool.docx
Varsha Nayak
 
PDF
lesson-2-rules-of-netiquette.pdf.bshhsjdj
jasmenrojas249
 
PPTX
ConcordeApp: Engineering Global Impact & Unlocking Billions in Event ROI with AI
chastechaste14
 
PDF
Appium Automation Testing Tutorial PDF: Learn Mobile Testing in 7 Days
jamescantor38
 
PDF
Balancing Resource Capacity and Workloads with OnePlan – Avoid Overloading Te...
OnePlan Solutions
 
Jenkins: An open-source automation server powering CI/CD Automation
SaikatBasu37
 
Maximizing Revenue with Marketo Measure: A Deep Dive into Multi-Touch Attribu...
bbedford2
 
Generating Union types w/ Static Analysis
K. Matthew Dupree
 
Protecting the Digital World Cyber Securit
dnthakkar16
 
Key Features to Look for in Arizona App Development Services
Net-Craft.com
 
GALILEO CRS SYSTEM | GALILEO TRAVEL SOFTWARE
philipnathen82
 
AI-Ready Handoff: Auto-Summaries & Draft Emails from MQL to Slack in One Flow
bbedford2
 
vAdobe Premiere Pro 2025 (v25.2.3.004) Crack Pre-Activated Latest
imang66g
 
ASSIGNMENT_1[1][1][1][1][1] (1) variables.pptx
kr2589474
 
classification of computer and basic part of digital computer
ravisinghrajpurohit3
 
Applitools Platform Pulse: What's New and What's Coming - July 2025
Applitools
 
Exploring AI Agents in Process Industries
amoreira6
 
advancepresentationskillshdhdhhdhdhdhhfhf
jasmenrojas249
 
Explanation about Structures in C language.pptx
Veeral Rathod
 
Visualising Data with Scatterplots in IBM SPSS Statistics.pptx
Version 1 Analytics
 
Can You Build Dashboards Using Open Source Visualization Tool.docx
Varsha Nayak
 
lesson-2-rules-of-netiquette.pdf.bshhsjdj
jasmenrojas249
 
ConcordeApp: Engineering Global Impact & Unlocking Billions in Event ROI with AI
chastechaste14
 
Appium Automation Testing Tutorial PDF: Learn Mobile Testing in 7 Days
jamescantor38
 
Balancing Resource Capacity and Workloads with OnePlan – Avoid Overloading Te...
OnePlan Solutions
 

A Journey from API Versioning to Canary Release | Nordic APIs Platform Summit 2017

  • 1. A Journey from API Versioning to Canary Release Patrice Krakow | ING | Lead Architect | APIs Nordic APIs – The 2017 Platform Summit Stockholm | 2017, October 10 (2.2.1)
  • 2. We want to be a tech company with a banking license! Ralph Hamers, CEO and chairman Executive Board ING Group source: https://www.ing.com/Newsroom/All-news/We-want-to-be-a-tech-company-with-a-banking-license-Ralph-Hamers.htm
  • 3. Patrice Krakow 3 • Sep 2016 – Present • ING | Lead Architect of the API Platform • Jul 2012 – Aug 2016 • ING Belgium | SOA Architect • Jun 2012 – Apr 2013 • Eligible | Co-founder • Aug 2001 – Jun 2012 • SCA Package (DS Smith) | System Integration Coordinator … • Sep 1990 – Jun 1995 • University of Liège | Master of Physics
  • 4. A Journey from API Versioning to Canary Release 4
  • 8. Why? 8 API Providers API Consumers want to change their APIs as soon as they have a new brilliant idea want the APIs they are using to stay stable as long as they are not interested by the new brilliant ideas of the API Providers!
  • 9. Why? 9 API Providers API Consumers What!? want to change their APIs as soon as they have a new brilliant idea want the APIs they are using to stay stable as long as they are not interested by the new brilliant ideas of the API Providers!
  • 10. Why? 10 API Providers API Consumers API Versionin g want to change their APIs as soon as they have a new brilliant idea want the APIs they are using to stay stable as long as they are not interested by the new brilliant ideas of the API Providers!
  • 11. Why? 11 API Providers API Consumers want to change their APIs as soon as they have a new brilliant idea want the APIs they are using to stay stable as long as they are not interested by the new brilliant ideas of the API Providers! DON’ T
  • 12. Why? 12 API Providers API Consumers want to change their APIs as soon as they have a new brilliant idea want the APIs they are using to stay stable as long as they are not interested by the new brilliant ideas of the API Providers!
  • 13. Why? 13 API Providers API Consumers want to change their APIs as soon as they have a new brilliant idea want the APIs they are using to stay stable as long as they are not interested by the new brilliant ideas of the API Providers!
  • 14. The canary release is a technique to reduce the risk of introducing a new software version in production by slowly rolling out the change to a small subset of users before making it available to everybody. Canary Release 14
  • 15. The canary release is a technique to reduce the risk of introducing a new software version in production by slowly rolling out the change to a small subset of users before making it available to everybody. The name for this technique originates from miners who would carry a canary in a cage down the coal mines. If toxic gases leaked into the mine, it would kill the canary before killing the miners. A canary release provides a similar form of early warning for potential problems before impacting your user base. Canary Release 15
  • 17. Canary Release 17 Application~1 Router Instance of Service~1 v1.1.0 Instance of Service~1 v1.0.0
  • 18. Canary Release 18 Application~1 Router Instance of Service~1 v1.1.0 Instance of Service~1 v1.0.0 100% 10% 90%
  • 19. Canary Release 19 Application~1 Router Instance of Service~1 v1.1.0 Instance of Service~1 v1.0.0 100% 50% 50%
  • 20. Canary Release 20 Application~1 Router Instance of Service~1 v1.1.0 Instance of Service~1 v1.0.0 100% 90% 10%
  • 21. Canary Release 21 Application~1 Router Instance of Service~1 v1.1.0 Instance of Service~1 v1.0.0 100% 100%
  • 23. • API is a set of API endpoints. • API endpoint is an interface; when using HTTP, an API endpoint is identified by the triplet {HTTP method, host, URL Path Template}. • API specification is a precise and comprehensive documentation of the API endpoints part of the API. We use the OpenAPI/Swagger standard. • Service is a piece of software, a piece of code, to be run in an out-of- process component, so it cannot be a library! • Service version is a version of a service. • Instance is a running process of a service version. As the running processes are addressable on TCP/IP network, you can call them via a socket identified by an IP address and a TCP port. 23 Meta-Model and Terminology for APIs Service API
  • 24. • API is a set of API endpoints. • API endpoint is an interface; when using HTTP, an API endpoint is identified by the triplet {HTTP method, host, URL Path Template}. • API specification is a precise and comprehensive documentation of the API endpoints part of the API. We use the OpenAPI/Swagger standard. • Service is a piece of software, a piece of code, to be run in an out-of- process component, so it cannot be a library! • Service version is a version of a service. • Instance is a running process of a service version. As the running processes are addressable on TCP/IP network, you can call them via a socket identified by an IP address and a TCP port. 24 Meta-Model and Terminology for APIs Service API
  • 25. • API is a set of API endpoints. • API endpoint is an interface; when using HTTP, an API endpoint is identified by the triplet {HTTP method, host, URL Path Template}. • API specification is a precise and comprehensive documentation of the API endpoints part of the API. We use the OpenAPI/Swagger standard. • Service is a piece of software, a piece of code, to be run in an out-of- process component, so it cannot be a library! • Service version is a version of a service. • Instance is a running process of a service version. As the running processes are addressable on TCP/IP network, you can call them via a socket identified by an IP address and a TCP port. 25 Meta-Model and Terminology for APIs API endpoint Service API
  • 26. • API is a set of API endpoints that share a common purpose. • API endpoint is an interface; when using HTTP, an API endpoint is identified by the triplet {HTTP method, host, URL Path Template}. • API specification is a precise and comprehensive documentation of the API endpoints part of the API. We use the OpenAPI/Swagger standard. • Service is a piece of software, a piece of code, to be run in an out-of- process component, so it cannot be a library! • Service version is a version of a service. • Instance is a running process of a service version. As the running processes are addressable on TCP/IP network, you can call them via a socket identified by an IP address and a TCP port. 26 Meta-Model and Terminology for APIs API endpoint Service API
  • 27. • API is a set of API endpoints that share a common purpose. • API endpoint is an interface; when using HTTP, an API endpoint is identified by the triplet {HTTP method, host, URL Path Template}. • API specification is a precise and comprehensive documentation of the API endpoints part of the API. We use the OpenAPI/Swagger standard. • Service is a piece of software, a piece of code, to be run in an out-of- process component, so it cannot be a library! • Service version is a version of a service. • Instance is a running process of a service version. As the running processes are addressable on TCP/IP network, you can call them via a socket identified by an IP address and a TCP port. 27 Meta-Model and Terminology for APIs API endpoint API specification Service API
  • 28. • API is a set of API endpoints that share a common purpose. • API endpoint is an interface; when using HTTP, an API endpoint is identified by the triplet {HTTP method, host, URL Path Template}. • API specification is a precise and comprehensive documentation of the API endpoints part of the API. We use the OpenAPI/Swagger standard. • Service is a piece of software, a piece of code, to be run in an out-of- process component, so it cannot be a library! • Service version is a version of a service. • Instance is a running process of a service version. As the running processes are addressable on TCP/IP network, you can call them via a socket identified by an IP address and a TCP port. 28 Meta-Model and Terminology for APIs API endpoint API specification Service API
  • 29. • API is a set of API endpoints that share a common purpose. • API endpoint is an interface; when using HTTP, an API endpoint is identified by the triplet {HTTP method, host, URL Path Template}. • API specification is a precise and comprehensive documentation of the API endpoints part of the API. We use the OpenAPI/Swagger standard. • Service is a piece of software, a piece of code, to be run in an out-of- process component, so it cannot be a library! • Service version is a version of a service. • Instance is a running process of a service version. As the running processes are addressable on TCP/IP network, you can call them via a socket identified by an IP address and a TCP port. 29 Meta-Model and Terminology for APIs API endpoint API specification Service Service version API
  • 30. • API is a set of API endpoints that share a common purpose. • API endpoint is an interface; when using HTTP, an API endpoint is identified by the triplet {HTTP method, host, URL Path Template}. • API specification is a precise and comprehensive documentation of the API endpoints part of the API. We use the OpenAPI/Swagger standard. • Service is a piece of software, a piece of code, to be run in an out-of- process component, so it cannot be a library! • Service version is a version of a service. • Instance is a running process of a service version. As the running processes are addressable on TCP/IP network, you can call them via a socket identified by an IP address and a TCP port. 30 Meta-Model and Terminology for APIs API endpoint API specification Service Service version Instance API
  • 31. • API is a set of API endpoints that share a common purpose. • API endpoint is an interface; when using HTTP, an API endpoint is identified by the triplet {HTTP method, host, URL Path Template}. • API specification is a precise and comprehensive documentation of the API endpoints part of the API. We use the OpenAPI/Swagger standard. • Service is a piece of software, a piece of code, to be run in an out-of- process component, so it cannot be a library! • Service version is a version of a service. • Instance is a running process of a service version. As the running processes are addressable on TCP/IP network, you can call them via a socket identified by an IP address and a TCP port. 31 Meta-Model and Terminology for APIs API endpoint API specification Service Service version Xs.Ys.Zs Instance API
  • 32. • API is a set of API endpoints that share a common purpose. • API endpoint is an interface; when using HTTP, an API endpoint is identified by the triplet {HTTP method, host, URL Path Template}. • API specification is a precise and comprehensive documentation of the API endpoints part of the API. We use the OpenAPI/Swagger standard. • Service is a piece of software, a piece of code, to be run in an out-of- process component, so it cannot be a library! • Service version is a version of a service. • Instance is a running process of a service version. As the running processes are addressable on TCP/IP network, you can call them via a socket identified by an IP address and a TCP port. 32 Meta-Model and Terminology for APIs API endpoint API specification Xa.Ya.Za Service Service version Xs.Ys.Zs Instance API
  • 33. Semantic Versioning is a de-facto standard way – proposed by Tom Preston-Werner, co- founder of GitHub – to format version numbers of software packages. You can find the full specification at http://semver.org/. Semantic Versioning for both API Specifications and Services 33
  • 34. Semantic Versioning is a de-facto standard way – proposed by Tom Preston-Werner, co- founder of GitHub – to format version numbers of software packages. You can find the full specification at http://semver.org/. MAJOR.MINOR.PATCH or X.Y.Z where X, Y and Z are non-negative integers 1. MAJOR version when you make incompatible API changes, 2. MINOR version when you add functionality in a backwards-compatible manner, and 3. PATCH version when you make backwards-compatible bug fixes. Semantic Versioning for both API Specifications and Services 34
  • 35. Semantic Versioning is a de-facto standard way – proposed by Tom Preston-Werner, co- founder of GitHub – to format version numbers of software packages. You can find the full specification at http://semver.org/. MAJOR.MINOR.PATCH or X.Y.Z where X, Y and Z are non-negative integers 1. MAJOR version when you make incompatible API changes, 2. MINOR version when you add functionality in a backwards-compatible manner, and 3. PATCH version when you make backwards-compatible bug fixes. Software using Semantic Versioning MUST declare a public API. This API could be declared in the code itself or exist strictly in documentation. However it is done, it should be precise and comprehensive. Semantic Versioning for both API Specifications and Services 35
  • 36. Semantic Versioning is a de-facto standard way – proposed by Tom Preston-Werner, co- founder of GitHub – to format version numbers of software packages. You can find the full specification at http://semver.org/. MAJOR.MINOR.PATCH or X.Y.Z where X, Y and Z are non-negative integers 1. MAJOR version when you make incompatible API changes, 2. MINOR version when you add functionality in a backwards-compatible manner, and 3. PATCH version when you make backwards-compatible bug fixes. Software using Semantic Versioning MUST declare a public API. This API could be declared in the code itself or exist strictly in documentation. However it is done, it should be precise and comprehensive. Swagger/OpenAPI 2.0 specification – https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md Semantic Versioning for both API Specifications and Services 36
  • 37. 10. Patch version Z(a) (x(a).y(a).Z(a) | x(a) > 0) of the Swagger/OpenAPI file MUST be incremented if changes that do not require any services implementing the API to be changed, are introduced. 11. Patch version Z(s) (x(s).y(s).Z(s) | x(s) > 0) of a service MUST be incremented if only backwards compatible bug fixes are introduced. A bug fix is defined as an internal change that fixes incorrect behavior and MUST NOT require any changes to the Swagger/OpenAPI file. The patch version Z(s) of a service MUST NOT be constrained by the patch version Z(a) of the Swagger/OpenAPI file, and vice-versa. 12. Minor version Y(a) (x(a).Y(a).z(a) | x(a) > 0) of the Swagger/OpenAPI file MUST be incremented if new, backwards compatible functionality is introduced to the API. It MUST be incremented if any API functionality is marked as deprecated. It MAY include patch level changes. Patch version MUST be reset to 0 when minor version is incremented. 13. Minor version Y(s) (x(s).Y(s).z(s) | x(s) > 0) of a service MUST be incremented, together with the Swagger/OpenAPI file one, if new, backwards compatible functionality is introduced by the API changes. It MUST NOT be incremented if the minor version of the Swagger/OpenAPI file is not incremented. It MAY include patch level changes. Patch version MUST be reset to 0 when minor version is incremented. The minor version Y(s) of a service MUST always be less than or equal to the minor version Y(a) of the Swagger/OpenAPI file, Y(s) ≤ Y(a). Semantic Versioning for both API Specifications and Services 37
  • 38. 10. Patch version Z(a) (x(a).y(a).Z(a) | x(a) > 0) of the Swagger/OpenAPI file MUST be incremented if changes that do not require any services implementing the API to be changed, are introduced. 11. Patch version Z(s) (x(s).y(s).Z(s) | x(s) > 0) of a service MUST be incremented if only backwards compatible bug fixes are introduced. A bug fix is defined as an internal change that fixes incorrect behavior and MUST NOT require any changes to the Swagger/OpenAPI file. The patch version Z(s) of a service MUST NOT be constrained by the patch version Z(a) of the Swagger/OpenAPI file, and vice-versa. 12. Minor version Y(a) (x(a).Y(a).z(a) | x(a) > 0) of the Swagger/OpenAPI file MUST be incremented if new, backwards compatible functionality is introduced to the API. It MUST be incremented if any API functionality is marked as deprecated. It MAY include patch level changes. Patch version MUST be reset to 0 when minor version is incremented. 13. Minor version Y(s) (x(s).Y(s).z(s) | x(s) > 0) of a service MUST be incremented, together with the Swagger/OpenAPI file one, if new, backwards compatible functionality is introduced by the API changes. It MUST NOT be incremented if the minor version of the Swagger/OpenAPI file is not incremented. It MAY include patch level changes. Patch version MUST be reset to 0 when minor version is incremented. The minor version Y(s) of a service MUST always be less than or equal to the minor version Y(a) of the Swagger/OpenAPI file, Y(s) ≤ Y(a). Semantic Versioning for both API Specifications and Services 38
  • 44. API Gateway 44 Outside Inside Office API Gateway on the external edge
  • 45. API Gateway 45 Outside Inside Office API Gateway on the external edge API Gateway on the internal edge
  • 46. API Service Discovery and Client-Side Load Balancing 46 API Service Discovery
  • 47. API Service Discovery and Client-Side Load Balancing 47 API Service Discovery Instance of Service~1 10.0.0.1:9001
  • 48. API Service Discovery and Client-Side Load Balancing 48 API Service Discovery Instance of Service~1 10.0.0.1:9001 Application~1
  • 49. API Service Discovery and Client-Side Load Balancing 49 Router API Service Discovery Instance of Service~1 10.0.0.1:9001 Application~1
  • 50. API Service Discovery and Client-Side Load Balancing 50 Router API Service Discovery Instance of Service~1 10.0.0.1:9001 Application~1
  • 51. API Service Discovery and Client-Side Load Balancing 51 Router API Service Discovery Instance of Service~1 10.0.0.1:9001 Application~1
  • 52. API Service Discovery and Client-Side Load Balancing 52 Router Instance of Service~1 API Service Discovery Instance of Service~1 10.0.0.1:9001 10.0.0.2:9001 Application~1
  • 53. API Service Discovery and Client-Side Load Balancing 53 Router Instance of Service~1 API Service Discovery Instance of Service~1 10.0.0.1:9001 10.0.0.2:9001 Application~1
  • 54. API Service Discovery and Client-Side Load Balancing 54 Router Instance of Service~1 API Service Discovery Instance of Service~1 10.0.0.1:9001 10.0.0.2:9001 Application~1
  • 55. API Service Discovery and Client-Side Load Balancing 55
  • 56. API Service Discovery and Client-Side Load Balancing 56
  • 57. In particular, [Baker Street] creates a simpler management model: there is a 1:1 mapping between a microservice instance and local load balancer (no central load balancer required!), which means every microservice can be configured and set up in exactly the same way using a default configuration that works for most services. In addition, the distributed architecture exhibits linear scale: each new microservice instance adds new load balancing capacity. Thus, the system is self-provisioning and automatically provides the capacity needed to handle the available instances of a service. Finally, by storing availability information locally with each load balancer instance, [Baker Street] ensures that all active microservice instances can still route traffic, even if some instances of the microservice or instances of [Baker Street] components. Source: https://thenewstack.io/baker-street-avoiding-bottlenecks-with-a-client-side-load-balancer-for-microservices/ API Service Discovery and Client-Side Load Balancing 57
  • 58. Within our organization, we want to control which service is implementing which part of an API. The Manifest 58 API endpoint API specification Xa.Ya.Za Service Service version Xs.Ys.Zs Instance API
  • 59. Within our organization, we want to control which service is implementing which part of an API. We can implement this control by creating a structure making an explicit link between a service and a list of API endpoints part of an API. We will call such a structure our manifest. The Manifest 59 API endpoint API specification Xa.Ya.Za Service Service version Xs.Ys.Zs Instance API Manifest
  • 60. Within our organization, we want to control which service is implementing which part of an API. We can implement this control by creating a structure making an explicit link between a service and a list of API endpoints part of an API. We will call such a structure our manifest. When we generate a manifest, we store/remember the version of the API specification that documents API endpoint at the moment the manifest is generated. The Manifest 60 API endpoint API specification Xa.Ya.Za Service Service version Xs.Ys.Zs Instance API Manifest
  • 61. { "serviceName": "<Name of the service = client certificate OU>", "endpoints": [ { "method": "<paths/{path} of the Swagger/OpenAPI file>", "host": "<host of the Swagger/OpenAPI file>", "urlPathTemplate": "<paths of the Swagger/OpenAPI file>", "apiSpecificationVersion": "<info/version of the Swagger/OpenAPI file>" }, ... ] } The Manifest 61
  • 62. When a software package wants to call an API endpoint, it has first to declare its intention to do so. Subscription and Peer Token 62 API endpoint API specification Xa.Ya.Za Service Service version Xs.Ys.Zs Instance API
  • 63. When a software package wants to call an API endpoint, it has first to declare its intention to do so. We call subscription this relation between the software package, called an application, and a specific API endpoint. Subscription and Peer Token 63 API endpoint API specification Xa.Ya.Za Service Service version Xs.Ys.Zs Instance API SubscriptionApplication
  • 64. When a software package wants to call an API endpoint, it has first to declare its intention to do so. We call subscription this relation between the software package, called an application, and a specific API endpoint. When we generate a peer-token, we store/remember the version of the API specification that documents the API endpoint at the moment the subscription is created. Subscription and Peer Token 64 API endpoint API specification Xa.Ya.Za Service Service version Xs.Ys.Zs Instance API SubscriptionApplication
  • 65. { "applicationName": "<if application == service = client certificate OU>", "endpoints": [ { "method": "<paths/{path} of the Swagger/OpenAPI file>", "host": "<host of the Swagger/OpenAPI file>", "urlPathTemplate": "<paths of the Swagger/OpenAPI file>", "apiSpecificationVersion": "<info/version of the Swagger/OpenAPI file>" }, ... ] } Subscription and Peer Token 65
  • 66. { "applicationName": "<if application == service = client certificate OU>", "endpoints": [ { "method": "<paths/{path} of the Swagger/OpenAPI file>", "host": "<host of the Swagger/OpenAPI file>", "urlPathTemplate": "<paths of the Swagger/OpenAPI file>", "apiSpecificationVersion": "<info/version of the Swagger/OpenAPI file>" }, ... ] } Subscription and Peer Token 66 This is the exact same structure as the manifest ;-)
  • 67. We can now implement the Canary Release, but let’s be careful Application (API Specification x.Y.z)  (Yes)API endpoint (API Specification x.Y.z) Application (API Specification x.Y.z)  (Yes)API endpoint (API Specification x.Y+1.z) Application (API Specification x.Y+1.z)  (Yes)API endpoint (API Specification x.Y+1.z) Application (API Specification x.Y+1.z)  (No) API endpoint (API Specification x.Y.z) But, we can handle that by building the routing rules with information form both the API Registry and the API Service Discovery ;-) Routing 67
  • 68. We can now implement the Canary Release, but let’s be careful 1. Application (API Specification x.Y.z)  (Yes)service (API Specification x.Y.z) Application (API Specification x.Y.z)  (Yes)API endpoint (API Specification x.Y+1.z) Application (API Specification x.Y+1.z)  (Yes)API endpoint (API Specification x.Y+1.z) Application (API Specification x.Y+1.z)  (No) API endpoint (API Specification x.Y.z) But, we can handle that by building the routing rules with information form both the API Registry and the API Service Discovery ;-) Routing 68
  • 69. We can now implement the Canary Release, but let’s be careful 1. Application (API Specification x.Y.z)  (Yes)service (API Specification x.Y.z) 2. Application (API Specification x.Y.z)  (Yes)service (API Specification x.Y+1.z) Application (API Specification x.Y+1.z)  (Yes)API endpoint (API Specification x.Y+1.z) Application (API Specification x.Y+1.z)  (No) API endpoint (API Specification x.Y.z) But, we can handle that by building the routing rules with information form both the API Registry and the API Service Discovery ;-) Routing 69
  • 70. We can now implement the Canary Release, but let’s be careful 1. Application (API Specification x.Y.z)  (Yes)service (API Specification x.Y.z) 2. Application (API Specification x.Y.z)  (Yes)service (API Specification x.Y+1.z) 3. Application (API Specification x.Y+1.z)  (Yes)service (API Specification x.Y+1.z) Application (API Specification x.Y+1.z)  (No) API endpoint (API Specification x.Y.z) But, we can handle that by building the routing rules with information form both the API Registry and the API Service Discovery ;-) Routing 70
  • 71. We can now implement the Canary Release, but let’s be careful 1. Application (API Specification x.Y.z)  (Yes)service (API Specification x.Y.z) 2. Application (API Specification x.Y.z)  (Yes)service (API Specification x.Y+1.z) 3. Application (API Specification x.Y+1.z)  (Yes)service (API Specification x.Y+1.z) 4. Application (API Specification x.Y+1.z)  (No) service (API Specification x.Y.z) But, we can handle that by building the routing rules with information form both the API Registry and the API Service Discovery ;-) Routing 71
  • 72. We can now implement the Canary Release, but let’s be careful 1. Application (API Specification x.Y.z)  (Yes)service (API Specification x.Y.z) 2. Application (API Specification x.Y.z)  (Yes)service (API Specification x.Y+1.z) 3. Application (API Specification x.Y+1.z)  (Yes)service (API Specification x.Y+1.z) 4. Application (API Specification x.Y+1.z)  (No) service (API Specification x.Y.z) But, we can handle that by building the routing rules with information form both the API Registry and the API Service Discovery ;-) Routing 72
  • 73. We can now implement the Canary Release, but let’s be careful 1. Application (API Specification x.Y.z)  (Yes)service (API Specification x.Y.z) 2. Application (API Specification x.Y.z)  (Yes)service (API Specification x.Y+1.z) 3. Application (API Specification x.Y+1.z)  (Yes)service (API Specification x.Y+1.z) 4. Application (API Specification x.Y+1.z)  (No) service (API Specification x.Y.z) But, we can handle that by building the routing rules with information from both API Registry and API Service Discovery ;-) Routing 73
  • 81. Routing 81 Service~1 API Registry v1.0.3 { "serviceName": "Service~1", "endpoints": [ { "method": "...", "host": "...", "urlPathTemplate": "...", "apiSpecificationVersion": "1.0.3" } ] } Manifest
  • 83. Routing 83 Instance of Service~1 v1.0.5 API Registry 10.0.0.1:9001 v1.0.3 Manifest
  • 84. Routing 84 API Service Discovery Instance of Service~1 v1.0.5 API Registry 10.0.0.1:9001 v1.0.3 Manifest
  • 85. Routing 85 API Service Discovery Instance of Service~1 v1.0.5 API Registry 10.0.0.1:9001 v1.0.3 Manifest { "ip": "10.0.0.1:9001", "port": "9001" }
  • 86. Routing 86 API Service Discovery Instance of Service~1 v1.0.5 API Registry 10.0.0.1:9001 v1.0.3 Manifest { "ip": "10.0.0.1:9001", "port": "9001", "manifest": { "serviceName": "Service~1", "endpoints": [ { "method": "...", "host": "...", "urlPathTemplate": "...", "apiSpecificationVersion": "1.0.3" } ] } }
  • 87. Routing 87 API Service Discovery Instance of Service~1 v1.0.5 API Registry 10.0.0.1:9001 v1.0.3 Manifest
  • 88. Routing 88 Application~1 API Service Discovery Instance of Service~1 v1.0.5 API Registry 10.0.0.1:9001 v1.0.3 Manifest
  • 89. Routing 89 Application~1 (when v1.0.3) API Service Discovery Instance of Service~1 v1.0.5 API Registry 10.0.0.1:9001 v1.0.3 Manifest Subscription
  • 90. Routing 90 Application~1 (when v1.0.3) API Service Discovery Instance of Service~1 v1.0.5 API Registry 10.0.0.1:9001 v1.0.3 Manifest Subscription { “applicationName": "Application~1", "endpoints": [ { "method": "...", "host": "...", "urlPathTemplate": "...", "apiSpecificationVersion": "1.0.3" } ] }
  • 91. Routing 91 Application~1 (when v1.0.3) API Service Discovery Instance of Service~1 v1.0.5 API Registry 10.0.0.1:9001 v1.0.3 Manifest Subscription
  • 92. Routing 92 Instance of Application~1 (when v1.0.3) API Service Discovery Instance of Service~1 v1.0.5 API Registry 10.0.0.1:9001 v1.0.3 Manifest Subscription
  • 93. Routing 93 Instance of Application~1 (when v1.0.3) Router API Service Discovery Instance of Service~1 v1.0.5 API Registry 10.0.0.1:9001 v1.0.3 Manifest Subscription
  • 94. Routing 94 Instance of Application~1 (when v1.0.3) Router API Service Discovery Instance of Service~1 v1.0.5 API Registry 10.0.0.1:9001 v1.0.3 Manifest Subscription
  • 95. Routing 95 Router API Service Discovery Instance of Service~1 v1.0.5 API Registry 10.0.0.1:9001 v1.0.3 Manifest Subscription { “applicationName": "Application~1", "endpoints": [ { "method": "...", "host": "...", "urlPathTemplate": "...", "apiSpecificationVersion": "1.0.3" } ] } Instance of Application~1 (when v1.0.3)
  • 96. Routing 96 Router API Service Discovery Instance of Service~1 v1.0.5 API Registry 10.0.0.1:9001 v1.0.3 Manifest Subscription { “applicationName": "Application~1", "endpoints": [ { "method": "...", "host": "...", "urlPathTemplate": "...", "apiSpecificationVersion": "1.0.3" } ] } Instance of Application~1 (when v1.0.3)
  • 97. Routing 97 API Service Discovery Instance of Service~1 v1.0.5 API Registry 10.0.0.1:9001 v1.0.3 Manifest Subscription { “applicationName": "Application~1", "endpoints": [ { "method": "...", "host": "...", "urlPathTemplate": "...", "apiSpecificationVersion": "1.0.3" } ] } [ { "ip": “10.0.0.1", "port": “9001", "apiSpecificationVersion": “1.0.3" } ] Router Instance of Application~1 (when v1.0.3)
  • 98. Routing 98 API Service Discovery Instance of Service~1 v1.0.5 API Registry 10.0.0.1:9001 v1.0.3 Manifest Subscription { “applicationName": "Application~1", "endpoints": [ { "method": "...", "host": "...", "urlPathTemplate": "...", "apiSpecificationVersion": "1.0.3" } ] } [ { "ip": “10.0.0.1", "port": “9001", "apiSpecificationVersion": “1.0.3" } ] Instance of Application~1 (when v1.0.3) Router
  • 99. Routing 99 API Service Discovery Instance of Service~1 v1.0.5 API Registry 10.0.0.1:9001 v1.0.3 Manifest Subscription { “applicationName": "Application~1", "endpoints": [ { "method": "...", "host": "...", "urlPathTemplate": "...", "apiSpecificationVersion": "1.0.3" } ] } [ { "ip": “10.0.0.1", "port": “9001", "apiSpecificationVersion": “1.0.3" } ] Router Instance of Application~1 (when v1.0.3)
  • 100. Routing 100 API Service Discovery Instance of Service~1 v1.0.5 API Registry 10.0.0.1:9001 v1.0.3 Manifest Subscription { “applicationName": "Application~1", "endpoints": [ { "method": "...", "host": "...", "urlPathTemplate": "...", "apiSpecificationVersion": "1.0.3" } ] } [ { "ip": “10.0.0.1", "port": “9001", "apiSpecificationVersion": “1.0.3" } ] Router v1.1.0 Instance of Application~1 (when v1.0.3)
  • 101. Routing 101 API Service Discovery Instance of Service~1 v1.0.5 API Registry 10.0.0.1:9001 v1.0.3 Manifest Subscription { “applicationName": "Application~1", "endpoints": [ { "method": "...", "host": "...", "urlPathTemplate": "...", "apiSpecificationVersion": "1.0.3" } ] } [ { "ip": “10.0.0.1", "port": “9001", "apiSpecificationVersion": “1.0.3" } ] Router v1.1.0 Service~1 v1.1.2 Instance of Application~1 (when v1.0.3)
  • 102. Routing 102 API Service Discovery Instance of Service~1 v1.0.5 API Registry 10.0.0.1:9001 v1.0.3 Manifest Subscription { “applicationName": "Application~1", "endpoints": [ { "method": "...", "host": "...", "urlPathTemplate": "...", "apiSpecificationVersion": "1.0.3" } ] } [ { "ip": “10.0.0.1", "port": “9001", "apiSpecificationVersion": “1.0.3" } ] Router v1.1.0 Instance of Service~1 v1.1.2 10.0.0.2:9001 Instance of Application~1 (when v1.0.3)
  • 103. Routing 103 API Service Discovery Instance of Service~1 v1.0.5 API Registry 10.0.0.1:9001 v1.0.3 Manifest Subscription { “applicationName": "Application~1", "endpoints": [ { "method": "...", "host": "...", "urlPathTemplate": "...", "apiSpecificationVersion": "1.0.3" } ] } [ { "ip": “10.0.0.1", "port": “9001", "apiSpecificationVersion": “1.0.3" } ] Router v1.1.0 Instance of Service~1 v1.1.2 10.0.0.2:9001 Instance of Application~1 (when v1.0.3)
  • 104. Routing 104 API Service Discovery Instance of Service~1 v1.0.5 API Registry 10.0.0.1:9001 v1.0.3 Manifest Subscription { “applicationName": "Application~1", "endpoints": [ { "method": "...", "host": "...", "urlPathTemplate": "...", "apiSpecificationVersion": "1.0.3" } ] } [ { "ip": “10.0.0.1", "port": “9001", "apiSpecificationVersion": “1.0.3" } ] Router v1.1.0 Instance of Service~1 v1.1.2 10.0.0.2:9001 Instance of Application~1 (when v1.0.3)
  • 105. Routing 105 API Service Discovery Instance of Service~1 v1.0.5 API Registry 10.0.0.1:9001 v1.0.3 Manifest Subscription { “applicationName": "Application~1", "endpoints": [ { "method": "...", "host": "...", "urlPathTemplate": "...", "apiSpecificationVersion": "1.0.3" } ] } [ { "ip": “10.0.0.1", "port": “9001", "apiSpecificationVersion": “1.0.3" }, { "ip": “10.0.0.2", "port": “9001", "apiSpecificationVersion": “1.1.0" } ] Router Instance of Application~1 (when v1.0.3) v1.1.0 Instance of Service~1 v1.1.2 10.0.0.2:9001
  • 106. Routing 106 API Service Discovery Instance of Service~1 v1.0.5 API Registry 10.0.0.1:9001 v1.0.3 Manifest Subscription { “applicationName": "Application~1", "endpoints": [ { "method": "...", "host": "...", "urlPathTemplate": "...", "apiSpecificationVersion": "1.0.3" } ] } [ { "ip": “10.0.0.1", "port": “9001", "apiSpecificationVersion": “1.0.3" }, { "ip": “10.0.0.2", "port": “9001", "apiSpecificationVersion": “1.1.0" } ] Router Instance of Application~1 (when v1.0.3) v1.1.0 Instance of Service~1 v1.1.2 10.0.0.2:9001
  • 107. Routing 107 Instance of Service~1 v1.1.2 API Service Discovery Instance of Service~1 v1.0.5 API Registry 10.0.0.1:9001 10.0.0.2:9001 v1.0.3 v1.1.0 Manifest
  • 108. Routing 108 Application~2 Instance of Service~1 v1.1.2 API Service Discovery Instance of Service~1 v1.0.5 API Registry 10.0.0.1:9001 10.0.0.2:9001 v1.0.3 v1.1.0 Manifest
  • 109. Routing 109 Application~2 (when v1.1.0) Instance of Service~1 v1.1.2 API Service Discovery Instance of Service~1 v1.0.5 API Registry 10.0.0.1:9001 10.0.0.2:9001 v1.0.3 v1.1.0 Manifest Subscription
  • 110. Routing 110 Application~2 (when v1.1.0) Instance of Service~1 v1.1.2 API Service Discovery Instance of Service~1 v1.0.5 API Registry 10.0.0.1:9001 10.0.0.2:9001 v1.0.3 v1.1.0 Manifest Subscription { “applicationName": "Application~2", "endpoints": [ { "method": "...", "host": "...", "urlPathTemplate": "...", "apiSpecificationVersion": "1.1.0" } ] }
  • 111. Routing 111 Application~2 (when v1.1.0) Instance of Service~1 v1.1.2 API Service Discovery Instance of Service~1 v1.0.5 API Registry 10.0.0.1:9001 10.0.0.2:9001 v1.0.3 v1.1.0 Manifest Subscription
  • 112. Routing 112 Router Instance of Service~1 v1.1.2 API Service Discovery Instance of Service~1 v1.0.5 10.0.0.1:9001 10.0.0.2:9001 v1.0.3 v1.1.0 API Registry Instance of Application~2 (when v1.1.0) Manifest Subscription
  • 113. Routing 113 Router Instance of Service~1 v1.1.2 API Service Discovery Instance of Service~1 v1.0.5 10.0.0.1:9001 10.0.0.2:9001 v1.0.3 v1.1.0 API Registry Instance of Application~2 (when v1.1.0) Manifest Subscription
  • 114. Routing 114 Router Instance of Service~1 v1.1.2 API Service Discovery Instance of Service~1 v1.0.5 10.0.0.1:9001 10.0.0.2:9001 v1.0.3 v1.1.0 { “applicationName": "Application~2", "endpoints": [ { "method": "...", "host": "...", "urlPathTemplate": "...", "apiSpecificationVersion": "1.1.0" } ] } API Registry Instance of Application~2 (when v1.1.0) Manifest Subscription
  • 115. Routing 115 Router Instance of Service~1 v1.1.2 API Service Discovery Instance of Service~1 v1.0.5 10.0.0.1:9001 10.0.0.2:9001 v1.0.3 v1.1.0 { “applicationName": "Application~2", "endpoints": [ { "method": "...", "host": "...", "urlPathTemplate": "...", "apiSpecificationVersion": "1.1.0" } ] } API Registry Instance of Application~2 (when v1.1.0) Manifest Subscription
  • 116. Routing 116 Router Instance of Service~1 v1.1.2 API Service Discovery Instance of Service~1 v1.0.5 10.0.0.1:9001 10.0.0.2:9001 v1.0.3 v1.1.0 { “applicationName": "Application~2", "endpoints": [ { "method": "...", "host": "...", "urlPathTemplate": "...", "apiSpecificationVersion": "1.1.0" } ] } [ { "ip": “10.0.0.1", "port": “9001", "apiSpecificationVersion": “1.0.3" }, { "ip": “10.0.0.2", "port": “9001", "apiSpecificationVersion": “1.1.0" } ] API Registry Instance of Application~2 (when v1.1.0) Manifest Subscription
  • 117. Routing 117 Router Instance of Service~1 v1.1.2 API Service Discovery Instance of Service~1 v1.0.5 10.0.0.1:9001 10.0.0.2:9001 v1.0.3 v1.1.0 { “applicationName": "Application~2", "endpoints": [ { "method": "...", "host": "...", "urlPathTemplate": "...", "apiSpecificationVersion": "1.1.0" } ] } [ { "ip": “10.0.0.1", "port": “9001", "apiSpecificationVersion": “1.0.3" }, { "ip": “10.0.0.2", "port": “9001", "apiSpecificationVersion": “1.1.0" } ] API Registry Instance of Application~2 (when v1.1.0) Manifest Subscription
  • 118. Routing 118 Router Instance of Service~1 v1.1.2 API Service Discovery Instance of Service~1 v1.0.5 10.0.0.1:9001 10.0.0.2:9001 v1.0.3 v1.1.0 { “applicationName": "Application~2", "endpoints": [ { "method": "...", "host": "...", "urlPathTemplate": "...", "apiSpecificationVersion": "1.1.0" } ] } [ { "ip": “10.0.0.1", "port": “9001", "apiSpecificationVersion": “1.0.3" }, { "ip": “10.0.0.2", "port": “9001", "apiSpecificationVersion": “1.1.0" } ] API Registry Instance of Application~2 (when v1.1.0) Manifest Subscription
  • 119. Routing 119 Router Instance of Service~1 v1.1.2 API Service Discovery Instance of Service~1 v1.0.5 10.0.0.1:9001 10.0.0.2:9001 v1.0.3 v1.1.0 { “applicationName": "Application~2", "endpoints": [ { "method": "...", "host": "...", "urlPathTemplate": "...", "apiSpecificationVersion": "1.1.0" } ] } [ { "ip": “10.0.0.1", "port": “9001", "apiSpecificationVersion": “1.0.3" }, { "ip": “10.0.0.2", "port": “9001", "apiSpecificationVersion": “1.1.0" } ] API Registry Instance of Application~2 (when v1.1.0) Manifest Subscription
  • 121. • Make an explicit distinction between API (endpoints) and services Summary 121
  • 122. • Make an explicit distinction between API (endpoints) and services Summary 122
  • 123. • Make an explicit distinction between API (endpoints) and services • Use semantic versioning for both API specifications (OpenAPI/Swagger) and services Summary 123
  • 124. • Make an explicit distinction between API (endpoints) and services • Use semantic versioning for both API specifications (OpenAPI/Swagger) and services • Make an explicit link between service and API endpoints within a manifest* Summary 124
  • 125. • Make an explicit distinction between API (endpoints) and services • Use semantic versioning for both API specifications (OpenAPI/Swagger) and services • Make an explicit link between service and API endpoints within a manifest* • Register instances at run-time by sending the manifest to API Service Discovery • Get the physical addresses of your running services (instances) via API Service Discovery Summary 125
  • 126. • Make an explicit distinction between API (endpoints) and services • Use semantic versioning for both API specifications (OpenAPI/Swagger) and services • Make an explicit link between service and API endpoints within a manifest* • Register instances at run-time by sending the manifest to API Service Discovery • Get the physical addresses of your running services (instances) via API Service Discovery • Request explicit subscriptions to API endpoints at design-time, and store them in API Registry • Make subscriptions available at run-time with peer-tokens* Summary 126
  • 127. • Make an explicit distinction between API (endpoints) and services • Use semantic versioning for both API specifications (OpenAPI/Swagger) and services • Make an explicit link between service and API endpoints within a manifest* • Register instances at run-time by sending the manifest to API Service Discovery • Get the physical addresses of your running services (instances) via API Service Discovery • Request explicit subscriptions to API endpoints at design-time, and store them in API Registry • Make subscriptions available at run-time with peer-tokens* • Let the (client-side) router make a wise decision about which instance to call by combining information coming from API Registry and API Service Discovery * The structure of a manifest and a peer-token is the same – exploit the symmetry – and, for both, the trick is to remember/store the version of API specification ;-) Summary 127
  • 128. • Make an explicit distinction between API (endpoints) and services • Use semantic versioning for both API specifications (OpenAPI/Swagger) and services • Make an explicit link between service and API endpoints within a manifest* • Register instances at run-time by sending the manifest to API Service Discovery • Get the physical addresses of your running services (instances) via API Service Discovery • Request explicit subscriptions to API endpoints at design-time, and store them in API Registry • Make subscriptions available at run-time with peer-tokens* • Let the (client-side) router make a wise decision about which instance to call by combining information coming from API Registry and API Service Discovery * The structure of a manifest and a peer-token is the same – exploit the symmetry – and, for both, the trick is to remember/store the version of API specification ;-) Summary 128
  • 129. • Make an explicit distinction between API (endpoints) and services • Use semantic versioning for both API specifications (OpenAPI/Swagger) and services • Make an explicit link between service and API endpoints within a manifest* • Register instances at run-time by sending the manifest to API Service Discovery • Get the physical addresses of your running services (instances) via API Service Discovery • Request explicit subscriptions to API endpoints at design-time, and store them in API Registry • Make subscriptions available at run-time with peer-tokens* • Let the (client-side) router make a wise decision about which instance to call by combining information coming from API Registry and API Service Discovery * The structure of a manifest and a peer-token is the same – exploit the symmetry – and, for both, the trick is to remember/store the version of API specification ;-) • Extend this technique to Confidence Check and A/B testing, it’s a unified way to handle any special routing mechanisms you want to implement ;-) Summary 129
  • 130. • Make an explicit distinction between API (endpoints) and services Summary 130
  • 131. • Make an explicit distinction between API (endpoints) and services • Make an explicit distinction between the interface and the code Summary 131 Click to edit Master title style
  • 132. API Versioning, DON’T bother your consumers with it ;-) Thank You! Patrice Krakow, Lead Architect, APIs, ING https://www.linkedin.com/in/patricekrakow/ @patricekrakow
  • 133. API Versioning, DON’T bother your consumers with it ;-) Thank You! Patrice Krakow, Lead Architect, APIs, ING https://www.linkedin.com/in/patricekrakow/ @patricekrakow
  • 134. API Versioning, DON’T bother your consumers with it ;-) Thank You! Patrice Krakow, Lead Architect, APIs, ING https://www.linkedin.com/in/patricekrakow/ @patricekrakow