Rob Davies presentation during Red Hat's "Microservices Journey with Apache Camel" that took place in Atlanta on 10/04/16 and in Minneapolis on 10/06/16.
2. 2
Rob Davies
• Director of Middleware Engineering for
iPaaS, Technical Director for Fuse
• Herd the fabric8 cats
• Over 20 years experience of developing
large scale solutions for telcos and
finance
• Creator of ActiveMQ and ServiceMix
• Committer on open source projects,
including fabric8, Apache Camel and
other stuff …
14. 14
Open Source community
Version 1.3.x
Hosted on GitHub
800+ contributors
34,000+ commits
16,000+ GitHub stars
Red Hat
HP
IBM
Mesosphere
Microsoft
Project Partners
CoreOS
Pivotal
SaltStack
VMWare
http://kubernetes.io/
https://github.com/kubernetes/kubernetes
18. 18
Red Hat Definition
“Microservices is an architectural approach, that
emphasizes the decomposition of applications into
single-purpose, loosely coupled services managed by
cross-functional teams, for delivering and maintaining
complex software systems with the velocity and quality
required by today’s digital business”
19. 19
What does that mean ?
Application is composed of multiple services
UNIX style – do one thing, and one thing well – in one
process.
Language agnostic
API is important
Organize teams around delivery of a service
20. 20
Microservices characteristics …
1. Deployment Independence - updates to an individual
microservice have no negative impact to any other component of
the system. Optimized for replacement
2. API Focused
3. Do one thing well - small enough and no smaller
4. Fit in your head
5. Decentralized Data Management
22. 22
Big Team, Big Effort, High Ceremony Deployment
Code offers no value until it survives in production
24 Weeks
Monolithic System
Business
Change
Requests
26. 26
Linux Containers (e.g. docker)
Automation via Orchestration (allows Devs to become
DevOps)
Infrastructure as Code
24 Weeks
8 of 3
week
sprints
Monolithic System
12 Weeks 9 Weeks
Business
Change
Requests
29. 29
24 Weeks
8 of 3
week
sprints
Monolithic System
6 3 1 112 Weeks 9 Weeks 1
Business
Change
Requests
30. 30
24 Weeks
8 of 3
week
sprints
Monolithic System
6 3 1 112 Weeks 9 Weeks 1
Deploying faster than
3-week sprint cycles?
Patches to your application as well as your “stack” are
also deployments.
Business
Change
Requests
32. 32
#1 – Cleaner Code
Well, less code to go wrong, but
Its not going to magically fix poor engineers
33. 33
#2 – Its Easier
Only doing one thing, so it should be easier - but
The complexity still exists – its moved
somewhere else – the platform
34. 34
#3 – Its Faster
Easier to optimize an isolated service, but
Network is always going to be slower than
co-located code
35. 35
#5 – Better for Scalability
Microservices are better for scalability, but
Only if you carefully consider what should be
architected as a Microservice in the first place
37. 37
Its fine to mix and match monoliths and Microservices
Some things are better left untouched
Choose carefully what to build as a Microservice
Don’t do it yourself:
45. 45
iPaaS 2.0 Microservices Platform
• Built on top of OpenShift
• Provides additional services to generate, build and test integration
services
• Integration Services use Apache Camel:
– deployed in Spring Boot
– In a Docker Container
46. 46
iPaaS 2.0: Microservices Platform
Citizen Developer
iPaaS Console
Expert
Developer
Can view
what’s
under the
hood
Administrator
Can look at
Infrastructure
OpenShift Dedicated
Component
Catalog
Integration
Editor
Funktion
Editor
Data
Mapper
Artifact
Repository
Git
Repository
Application
Logging
Application
Metrics
Tracing
Project
Wizards
Code
Quality
Automated
Testing
Circuit
Breaker
Social
API
Management
47. 47
Agility: Integrated CI/CD
• Continuous
Deployment
automatically, with
jenkins pipelines for
your integration
services
• Automated tests
• Hooks for manual
approval before
production
50. 50
Why Logging ?
What a system is doing
What happened
A record of Actions and Outcomes
51. 51
Traditional Application Logging
Logging strategies defined by the system
Storage and routing defined by the system
Write to local File
Centralizing
Custom configurator per system
52. 52
Container Logging
Container standardize Management of your Processes
So lets standardize Logging
Logs to STDOUT & STDERR
Captured by Execution Environment
Routed by Execution Environment
Containers are Ephemeral
CENTRALIZE
59. 59
Why collect Metrics ?
Logs tell you what’s happening
Metrics measure behavior
Measure improvement of change
Adapt to runtime changes – e.g. auto-scaling
60. 60
Kubernetes Infra … Kublet
Runs on each node
Manages Pod and
container lifecycle
Key Elements:
• Docker client
• cAdvisor client
• Etcd client
• Docker client
• Root directory
master
Node
Node
Node
Node
Node
Node
Pod
Container
Container
Pod
Container
Container
Kublet
61. 61
cAdvisor
Daemon that collects, aggregates processes and exports
information about containers
Collects metrics for both system components and user
containers
62. 62
Heapster
One per cluster
Aggregates all metrics
exposed by cAdvisor
Has Pluggable backend for
persistent storage:
• InfluxDB
• Kafka
• Hawkular etc.
master
Node
Node
Node
Node
Node
Kublet
Heapster
63. 63
Microservices Platform – Application Metrics
• Historical metrics
required for
diagnosis,trends,
and auto-scaling
• Uses Prometheus
for storage
• Grafana for front
end
64. 64
In Summary
Logs tell you what’s happening
Metrics measure how it happened
Use Microservices to capture
CENTRALIZE
66. 66
Why do Tracing?
Latency optimization – where are the bottlenecks ?
Root cause analysis
Measure improvement of change
Continuous Analysis for Continuous
Improvement
68. 68
Microservices Platform – Tracing: Zipkin
• Zipkin: distributed tracing
framework:
• Manages both the tracing
and lookup of the data.
• All routes for iPaaS use
camel-zipkin to record
incoming and outgoing
Camel messages
• OpenTracing
72. 72
Funktion
Event driven lambda style Microservices, built on top of
Kubernetes
Polygot - supports Java, Node.js, Groovy, Kotlin, Go …
Supports hundreds of trigger endpoint URLs
Trigger endpoint defined in funktion.yml:
rules:
- trigger: http://0.0.0.0:8080
action: io.fabric8.funktion.sample.Main
74. 74
Funktion rules:
rules:
name: foo
- trigger: URL
action: io.fabric8.funktion.sample.Producer::message
chain: URL
Optional code to call
Optional
Mandatory – the input
Out – can have multiple of these
87. 87
Single Sign On
By RH SSO
Integration Services
By JBoss Fuse
Intelligent Process
Server
By JBoss BPM Suite
Real time Decision
Service
By JBoss BRMS
In Memory Data Grid
By JBoss Data Grid
Messaging Services
By JBoss A-MQ
Java EE Application
Server
By JBoss EAP
Tomcat
By JBoss Web Server
API
ManagementData Services
By JBoss Data
Virtualization