Versioning in a microservice architecture

Versioning in a Microservice
Architecture
Stephan Schulze | 5 April 2019

Contact with me
Email
stephan.schulze@project-a.com
Twitter
twitter.com/nahpeps
LinkedIn
linkedin.com/in/stephan-schulze-24115957/
Website
www.project-a.com
2
Stephan Schulze
CTO - Project A
Talk to me
Everytime at this conference

Project A - The operational VC
We empower tomorrow’s digital winners - www.project-a.com
The fund:
260mio
Assets under management
The people:
100
hands-on professionals
3
Stephan Schulze - @nahpeps | 5 April 2019

4
This talk buzzwords about
Versioning, APIs, Datastructures and Microservices

Thinking of and
introducing a proper versioning and
dependency management early, will
may save your life.
5

What is a Microservice?
6

What is a microservice?
At least in the scope of this talk
7
▪ There is an isolated vertical
infrastructure per service
▪ Communication happens via APIs
only
▪ A service can provide different
frontends (e.g. Customer Facing
and Backoffice)
▪ Each service serves a specific
business domain/need
Frontend
Backend
Application
Infrastructure DB Queues Webserver
API API API
FE 1 FE 2
Microservice

8
Let’s see a more complex
complete picture

Microservice based application
You have many services
9

Service2Service Communication
To provide functionality, they will talk to each other
10

Frontend
People want to see something
11

Frontend composition
Multiple Services contributing to single Frontend Pages
12

Naming the things
13
Backend Layer
Frontend Layer
Infrastructure Layer

This is what we call an application
14
Frontend Layer
Backend Layer
Product/A
pplication

15
What should we version?

Versioning within a Microservice
16
Microservice
Frontend
Backend
Application
API API API
FE 1 FE 2
V V V
V
V
V V
V
VV
V
▪ Every Layer has components with independent versioning (Code, Infrastructure component, Libraries, etc.)
▪ The combination of Versions within a Layer, results in a Version for that Layer
▪ The combination of Versions of Layers, results in a Version for the Microservice itself
▪ This all can be seen as a vector that exactly describes the Microservice itself
V

What is this Microservice Vector?
17
DB: 11.1.2
WS: 2.4.5
...
r-36
Bundle A - 1.5.4
Bundle ...
App Code ...
r-15
Other Service Client - 1.4
FE Component A - 1.3.7
FE Component B - 3.6.1
FE Component ...
r-17
r-164

Seeing it in larger scale
This are just eight microservices
18
DB: 11.1.2
WS: 2.4.5
...
r-3
6
Bundle A - 1.5.4
Bundle ...
App Code ...
r-15
FE Component ...
r-17
r-16
4
DB: 11.1.2
WS: 2.4.5
...
r-3
6
Bundle A - 1.5.4
Bundle ...
App Code ...
r-15
FE Component ...
r-17
r-16
4
DB: 11.1.2
WS: 2.4.5
...
r-3
6
Bundle A - 1.5.4
Bundle ...
App Code ...
r-15
FE Component ...
r-17
r-16
4
DB: 11.1.2
WS: 2.4.5
...
r-3
6
Bundle A - 1.5.4
Bundle ...
App Code ...
r-15
FE Component ...
r-17
r-16
4
DB: 11.1.2
WS: 2.4.5
...
r-3
6
Bundle A - 1.5.4
Bundle ...
App Code ...
r-15
FE Component ...
r-17
r-16
4
DB: 11.1.2
WS: 2.4.5
...
r-3
6
Bundle A - 1.5.4
Bundle ...
App Code ...
r-15
FE Component ...
r-17
r-16
4
Application Vector:
{
“Service 1”: “r-19”,
“Service 2”: “r-176”,
...
“Service n”: “r-n”
}
This combination is actually
a working setup of your
application
Hopefully!
DB: 11.1.2
WS: 2.4.5
...
r-3
6
Bundle A - 1.5.4
Bundle ...
App Code ...
r-15
FE Component ...
r-17
r-16
4
DB: 11.1.2
WS: 2.4.5
...
r-3
6
Bundle A - 1.5.4
Bundle ...
App Code ...
r-15
FE Component ...
r-17
r-16
4

