Integration in the Cloud
Download as PPT, PDF2 likes714 views
The document discusses the evolution of cloud integration and microservices, highlighting key technologies like Kubernetes and Docker, and their benefits for application deployment and management. It elaborates on microservices as an architectural approach, emphasizing deployment independence, API focus, and decentralized data management, while also addressing common fallacies associated with adopting microservices. Additionally, it introduces Fabric8 and integration platform as a service (iPaaS) as solutions for streamlining cloud services, emphasizing orchestration, logging, and metrics collection.
![54
Structured Logging Example
{
"STATUS": "200”,
"REQUEST": "GET /apache_pb.gif
HTTP/1.0”,
"HOST": ”127.0.0.1”,
"REFERER":
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](https://image.slidesharecdn.com/integrationinthecloud-161010162443/85/Integration-in-the-Cloud-54-320.jpg)
Integration in the Cloud
- 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 …
- 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)
- 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 Red Hat is helping drive open containers docker kubernetes
- 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
- 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
- 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
- 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
- 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:
- 38. 38 Fabric8: Makes cloud stuff easy – and we are building an iPaaS too
- 39. 39
- 40. 40 Two Faces of iPaaS or ...
- 41. 41 Fuse Integration Services for OpenShift Native integration with Docker, Kubernetes, and OpenShift Built-for-purpose application runtime ideal for microservice deployments DevOps friendly deployment workflows Deep inspection into integration services with domain-specific administration views Containerized integration services FIS 1.0 Released in Dec 2015 OpenShift Enterprise OpenShift Dedicated
- 42. 42 Fuse Integration Services for OpenShift Integrate, cluster, and scale applications using Kubernetes. Tooling creates a complete runtime customized to an application’s requirements and delivered as a Docker image Bridge development and operations with build, deployment, and management integration within OpenShift.
- 43. 43 Microservices Platform – the Foundations • Runtime Registry • Logging • Security • Deployment • Scalability • Loosely coupled • Resilient • Temporal From the platform: The services:
- 44. 44 Integration Platform as a Service iPaaS Cloud-Based Cloud Connectivity Citizen UX API Management Cloud Toolchain Data Integration Application Integration Delivery Lifecycle Multi-Platform
- 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://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://github.com/fabric8io/funktion 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 ENTERPRISE-GRADE CONTAINER OS Business Automation CONTAINER CONTAINERCONTAINER CONTAINER CONTAINER Integration Data Web & Mobile 3rd party frameworks CONTAINER INFRASTRUCTURE (Orchestration & Scheduling, Storage, Registry, Security, Networking) LIFECYCLE AUTOMATION (Self-service, CI/CD, Image Stream) CONTAINER MANAGEMENT (Monitoring, Capacity, Policies) Red Hat OpenShift Container Platform (incl. CloudForms) Red Hat Enterprise Linux & Atomic Host Red Hat Application Services (JBOSS) Traditional, Stateful & Microservices-based Apps Red Hat Registry CloudForms Ansible Satellite Developer Studio CDK Storage PaaS CaaS IaaS Red Hat Container Stack & Tools
- 85. 85 OpenShift Enables Dev and Ops
- 86. 86 SERVICECATALOG (LANGUAGERUNTIMES,MIDDLEWARE,DATABASES,…) SELF-SERVICE APPLICATIONLIFECYCLEMANAGEMENT (CI/CD) BUILDAUTOMATION DEPLOYMENTAUTOMATION CONTAINER CONTAINERCONTAINER CONTAINER CONTAINER NETWORKING SECURITYSTORAGE REGISTRY LOGS&METRICS CONTAINERORCHESTRATION&CLUSTERMANAGEMENT (KUBERNETES) REDHATENTERPRISELINUX CONTAINERRUNTIME&PACKAGING (DOCKER) ATOMICHOST OpenShift Container Platform Build, Deploy and Manage Containerized Apps
- 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 JBoss Middleware Services on OpenShift
Editor's Notes
- #6: concluded that Docker was “scoring higher than anything ever seen in [ETR’s] history.” In fact, as of April 2015 Docker was ranking at 97% net usage and purchasing intention by enterprises
- #16: Niantuc – 10s thousands of cores on GKE
- #19: System -== app server. There maybe file per app, file for admin etc – so context is providid by the system
- #20: System -== app server. There maybe file per app, file for admin etc – so context is providid by the system
- #33: System -== app server. There maybe file per app, file for admin etc – so context is providid by the system
- #34: System -== app server. There maybe file per app, file for admin etc – so context is providid by the system
- #35: System -== app server. There maybe file per app, file for admin etc – so context is providid by the system
- #36: System -== app server. There maybe file per app, file for admin etc – so context is providid by the system
- #38: System -== app server. There maybe file per app, file for admin etc – so context is providid by the system
- #42: Light
- #43: Light
- #52: System -== app server. There maybe file per app, file for admin etc – so context is providid by the system
- #53: Fault diagnosis involves logging on to server - Application is responsible for storage of its logs - Log to local file system defined in application - Multiple log files - Centralised aggregator - Appears flexible but soon becomes limiting
- #54: Fault diagnosis involves logging on to server - Application is responsible for storage of its logs - Log to local file system defined in application - Multiple log files - Centralised aggregator - Appears flexible but soon becomes limiting
- #55: Fault diagnosis involves logging on to server - Application is responsible for storage of its logs - Log to local file system defined in application - Multiple log files - Centralised aggregator - Appears flexible but soon becomes limiting
- #56: Fault diagnosis involves logging on to server - Application is responsible for storage of its logs - Log to local file system defined in application - Multiple log files - Centralised aggregator - Appears flexible but soon becomes limiting
- #57: daemon set – a copy of a pod (in this case fluentd) Is run on every node as it joins the cluster
- #59: daemon set – a copy of a pod (in this case fluentd) Is run on every node as it joins the cluster
- #60: daemon set – a copy of a pod (in this case fluentd) Is run on every node as it joins the cluster
- #62: daemon set – a copy of a pod (in this case fluentd) Is run on every node as it joins the cluster
- #65: daemon set – a copy of a pod (in this case fluentd) Is run on every node as it joins the cluster
- #66: daemon set – a copy of a pod (in this case fluentd) Is run on every node as it joins the cluster
- #67: daemon set – a copy of a pod (in this case fluentd) Is run on every node as it joins the cluster
- #68: daemon set – a copy of a pod (in this case fluentd) Is run on every node as it joins the cluster
- #72: daemon set – a copy of a pod (in this case fluentd) Is run on every node as it joins the cluster
- #76: daemon set – a copy of a pod (in this case fluentd) Is run on every node as it joins the cluster
- #77: daemon set – a copy of a pod (in this case fluentd) Is run on every node as it joins the cluster
- #78: daemon set – a copy of a pod (in this case fluentd) Is run on every node as it joins the cluster
- #82: daemon set – a copy of a pod (in this case fluentd) Is run on every node as it joins the cluster