Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Microservices Journey Fall 2017

956 views

Published on

We consider a microservices architecture to achieve an end goal, not because it's "the cool thing to do". Every organization looking to adopt this architecture must realize (and adhere) to a set of foundational principles. Guided by those principles, we can correctly choose the technology to help support a microservices architecture and meet our end goals. This talk explains those core principles and gives you the tools needed for your microservices journey.

Published in: Software
  • Be the first to comment

Microservices Journey Fall 2017

  1. 1. A Microservices Journey @christianposta
  2. 2. Christian Posta Chief Architect, cloud application development Twitter: @christianposta Blog: http://blog.christianposta.com Email: christian@redhat.com Slides: http://slideshare.net/ceposta • Author “Microservices for Java developers” • Committer/contributor lots of open-source projects • Worked with large Microservices, web-scale, unicorn company • Blogger, speaker about DevOps, integration, and microservices
  3. 3. Rough path of discussions today • Microservices: What, Why, When? • “Cloud-native” with a Platform • Microservices frameworks • Service decomposition and boundaries • Microservice resilience, routing, and control @christianposta
  4. 4. Microserivces: What, Why, When @christianposta
  5. 5. “The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery.” A microservices definition
  6. 6. • Single, self-contained, autonomous • Isolated and Resilient to faults • Faster software delivery • Own their own data • Easier to understand individually • Scalability • Right technology for the problem • Test individual services • Individual deployments Microservices? @christianposta
  7. 7. • System complexity • Operational complexity • Testing is harder across services • Security • Hard to get boundaries right (transactions, APIs, etc) • Resource overhead • Network overhead • Lack of tooling Drawbacks to microservices @christianposta
  8. 8. Why would one implement a system as microservices? @christianposta
  9. 9. Pain we may feel… @christianposta • Making changes in one place negatively affects unrelated areas • Low confidence making changes that don’t break things • Spend lots of time trying to coordinate work between team members • Structure in the application has eroded or is non- existant • We have no way to quantify how long code merges will take
  10. 10. @christianposta • Development time is slow simply because the project is so big (IDE bogs down, running tests is slow, slow bootstrap time, etc) • Changes to one module force changes across other modules • Difficult to sunset outdated technology • We’ve built our new applications around old premises like batch processing • Application steps on itself at runtime managing resources, allocations, computations Pain we may feel…
  11. 11. Microservices is about optimizing for speed. @christianposta
  12. 12. If change is happening on the outside faster than on the inside the end is in sight. S&P company life expectancy @christianposta Jack Welch, former CEO, GE
  13. 13. Fortune 500 firms in 1955 vs. 2014; 88% are gone @christianposta
  14. 14. Competitive advantage is transient. We need to continuously re-invent our business models to compete and stay relevant. We need to continuously innovate. @christianposta
  15. 15. Innovation is admitting we don’t have all the answers Mark Schwartz – Former CIO USCIS @christianposta
  16. 16. We need to figure out the right questions to ask… Mark Schwartz – Former CIO USCIS @christianposta
  17. 17. How do we do this? @christianposta • Identify goals • Free teams to explore possible solution spaces • Generate hypothesis • Design cheap experiments to test hypothesis • Work in small batches • Learn from results • Calibrate investment; rinse, repeat
  18. 18. “If I invest $5-$10M in your company and you fail, I have 30 other investments. It’s just a footnote in my investment history.” https://medium.com/@mattklein123/optimizing-impact-why-i-will-not-start-an-envoy-platform-company-8904286658cb https://barryoreilly.com/2017/04/06/optimize-to-be-wrong-not-right/ Create options through experiments
  19. 19. @christianposta Learning through build-measure-learn
  20. 20. Microservices help us go faster. @christianposta
  21. 21. So do we microservices all the way down? @christianposta
  22. 22. @christianposta http://blog.hypeinnovation.com/using-the-three-horizons-framework-for-innovation IT Portfolio management strategies
  23. 23. @christianposta Lean Enterprise: http://shop.oreilly.com/product/0636920030355.do
  24. 24. @christianposta http://blog.hypeinnovation.com/using-the-three-horizons-framework-for-innovation IT Portfolio management MVPs, experiments, small apps (co-locate if you have to write an app) Product development, initial scale (co-locate perfectly okay here!! .. Microserices? possibly…) Starting to feel the weight of maintenance, need to shoot for efficiencies, integrate new approaches to increase revenue (microservices land)
  25. 25. Microservices != good design AND Co-location != bad design @christianposta
  26. 26. DON’T optimize for microservices if… @christianposta • You’re building a Minimum Viable Product (MVP), testing a hypothesis • You’re building a CRUD application • You system isn’t CRUD, but the business logic not very complicated • Your system doesn’t have > 10 people all trying to coordinate to work on it • Your application doesn’t need to scale • You deliver packaged software • You’re building HPC systems
  27. 27. Making “cloud-native” economical @christianposta
  28. 28. We can now assert with confidence that high IT performance correlates with strong business performance, helping to boost productivity, profitability and market share. @christianposta https://puppet.com/resources/whitepaper/2014-state-devops-report
  29. 29. High performing IT teams @christianposta • …are encouraged to experiment • …learn from failure • …work in small batches • …focus on getting continuous feedback • …are held to outcomes, not output • …continuously prioritize and reprioritize based on cost of delay (http://blackswanfarming.com/cost-of- delay/)
  30. 30. High performing IT teams need these IT capabilities and practices @christianposta • Continuous Integration (build from master) • Continuous Delivery (automated pipelines) • Safe, reliable delivery mechanisms • Modern, scalable, resilient application architectures • Self-service, on-demand infrastructure • Automated testing • Metrics, logs, traces, observability • Feedback loops • Security as part of the pipeline
  31. 31. @christianposta https://www.infoq.com/articles/cloud-native-panel "Cloud native” describes applications, architectures, platforms/infrastructure, and processes, that together make it economical to work to in small batches to learn and reduce uncertainty.
  32. 32. • Distributed configuration • Service Discovery • Loadbalancing • Circuit Breakers • Bulkheading • Versioning/Routing • Based on AWS “Cloud-native” platform What about non-java? @christianposta
  33. 33. Kubernetes @christianposta
  34. 34. Cluster management • Distributed configuration • Service Discovery • Loadbalancing • Versioning/Routing • Deployments • Scaling/Autoscaling • Liveness/Health checking • Self healing • Logging, Metrics, Tracing @christianposta
  35. 35. @christianposta
  36. 36. • Team self service application deployment • Developer workflow • Enterprise focused (LDAP, RBAC, Oauth, etc) • Integrated Docker registry • Jenkins Pipeline (CI/CD) out of the box • Build/deployment triggers • Software Defined Networking (SDN) • Docker native format/packaging • CLI/IDE/Web based tooling OpenShift is a Kubernetes platform @christianposta
  37. 37. @christianposta
  38. 38. @christianposta
  39. 39. @christianposta
  40. 40. @christianposta • Simple configuration • Curated dependencies and transitive dependencies • Built in metrics, monitoring • Slim profile for deployment • Strong communities (spring, vert.x, microprofile.io) OpenShift Application Runtimes
  41. 41. Use Kubernetes/OpenShift • Distributed configuration • Service Discovery • Loadbalancing • Versioning/Routing • Deployments • Scaling/Autoscaling • Liveness/Health checking • Self healing • Logging, Metrics, Tracing @christianposta
  42. 42. What if we’re already using things like Spring Cloud and/or Netflix OSS?! @christianposta
  43. 43. spring-cloud-kubernetes • DiscoveryClient • Ribbon integration • Actuator/Health integrations • Hystrix/Turbine Dashboard integrations (kubeflix) • Zipkin Tracing • Configuration via ConfigMaps • Archaius Bridge for dynamic configs https://github.com/spring-cloud-incubator/spring-cloud-kubernetes
  44. 44. Microservices boundaries @christianposta
  45. 45. @christianposta
  46. 46. Book checkout / purchase Title Search Recommendations Weekly reporting @christianposta
  47. 47. @christianposta
  48. 48. • Break things into smaller, understandable models • Surround a model and its “context” with a boundary • Implement the model in code or get a new model • Explicitly map between different contexts • Model transactional boundaries as aggregates Focus on domain models, not data models @christianposta
  49. 49. Service Cutter: A systemic approach to service decomposition @christianposta https://servicecutter.github.io
  50. 50. @christianposta
  51. 51. How do we share information? • REST, RPC • Streams/Events(ActiveMQ, JMS, AMQP, STOMP, Kafka, etc) • Legacy (SOAP, mainframe, file processing, proprietary) • Routing, Aggregation, Splitting, Transactions, Compensations, Filtering, etc. @christianposta
  52. 52. • Small Java library • 200+ components for integrating systems (bring along only the ones you use) • Powerful EIPs (routing, transformation, error handling) • Distributed-systems swiss-army knife! • Declarative DSL • Embeddable into any JVM (EAP, Karaf, Tomcat, Spring Boot, Dropwizard, Wildfly Swarm, no container, etc) Apache Camel @christianposta
  53. 53. @christianposta
  54. 54. public class OrderProcessorRouteBuilder extends RouteBuilder { @Override public void configure() throws Exception { rest().post(“/order/socks”) .description(“New Order for pair of socks”) .consumes(“application/json”) .route() .to(“activemq:topic:newOrder”) .log(“received new order ${body.orderId}”) .to(“ibatis:storeOrder?statementType=Insert”); } Camel REST DSL @christianposta
  55. 55. Microservices resilience, routing, control @christianposta
  56. 56. Things you must solve for because… distributed systems • Service discovery • Retries • Timeouts • Load balancing • Rate limiting • Thread bulk heading • Circuit breaking
  57. 57. …continued • Routing between services (adaptive, zone-aware) • Deadlines • Back pressure • Outlier detection • Health checking • Traffic shaping • Request shadowing
  58. 58. …continued • Edge/DMZ routing • Surgical / fine / per-request routing • A/B rollout • Internal releases / dark launches • Fault injection • Stats, metric, collection • Logging • Tracing
  59. 59. @christianposta http://bit.ly/application-networking
  60. 60. @christianposta http://bit.ly/application-networking
  61. 61. @christianposta http://bit.ly/application-networking
  62. 62. • Netflix Hystrix (circuit breaking / bulk heading) • Netflix Zuul (edge router) • Netflix Ribbon (client-side service discovery / load balance) • Netflix Eureka (service discovery registry) • Brave / Zipkin (tracing) • Netflix spectator / atlas (metrics) “Microservices” patterns @christianposta
  63. 63. @christianposta http://bit.ly/application-networking
  64. 64. But I’m using Spring! • spring-cloud-netflix-hystrix • spring-cloud-netflix-zuul • spring-cloud-netflix-eureka-client • spring-cloud-netflix-ribbon • spring-cloud-netflix-atlas • spring-cloud-netflix-spectator • spring-cloud-netflix-hystrix-stream • ….. • ...... • @Enable....150differentThings
  65. 65. But I’m using Vert.x! • vertx-circuit-breaker • vertx-service-discovery • vertx-dropwizard-metrics • vertx-zipkin? • ….. • ......
  66. 66. But I’m using NodeJS! But I’m using Go! But I’m using Python!
  67. 67. Get the point?
  68. 68. @christianposta https://lyft.github.io/envoy/ Meet Envoy Proxy
  69. 69. Sidecar pattern
  70. 70. Meet Istio Service Mesh https://istio.io
  71. 71. Quick Demo https://istio.io/docs/samples/bookinfo.html
  72. 72. • Have self-service infrastructure automation? • Have self-service application automation? • Have working CI/CD? • Have health checking, monitoring, instrumentation? • Have logging, distributed tracing? • Able to release services independently? • Honoring backward and forward Are you doing microservices? @christianposta
  73. 73. • Number of features accepted • % of features completed • User satisfaction • Feature Cycle time • defects discovered after deployment • customer lifetime value (future profit as a result of relationship with the customer) https://en.wikipedia.org/wiki/Customer_lifetime_value • revenue per feature • mean time to recovery • % improvement in SLA • number of changes • number of user complaints, recommendations, suggestions • % favorable rating in surveys • % of users using which features • % reduction in error rates • avg number of tx / user • MANY MORE! Focus on going fast and learning
  74. 74. • The hardest part of microservices? Your data https://developers.redhat.com/blog/2016/08/02/the-hardest-part-about-microservices-your-data/ • Microservices patterns: circuit breaking with Envoy Proxy https://developers.redhat.com/blog/2017/05/31/microservices-patterns-with-envoy-sidecar-proxy- part-i-circuit-breaking/ • Monolith to microservices Part I https://developers.redhat.com/blog/2017/09/26/low-risk-monolith-microservice-evolution-part/ • Monolith to microservices Part II https://developers.redhat.com/blog/2017/10/23/low-risk-monolith-microservice-evolution-part-ii/ More material @christianposta
  75. 75. • Download and explore OpenShift • https://www.openshift.org/minishift/ • Checkout Spring Boot/WildFlySwarm/Vert.x on OpenShift: • https://launch.openshift.io • Reach out to your Red Hat rep to discuss more and/or get me/my team involved with your initiatives What next?
  76. 76. Thanks! BTW: Hand drawn diagrams made with Paper by FiftyThree.com @christianposta Twitter: @christianposta Blog: http://blog.christianposta.com Email: christian@redhat.com Slides: http://slideshare.net/ceposta Follow up links: • http://openshift.io • http://launch.openshift.io • http://blog.openshift.com • http://developers.redhat.com/blog • https://www.redhat.com/en/open-innovation-labs • https://www.redhat.com/en/technologies/jboss-middleware/3scale • https://www.redhat.com/en/technologies/jboss-middleware/fuse

×