microservices or new dress for the service emperor
TRANSCRIPT
New dress for the service emperor
…or what are microservices really good for
∗ Software development in more or less all roles since 1991
∗ I like to program in most languages ∗ Military systems (REAL systems :-‐) for about 10 years
∗ …in an international environment ∗ …where we amongst other things developed a Service Oriented Infrastructure
∗ …based on ideas like microservices
Me, myself and I
∗ A technology to solve all problems ∗ A flame bait for nerds ∗ The new new black ∗ All or nothing of the above
What are microservices?
∗ Understand what micro services are ∗ Showing examples ∗ Make You actively think when to use it ∗ Show dynamic configuration
Goal of presentation
String urlString = ”http://soa.com//service-call”; URL url = new URL(urlString);
Hardcoded?
Only works for really static systems!
Zero-‐configuration ∗ mDNS ∗ Apple Bonjour ∗ DNS/DNS-‐SD ∗ UPnP SSDP ∗ SLP
Other solutions ∗ Apache’s ZooKeeper ∗ Eureka ∗ etcd
Service Registry
The holy trinity
Producer Consumer
Serv
ice
Service Registry
From task to services
Ability 1
Ability 3
Ability 2
Service a
Service d
Service b
Service c
Task
10
Service a
Service d
Service b
Service c
1
3 4
6
5
7
8
9
11
12
2 The system is configured
Goal
Ability 1
Ability 3
Ability 2
Service a
Service d
Service b
Service c
10
1
3
4
6 7
8 9
11
12
2
Mgmt
Task
Difference SOA & Msg Passing
Producer ConsumerSe
rvic
e
Quality Location
∗Test ∗What to scale ∗When change ∗Re-‐use
Why micro services?
∗ 10 systems 99.9 => 99.0 ∗ 10 systems 99.0 => 90.4
On the other hand
∗ 30 systems 99.9 => 97.0 ∗ 30 systems 99.0 => 74.0
But, everybody does it!
Microservice envy
NEW ● Hold January 2015
We remain convinced that microservices can offer significant advantages to organizations, in terms of improving team autonomy and faster frequency of change. The additional complexity that comes from distributed systems requires an additional level of maturity and investment. We are concerned that some teams are rushing in to adopting microservices without understanding the changes to development, test, and operations that are required to do them well. Our general advice remains simple. Avoid microservice envy and start with one or two services before rushing headlong into developing more, to allow your teams time to adjust and understand the right level of granularity.
