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.

1. Integration in The Cloud
Rob Davies
2016

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 …

3. 3
Fabric8 –
some
background

4. 4
Camel’s Journey to Microservices
Self-Service,
On-Demand,
Elastic,
Infrastructure
as
Code
(Cloud)
Re-Org to
DevOps
Automation
Puppet, Chef,
Ansible
and/or
Containers
Fabric8 v1
(2010 ish)

5. 5
Fabric8: Cloud Engine
Agent
Runtime
Registry
Configuration
coordination
Monitoring
Agent
Agent
Fabric v1

6. 6
Camel’s Journey to Microservices
CI & CD
Deployment
Pipeline
One
Microservice
Silicon
Valley
DotCom
Startup
Meanwhile …

7. 7
We had to
pivot and go
Kubernetes
and
containers

8. 8
Why do you want to run your application inside containers?

9. 9
● Lightweight footprint and minimal overhead,
● Portability across machines,
● Simplify DevOps practices,
● Speeds up Continuous Integration,
● Empower Microservices Architectures.
● Isolation
Container
Advantages

10. 10
Kubernetes: Container Orchestration
• Inspired by Google’s experience with Orchestration
• Automatic bin packing
• Self healing
• Horizontal Scaling
• Service Discovery and load balancing
• Automated rollouts and rollbacks
• Secret and Configuration management
• Storage orchestration
• 2 years old – 30,000 commits

11. 11
Master
API Server
Service Layer
VirtualPhysical Private Public
Persistent
Storage
Node Node
Logger
Node
Node Node Node
Dev
Ops
SCM
(Git/Svn)
CI/CD
Automation
Routing Layer
Registry
SDN Overlay Network
Controllers
- Scheduler
- Replication
- Services
- Builds
- Routes
- Deployment
Kubernetes
OpenShift
- Deployments
- Builds
- ImageStreams

12. 12

13. 13

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

15. 15

16. 16
What are
Microservices
…

17. 17
Peak of
Inflated
Expectations
x
Trough of
Disillusionment
Serious Hotness
Techology
Trigger
Slope of
Enlightenment

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

21. 21
How to do
Microservices ?

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

23. 23
Programmers
(18) Operators
(6)
DBAs
(3)
Project
Managers
(2)
Business
Analysts
(4)
Quality
Assurance
(6)
Compliance
(2)

24. 24

25. 25
Automated Testing
Continuous Integration & Build Automation
24 Weeks
8 of 3
week
sprints
Monolithic System
12 Weeks
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

27. 27
Continuous Delivery Pipeline
24 Weeks
8 of 3
week
sprints
Monolithic System
612 Weeks 9 Weeks
Business
Change
Requests

28. 28
Zero-Downtime Deployment Strategies (Blue/Green,
Canary)
24 Weeks
8 of 3
week
sprints
Monolithic System
6 312 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

31. 31
Microservices
Fallacies…
From:http://basho.com/posts/techni
cal/microservices-please-dont/

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

36. 36
Microservices
In reality

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:

38. 38
Fabric8:
Makes cloud stuff
easy – and we
are building an
iPaaS too

39. 39

40. 40

41. 41

42. 42

43. 43
Microservices Platform – the Foundations
• Runtime Registry
• Logging
• Security
• Deployment
• Scalability
• Loosely coupled
• Resilient
• Temporal
From the platform: The services:

44. 44

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

48. 48
What Do we need
from our
Microservices
Platform?

49. 49
Logging …

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

53. 53
Contextual Logging
Logs are for machines, not humans
Context gives logs power
Structured Logging

54. 54
Structured Logging Example
{
"STATUS": "200”,
"REQUEST": "GET /apache_pb.gif
HTTP/1.0”,
"HOST": ”127.0.0.1”,
"REFERER": http"REFERER":
http://www.example.com/"REFE
RER":
http://www.example.com/start.ht
ml,
"USER": "frank”,
"TIME": "10/Oct/2000:13:55:36
-0700”,
"USERAGENT": "Mozilla/4.08 [en]
(Win98; I ;Nav)“,
"IDENTITY": "-”,
"SIZE": "2326”
}
Context added by the logging
process
Machine Readable
Filterable and Searchable

55. 55
CENTRALIZE

56. 56
Deployment is Easy
RC and Service for ElasticSearch
RC and Service for Kibana
daemon set for fluentd
Every Container’s Log is Centralized

57. 57

58. 58
Can we do the same for Metrics ?

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

65. 65
What about Tracing ??

66. 66
Why do Tracing?
Latency optimization – where are the bottlenecks ?
Root cause analysis
Measure improvement of change
Continuous Analysis for Continuous
Improvement

67. 67
Open Tracing
Vendor neutral
Open APIs
Support for Go, Python, Java and Javascript
No lock in, easy to develop, easy to switch

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

69. 69
Microservices Platform – Tracing: Zipkin
Architecture

70. 70
Wait –
there’s more
…

71. 71
Writing an Integration easily: Funktion

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

73. 73
Funktion supports same URLs as Camel:

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

75. 75

76. 76

77. 77

78. 78
Funktion how it works:

79. 79
Funktion how it works:
http://
Pod

80. 80
Funktion: part of the Fabric8 family
Code: https Code: https://github.com/fabric8io/ Code:
https://github.com/fabric8io/funktion
Examples: in quickstarts: https://github.com/fabric8-Examples:
in quickstarts: https://github.com/fabric8-quickstarts
• funktion-java-example
• funktion-nodejs-example
• funktion-kotlin-example
• funktion-nats-example
• funktion-java-kafka-example

81. 81
iPaaS:
A lot is happening under the hood …

82. 82
But … the user just sees this:

83. 83
iPaaS is being
built on
fabric8 and
OpenShift

84. 84
Red Hat
Registry

85. 85

86. 86
SERVICE CATALOG
(LANGUAGE RUNTIMES, MIDDLEWARE, DATABASES, …)
SELF-SERVICE
APPLICATION LIFECYCLE MANAGEMENT
(CI / CD)
BUILD AUTOMATION DEPLOYMENT AUTOMATION
CONTAINER CONTAINERCONTAINER CONTAINER CONTAINER
NETWORKING SECURITYSTORAGE REGISTRY
LOGS &
METRICS
CONTAINER ORCHESTRATION & CLUSTER MANAGEMENT
(KUBERNETES)
RED HAT ENTERPRISE LINUX
CONTAINER RUNTIME & PACKAGING
(DOCKER)
ATOMIC HOST

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

88. 88
Links:
http://camel.apache.org
http://fabric8.io
http://http://kubernetes.io
https://https://www.openshift.org