Dangerous if invisible - APIs
19
Microservice
Frontend
Backend
Application
API API API
FE 1 FE 2
V V V
V
V
V V
V
V
▪ Frontend: is providing and using a “Frontend API” ⇒ Hello Dependency!
▪ Backend: is maybe using external APIs and/or providing APIs to externals ⇒ Hello Dependency!
▪ Having dependencies is necessary but makes your live much harder
V
V

20
Broken dependencies
will break your system

The problem with external dependencies
21
▪ You don’t who uses them ⇒ just deleting e.g. an API version is not an option
▪ You have no control about them
▪ To introduce BC Breaks in an API you must somehow maintain multiple versions of the same API
▪ This can be everything from super easy to hell

22
An example

Example - A service with a very simple API
23
DB
API - /customer/create - 1.0.0
persist Customer
{
“email”: “mandatory”,
“firstname”: “optional”,
“lastname”: “optional”
}

24
Marketing says:
Let’s send a welcome mail!

You say: No problem!
Services are in place already!
25
Customer ServiceEmail Service

Adding a dependency to another service is easy
Maintaining this dependency is not
26
DB
persist Customer
{
“firstname”: “optional”,
“lastname”: “optional”
}
{
“firstname”: “mandatory”,
“lastname”: “mandatory”
}
▪ You become user of another external service
/mail/send -
1.0
{
“firstname”: “mandatory”,
“lastname”: “mandatory”,
“type”: “customer_welcome”
}
▪ This affects your API (because of requirements of the new service)
▪ You have no idea, who is using your “old” API ⇒ so you will have to support two APIs for a while

27
This is a ticking bomb!

28
How could you avoid this?

A solution approach
Creating machine readable transparency
29
Offering Service
▪ That information could be validated
during/before a deployment process
▪ Deployments will fail, if they would
remove an API that is still in usage
Consumer Service 1
Consumer Service 2

30
Whatever you do:
You must know your
Dependency Graph

31
Datastructures

You are not alone!
Seeing your application embedded in a larger IT Landscape
32
Frontend Layer
Backend Layer
Product/A
pplication
Products {
“Product”: “Data”
}
Stock
{
“Stock”: “Data”
}
Prices
{
“Price”: “Data”
}
ERP
{
“Order”: “Data”
}

RPC based communication
Endpoints are called and data is submitted
33

The version of an API Endpoint
defines how the Datastructure
must look like.
34

Event based communication
Datastructures are communicated via e.g. Queues, PubSub or via EventStreaming
35
Queues

Define a Datastructure as an API!
If you have no versioned Endpoint
doing the validation,
you must version the Datastructure itself!
36

Versioning Datastructures
Every versioning is ok, unless you version your documents in general!
37
Product Data Example Travel Data Example Order Data Example

38
Don’t forget:
You still must know your
Dependency Graph!

39
Frontend

Frontend composition
Multiple Services contributing to single Frontend Pages
40
FE-1FE-3FE-12

An example with different Frontend Versions
Concurrent versions
41
Customer Service Price Service

Service A
fe-components r-1
Service B
fe-components r-12
Service C
fe-components r-3
CSS* CSS* CSS*
Problems with multiple FE versions
Concurrent versions
42
JS*
JS
JS
JS
JS*
JS
JS
JS
JS*
JS
JS
JS
NOT PERFECT!

43
Conclusions

44
Under the Assumptions of
▪ Your Datastructures will change
▪ You don’t know who else is using your Datastructures or you don’t have control over them
▪ You want to be able to differentiate between two Datastructures of the same type
(e.g. Customer)
▪ You want to be able to survive a Datastructure change (especially BC breaks)

Thinking of and
introducing a proper versioning and
dependency management early, will
may save your life.
45

Thank you for listening.
Time for questions

Versioning in a microservice architecture

More Related Content

Similar to Versioning in a microservice architecture (20)

Recently uploaded (20)

Versioning in a microservice architecture