SlideShare a Scribd company logo

A Journey from API Versioning to Canary Release | APIDays Zurich 2017

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

The document discusses the journey from API versioning to canary release, highlighting the tension between API providers who wish to implement changes quickly and consumers who prefer stability. It defines canary releases as a technique for safely rolling out software changes to a small user base first to mitigate risks. Additionally, it covers the meta-model for APIs, emphasizing the importance of semantic versioning in communicating changes and maintaining compatibility.

Software
1 of 131
Downloaded 16 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
A Journey from API Versioning to Canary Release Patrice Krakow | ING | Lead Architect | APIs APIDays Zurich - API Economy and Microservices Zurich | 2017, September 27 (1.5.0)
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
API Providers want to change their APIs as soon as they have a new brilliant idea Why? 6
API Providers want to change their APIs as soon as they have a new brilliant idea vs. API Consumers 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? 7
API Providers want to change their APIs as soon as they have a new brilliant idea API Consumers 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? 8
API Providers want to change their APIs as soon as they have a new brilliant idea vs. API Consumers 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 want to change their APIs as soon as they have a new brilliant idea vs. API Consumers 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
Canary 11
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 12
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 13
Canary Release 14 Application~1 Router Instance of Service~1 v1.0.0
Canary Release 15 Application~1 Router Instance of Service~1 v1.1.0 Instance of Service~1 v1.0.0
Canary Release 16 Application~1 Router Instance of Service~1 v1.1.0 Instance of Service~1 v1.0.0 100% 10% 90%
Canary Release 17 Application~1 Router Instance of Service~1 v1.1.0 Instance of Service~1 v1.0.0 100% 50% 50%
Canary Release 18 Application~1 Router Instance of Service~1 v1.1.0 Instance of Service~1 v1.0.0 100% 90% 10%
Canary Release 19 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 20
• 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. 21 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. 22 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. 23 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. 24 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. 25 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. 26 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. 27 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. 28 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. 29 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. 30 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 31
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 32
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 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. 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 34
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 35
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 36
API Gateway 37
API Gateway 38 Outside Inside
API Gateway 39 Outside Inside
API Gateway 40 Outside Inside Office
API Gateway 41 Outside Inside Office
API Gateway 42 Outside Inside Office API Gateway on the external edge
API Gateway 43 Outside Inside Office API Gateway on the external edge API Gateway on the internal edge
API Service Discovery and Client-Side Load Balancing 44 API Service Discovery
API Service Discovery and Client-Side Load Balancing 45 API Service Discovery Instance of Service~1 10.0.0.1:9001
API Service Discovery and Client-Side Load Balancing 46 API Service Discovery Instance of Service~1 10.0.0.1:9001 Application~1
API Service Discovery and Client-Side Load Balancing 47 Router API Service Discovery Instance of Service~1 10.0.0.1:9001 Application~1
API Service Discovery and Client-Side Load Balancing 48 Router 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 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 51 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 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
API Service Discovery and Client-Side Load Balancing 54
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 55
The Manifest 56 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. The Manifest 57 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 58 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 59 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 60
When a software package wants to call an API endpoint, it has first to declare its intention to do so. Subscription and Peer Token 61 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 62 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 approved. Subscription and Peer Token 63 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 64
{ "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 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 66
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 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) 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 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) 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 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) 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 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 API Registry and API Service Discovery ;-) Routing 72
Routing 73
Routing 74 v1.0.3
Routing 75 v1.0.3 swagger: '2.0‘ info: title: My API version: 1.0.3 ...
Routing 76 API Registry v1.0.3 swagger: '2.0‘ info: title: My API version: 1.0.3 ...
Routing 77 API Registry v1.0.3
Routing 78 Service~1 API Registry v1.0.3
Routing 79 Service~1 API Registry v1.0.3 Manifest
Routing 80 Service~1 API Registry v1.0.3 { "serviceName": "Service~1", "endpoints": [ { "method": "...", "host": "...", "urlPathTemplate": "...", "apiSpecificationVersion": "1.0.3" } ] } Manifest
Routing 81 Service~1 API Registry v1.0.3 Manifest
Routing 82 Instance of Service~1 v1.0.5 API Registry 10.0.0.1:9001 v1.0.3 Manifest
Routing 83 API Service Discovery 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 { "ip": "10.0.0.1:9001", "port": "9001" }
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", "manifest": { "serviceName": "Service~1", "endpoints": [ { "method": "...", "host": "...", "urlPathTemplate": "...", "apiSpecificationVersion": "1.0.3" } ] } }
Routing 86 API Service Discovery Instance of Service~1 v1.0.5 API Registry 10.0.0.1:9001 v1.0.3 Manifest
Routing 87 Application~1 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 (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 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 { “applicationName": "Application~1", "endpoints": [ { "method": "...", "host": "...", "urlPathTemplate": "...", "apiSpecificationVersion": "1.0.3" } ] }
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
Routing 91 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 92 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 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 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 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 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 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" } ] Instance of Application~1 (when v1.0.3) Router
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" } ] Router Instance of Application~1 (when v1.0.3)
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 v1.1.0 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 Service~1 v1.1.2 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 Instance of Service~1 v1.1.2 10.0.0.2:9001 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" }, { "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 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 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 107 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 108 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 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 { “applicationName": "Application~2", "endpoints": [ { "method": "...", "host": "...", "urlPathTemplate": "...", "apiSpecificationVersion": "1.1.0" } ] }
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
Routing 111 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 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 { “applicationName": "Application~2", "endpoints": [ { "method": "...", "host": "...", "urlPathTemplate": "...", "apiSpecificationVersion": "1.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" } ] } [ { "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 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
Summary 119
• Make an explicit distinction between API (endpoints) and services Summary 120
• Make an explicit distinction between API (endpoints) and services Summary 121
• Make an explicit distinction between API (endpoints) and services • Use semantic versioning for both API specifications (OpenAPI/Swagger) and services Summary 122
• 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 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* • 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 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 • 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 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* • 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 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 ;-) • 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 128
• Make an explicit distinction between API (endpoints) and services Summary 129
• Make an explicit distinction between API (endpoints) and services • Make an explicit distinction between the interface and the code Summary 130
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
Speech to text software
RDI Egypt
 
PDF
API Testing: Answers to Your Top 3 Questions
QASource
 
PPTX
Tech Days 2015: Ada 2012 and Spark Crazyflie and Railway Demo
AdaCore
 
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
 
Speech to text software
RDI Egypt
 
API Testing: Answers to Your Top 3 Questions
QASource
 
Tech Days 2015: Ada 2012 and Spark Crazyflie and Railway Demo
AdaCore
 
Raml part 1
venkata20k
 
Ad

Similar to A Journey from API Versioning to Canary Release | APIDays Zurich 2017 (20)

PPTX
A Journey from API Versioning to Canary Release | Nordic APIs Platform Summit...
Patrice Krakow
 
PPTX
API Versioning for Zero Downtime | Devoxx Belgium 2017
Patrice Krakow
 
PDF
Apicurio Registry: Event-driven APIs & Schema governance for Apache Kafka | F...
HostedbyConfluent
 
PDF
apidays LIVE Hong Kong 2021 - Multi-Protocol APIs at Scale in Adidas by Jesus...
apidays
 
PPTX
mulesoft birmingham meetup_api_designing_with_raml
mohammadsakifuddin
 
PDF
RefCard API Architecture Strategy
OCTO Technology
 
PDF
Practices and tools for building better API (JFall 2013)
Peter Hendriks
 
PDF
Practices and tools for building better APIs
NLJUG
 
PPTX
API Conference 2021
José Haro Peralta
 
PDF
Schema-First API Design
Yos Riady
 
PDF
Extend soa with api management Sangam18
Vinay Kumar
 
PPTX
API Documentation.pptx
RahulCR31
 
PPTX
API Documentation.pptx
RahulCR31
 
PPTX
Api design part 1
Ibrahim Elsawaf
 
PDF
Highlights of WSO2 API Manager 4.0.0
WSO2
 
PPT
How to design effective APIs
Bansilal Haudakari
 
PDF
Best practices and advantages of REST APIs
Aparna Sharma
 
PDF
Extend soa with api management Doag18
Vinay Kumar
 
PPTX
REST-API's for architects and managers
Patrick Savalle
 
PDF
Gateway APIs, Envoy Gateway, and API Gateways
Matt Turner
 
A Journey from API Versioning to Canary Release | Nordic APIs Platform Summit...
Patrice Krakow
 
API Versioning for Zero Downtime | Devoxx Belgium 2017
Patrice Krakow
 
Apicurio Registry: Event-driven APIs & Schema governance for Apache Kafka | F...
HostedbyConfluent
 
apidays LIVE Hong Kong 2021 - Multi-Protocol APIs at Scale in Adidas by Jesus...
apidays
 
mulesoft birmingham meetup_api_designing_with_raml
mohammadsakifuddin
 
RefCard API Architecture Strategy
OCTO Technology
 
Practices and tools for building better API (JFall 2013)
Peter Hendriks
 
Practices and tools for building better APIs
NLJUG
 
API Conference 2021
José Haro Peralta
 
Schema-First API Design
Yos Riady
 
Extend soa with api management Sangam18
Vinay Kumar
 
API Documentation.pptx
RahulCR31
 
API Documentation.pptx
RahulCR31
 
Api design part 1
Ibrahim Elsawaf
 
Highlights of WSO2 API Manager 4.0.0
WSO2
 
How to design effective APIs
Bansilal Haudakari
 
Best practices and advantages of REST APIs
Aparna Sharma
 
Extend soa with api management Doag18
Vinay Kumar
 
REST-API's for architects and managers
Patrick Savalle
 
Gateway APIs, Envoy Gateway, and API Gateways
Matt Turner
 
Ad

Recently uploaded (20)

PDF
MiniTool Power Data Recovery Crack New Pre Activated Version Latest 2025
imang66g
 
PPTX
Contractor Management Platform and Software Solution for Compliance
SHEQ Network Limited
 
PPTX
Presentation about variables and constant.pptx
safalsingh810
 
PPTX
ASSIGNMENT_1[1][1][1][1][1] (1) variables.pptx
kr2589474
 
PPTX
classification of computer and basic part of digital computer
ravisinghrajpurohit3
 
PDF
49784907924775488180_LRN2959_Data_Pump_23ai.pdf
Abilash868456
 
PDF
Summary Of Odoo 18.1 to 18.4 : The Way For Odoo 19
CandidRoot Solutions Private Limited
 
PPT
Activate_Methodology_Summary presentatio
annapureddyn
 
PPTX
ConcordeApp: Engineering Global Impact & Unlocking Billions in Event ROI with AI
chastechaste14
 
PPTX
Can You Build Dashboards Using Open Source Visualization Tool.pptx
Varsha Nayak
 
PDF
Immersive experiences: what Pharo users do!
ESUG
 
PDF
49785682629390197565_LRN3014_Migrating_the_Beast.pdf
Abilash868456
 
PDF
New Download FL Studio Crack Full Version [Latest 2025]
imang66g
 
DOCX
Can You Build Dashboards Using Open Source Visualization Tool.docx
Varsha Nayak
 
PDF
Download iTop VPN Free 6.1.0.5882 Crack Full Activated Pre Latest 2025
imang66g
 
PDF
Key Features to Look for in Arizona App Development Services
Net-Craft.com
 
PDF
Salesforce Implementation Services Provider.pdf
VALiNTRY360
 
PDF
Exploring AI Agents in Process Industries
amoreira6
 
PDF
An Experience-Based Look at AI Lead Generation Pricing, Features & B2B Results
Thomas albart
 
PDF
10 posting ideas for community engagement with AI prompts
Pankaj Taneja
 
MiniTool Power Data Recovery Crack New Pre Activated Version Latest 2025
imang66g
 
Contractor Management Platform and Software Solution for Compliance
SHEQ Network Limited
 
Presentation about variables and constant.pptx
safalsingh810
 
ASSIGNMENT_1[1][1][1][1][1] (1) variables.pptx
kr2589474
 
classification of computer and basic part of digital computer
ravisinghrajpurohit3
 
49784907924775488180_LRN2959_Data_Pump_23ai.pdf
Abilash868456
 
Summary Of Odoo 18.1 to 18.4 : The Way For Odoo 19
CandidRoot Solutions Private Limited
 
Activate_Methodology_Summary presentatio
annapureddyn
 
ConcordeApp: Engineering Global Impact & Unlocking Billions in Event ROI with AI
chastechaste14
 
Can You Build Dashboards Using Open Source Visualization Tool.pptx
Varsha Nayak
 
Immersive experiences: what Pharo users do!
ESUG
 
49785682629390197565_LRN3014_Migrating_the_Beast.pdf
Abilash868456
 
New Download FL Studio Crack Full Version [Latest 2025]
imang66g
 
Can You Build Dashboards Using Open Source Visualization Tool.docx
Varsha Nayak
 
Download iTop VPN Free 6.1.0.5882 Crack Full Activated Pre Latest 2025
imang66g
 
Key Features to Look for in Arizona App Development Services
Net-Craft.com
 
Salesforce Implementation Services Provider.pdf
VALiNTRY360
 
Exploring AI Agents in Process Industries
amoreira6
 
An Experience-Based Look at AI Lead Generation Pricing, Features & B2B Results
Thomas albart
 
10 posting ideas for community engagement with AI prompts
Pankaj Taneja
 

A Journey from API Versioning to Canary Release | APIDays Zurich 2017

  • 1. A Journey from API Versioning to Canary Release Patrice Krakow | ING | Lead Architect | APIs APIDays Zurich - API Economy and Microservices Zurich | 2017, September 27 (1.5.0)
  • 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
  • 6. API Providers want to change their APIs as soon as they have a new brilliant idea Why? 6
  • 7. API Providers want to change their APIs as soon as they have a new brilliant idea vs. API Consumers 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? 7
  • 8. API Providers want to change their APIs as soon as they have a new brilliant idea API Consumers 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? 8
  • 9. API Providers want to change their APIs as soon as they have a new brilliant idea vs. API Consumers 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
  • 10. API Providers want to change their APIs as soon as they have a new brilliant idea vs. API Consumers 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
  • 12. 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 12
  • 13. 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 13
  • 15. Canary Release 15 Application~1 Router Instance of Service~1 v1.1.0 Instance of Service~1 v1.0.0
  • 16. Canary Release 16 Application~1 Router Instance of Service~1 v1.1.0 Instance of Service~1 v1.0.0 100% 10% 90%
  • 17. Canary Release 17 Application~1 Router Instance of Service~1 v1.1.0 Instance of Service~1 v1.0.0 100% 50% 50%
  • 18. Canary Release 18 Application~1 Router Instance of Service~1 v1.1.0 Instance of Service~1 v1.0.0 100% 90% 10%
  • 19. Canary Release 19 Application~1 Router Instance of Service~1 v1.1.0 Instance of Service~1 v1.0.0 100% 100%
  • 21. • 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. 21 Meta-Model and Terminology for APIs Service API
  • 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. 22 Meta-Model and Terminology for APIs Service API
  • 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 API endpoint Service API
  • 24. • 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. 24 Meta-Model and Terminology for APIs API endpoint Service API
  • 25. • 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. 25 Meta-Model and Terminology for APIs API endpoint API specification 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 API specification 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 Service version 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 Service version Instance 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 Xs.Ys.Zs Instance 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 Xa.Ya.Za Service Service version Xs.Ys.Zs Instance API
  • 31. 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 31
  • 32. 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 32
  • 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. 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 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. 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 34
  • 35. 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 35
  • 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 36
  • 42. API Gateway 42 Outside Inside Office API Gateway on the external edge
  • 43. API Gateway 43 Outside Inside Office API Gateway on the external edge API Gateway on the internal edge
  • 44. API Service Discovery and Client-Side Load Balancing 44 API Service Discovery
  • 45. API Service Discovery and Client-Side Load Balancing 45 API Service Discovery Instance of Service~1 10.0.0.1:9001
  • 46. API Service Discovery and Client-Side Load Balancing 46 API Service Discovery Instance of Service~1 10.0.0.1:9001 Application~1
  • 47. API Service Discovery and Client-Side Load Balancing 47 Router API Service Discovery Instance of Service~1 10.0.0.1:9001 Application~1
  • 48. API Service Discovery and Client-Side Load Balancing 48 Router 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 Instance of Service~1 API Service Discovery Instance of Service~1 10.0.0.1:9001 10.0.0.2:9001 Application~1
  • 51. API Service Discovery and Client-Side Load Balancing 51 Router Instance of Service~1 API Service Discovery Instance of Service~1 10.0.0.1:9001 10.0.0.2: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
  • 54. API Service Discovery and Client-Side Load Balancing 54
  • 55. 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 55
  • 56. The Manifest 56 API endpoint API specification Xa.Ya.Za Service Service version Xs.Ys.Zs Instance API
  • 57. Within our organization, we want to control which service is implementing which part of an API. The Manifest 57 API endpoint API specification Xa.Ya.Za Service Service version Xs.Ys.Zs Instance API
  • 58. 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 58 API endpoint API specification Xa.Ya.Za Service Service version Xs.Ys.Zs Instance API Manifest
  • 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. 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 59 API endpoint API specification Xa.Ya.Za Service Service version Xs.Ys.Zs Instance API Manifest
  • 60. { "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 60
  • 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 61 API endpoint API specification Xa.Ya.Za Service Service version Xs.Ys.Zs Instance API
  • 62. 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 62 API endpoint API specification Xa.Ya.Za Service Service version Xs.Ys.Zs Instance API SubscriptionApplication
  • 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. 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 approved. Subscription and Peer Token 63 API endpoint API specification Xa.Ya.Za Service Service version Xs.Ys.Zs Instance API SubscriptionApplication
  • 64. { "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 64
  • 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 This is the exact same structure as the manifest ;-)
  • 66. 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 66
  • 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 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) 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 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) 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 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) 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 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 API Registry and API Service Discovery ;-) Routing 72
  • 80. Routing 80 Service~1 API Registry v1.0.3 { "serviceName": "Service~1", "endpoints": [ { "method": "...", "host": "...", "urlPathTemplate": "...", "apiSpecificationVersion": "1.0.3" } ] } Manifest
  • 82. Routing 82 Instance of Service~1 v1.0.5 API Registry 10.0.0.1:9001 v1.0.3 Manifest
  • 83. Routing 83 API Service Discovery 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 { "ip": "10.0.0.1:9001", "port": "9001" }
  • 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", "manifest": { "serviceName": "Service~1", "endpoints": [ { "method": "...", "host": "...", "urlPathTemplate": "...", "apiSpecificationVersion": "1.0.3" } ] } }
  • 86. Routing 86 API Service Discovery Instance of Service~1 v1.0.5 API Registry 10.0.0.1:9001 v1.0.3 Manifest
  • 87. Routing 87 Application~1 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 (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
  • 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 { “applicationName": "Application~1", "endpoints": [ { "method": "...", "host": "...", "urlPathTemplate": "...", "apiSpecificationVersion": "1.0.3" } ] }
  • 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
  • 91. Routing 91 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
  • 92. Routing 92 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
  • 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 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)
  • 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 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)
  • 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" } ] Instance of Application~1 (when v1.0.3) Router
  • 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" } ] Router Instance of Application~1 (when v1.0.3)
  • 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 v1.1.0 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 Service~1 v1.1.2 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 Instance of Service~1 v1.1.2 10.0.0.2:9001 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" }, { "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
  • 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 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
  • 107. Routing 107 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
  • 108. Routing 108 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
  • 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 { “applicationName": "Application~2", "endpoints": [ { "method": "...", "host": "...", "urlPathTemplate": "...", "apiSpecificationVersion": "1.1.0" } ] }
  • 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
  • 111. Routing 111 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
  • 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 { “applicationName": "Application~2", "endpoints": [ { "method": "...", "host": "...", "urlPathTemplate": "...", "apiSpecificationVersion": "1.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" } ] } [ { "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
  • 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
  • 120. • Make an explicit distinction between API (endpoints) and services Summary 120
  • 121. • Make an explicit distinction between API (endpoints) and services Summary 121
  • 122. • Make an explicit distinction between API (endpoints) and services • Use semantic versioning for both API specifications (OpenAPI/Swagger) 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 • Make an explicit link between service and API endpoints within a manifest* 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* • 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 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 • 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 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* • 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 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 ;-) • 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 128
  • 129. • Make an explicit distinction between API (endpoints) and services Summary 129
  • 130. • Make an explicit distinction between API (endpoints) and services • Make an explicit distinction between the interface and the code Summary 130
  • 131. Thank You! Patrice Krakow, Lead Architect, APIs, ING https://www.linkedin.com/in/patricekrakow/ @patricekrakow