Microservices, Service Discovery and Registration have been heading towards the peak of inflated expectations on the Gartner Hype cycle for over the last year or so, but there has often been a lack of clarity as to what these are, why are they needed or how to implement them well.
Service discovery and registration are key components of most distributed systems and service oriented architectures. In this session we will talk about what, why and how of service registration and discovery in distributed systems in general and OpenStack in particular.
We will talk about some of the technologies that address this challenge like Zookeeper, Etcd, Consul, Mesos-DNS, Minuteman, SkyDNS, SmartStack or Eureka. We will also address how these technologies as well as existing OpenStack projects can be used to solve this problem inside OpenStack environments.
4. Part 1 - A bit of history
- DISCLAIMER
- Trying to provide context about the “what” and the “why”.
- Historically inaccurate
- Obviously and shamelessly biased
- A bit blurry…
- DISCLAIMER (2)
- This goes WAY BACK to provide context. I felt a bit OLD
making this presentation
- If you know what a v92 modem is, you probably will also feel
old listening to it.
5. A bit of history (1) : Service Registration in the early days
(Very) early days: applications living
on a single physical server
“Service Discovery”? = How do I find
my service “by name” when it really is
an IP address? Well… DNS!
1:1 relationship between the
Application and the backend
implementing it
6. A bit of history (2) : Service Registration in the early days
Early days: applications living on MANY physical servers
1:N relationship between Service IPs and backend Servers
Physical App Server “churn” was still “manageable”
“Service Discovery”?: DNS + Virtual IPs + Virtual Hosts
Need a Load Balancer!
“Service Registration” = When I add a new server to my service, how does it
get added to the list of available ”Service Backends”?
** Add a new backend to the Service IP/ Virtual IP in the load balancer
(“Service Access Point”)
** Many times, added manually by a guy who has a vendor certification.
** Including “healthchecks” for each backend
7. A bit of history (3) : Service Registration in the early days
- Advent of the 3-tier architecture (web, application, dB)
- Need load balancing in each layer so
that each can scale up/down
- With their respective healthchecks
- So each layer now has a “Service Registration
/ Service Discovery” need!
8. A bit of history (4) : Virtualization FTW
- Enter server virtualization: Web/App/dB Servers can be
created and destroyed in minutes.
- “Automated” Service Registration becomes an evident need
and options start to appear (we’ll discuss each in the 2nd part):
- “Sidecar process” in workloads to register into centralized “backend
database”?
- “External Orchestrator” registers backends upon creation?
- “API Gateways” with client or server-side discovery?
- Applications can scale up and down more dynamically, even
automatically depending on load
9. Enter Containerization!
Private Copy
Shared
App 3
Libraries
Guest
Operating
System
Infrastructure
App 1
Libs
Host Operating System
Start / stop time One minute to few seconds Milliseconds
Workload density 10 - 100x1x
App 2
Libraries
Guest
Operating
System
App 1
Libraries
Guest
Operating
System
App 2
Libs
App 3
Libs
Virtual Machines Containers
Host Operating System
Hypervisor
Infrastructure
App 4
Libs
App 5
Libs
10. Today: Containers and Container Orchestration
- Containers multiply the potential complexity:
can be created/destroyed in milliseconds, with
endpoints being one or more orders of
magnitude more numerous than VMs
- Impossible to have manual procedures: need
automatic discovery of backends
- All options mentioned for VMs may still be
considered, with their pros and cons:
- Sidecar, Centralized Orchestration, Client/Server
discovery…
11. From Containers to Microservices: What and Why?
“The Monolith” and its issues
- Traditional applications were typically developed
as a single unified codebase
- Which tends to grow along time
- Making it harder to maintain, troubleshoot, evolve
Microservices: divide and conquer!
- Divide applications into independent pieces
(typically functional areas)
- Interconnect the pieces with networking and
(REST) APIs
12. Microservices: Divide and Conquer
Traditional Architecture
Many functions
in a single process
Siloed
teams
RESTAPIs
Microservices Architecture
Cross-functional
teams organized
around capabilities
Scales
individually
Each element of
functionality defined as
“microservices”
Scales
monolithically
13. Microservices Challenge: SD/SR on steroids!
RESTAPIs
Dependencies Between Microservices Running Multiple Microservices-based Apps
14. SD/SR Evolution: from tiered architecture to usvcs
14
Before Micro-Services
10’s of services with well-defined endpoints
100’s of backends implementing them, with long duration
Secure Infrastructure with DMZ and Firewalling.
After Micro-Services
1000’s of services requiring new VIPs to talk to others
100000’s of backends that are created and destroyed
constantly, sometimes in milliseconds
1000’s of services requiring Auth handshakes
W W W
A AA
