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 Summer 2017

1,798 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 Summer 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 on Apache Camel, Apache ActiveMQ, Fabric8, others • Worked with large Microservices, web-scale, unicorn company • Blogger, speaker about DevOps, integration, and microservices
  3. 3. Stay with me here… • Why? What is this all about • Microservices architectures • Platform • Boundaries • Distributed systems • APIs • Microservices patterns @christianposta
  4. 4. @christianposta
  5. 5. If change is happening on the outside faster than on the inside the end is in sight. Jack Welch, former CEO, GE S&P company life expectancy @christianposta
  6. 6. Fortune 500 firms in 1955 vs. 2014; 88% are gone @christianposta
  7. 7. “Let there be no more talk about DevOps unicorns or horses but only thoroughbreds and horses heading to the glue factory” Dr. Branden Williams – business security specialist @christianposta
  8. 8. Keeping up is not enough anymore. @christianposta
  9. 9. What does it mean to innovate? @christianposta
  10. 10. “Innovation is admitting we don’t have all the answers” Mark Schwartz – CIO USCIS @christianposta
  11. 11. have a purpose figure out the right questions to ask learn from the answers iteratively repeat, toward the purpose @christianposta
  12. 12. “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/
  13. 13. We need to build a learning organization. @christianposta
  14. 14. organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations Melvin Conway Not so fast… @christianposta
  15. 15. Source: Dave Gray, The Connected Company @christianposta
  16. 16. Source: Dave Gray, The Connected Company @christianposta
  17. 17. Meanwhile… @christianposta
  18. 18. Software has eaten the world… https://venturebeat.com/2017/04/03/technology-has-eaten-the-world/@christianposta
  19. 19. @christianposta
  20. 20. IT as a core competency; a driver of business value @christianposta
  21. 21. We need to build a learning organization capable of using software as a differentiator @christianposta
  22. 22. People try to copy Netflix, but they can only copy what they see. They copy the results, not the process. Adrian Cockcroft, former Chief Cloud Architect, Netflix @christianposta
  23. 23. Microservices architectures
  24. 24. • 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
  25. 25. • 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
  26. 26. Purpose: building a learning organization with microservices • Organize teams around aligned concerns • Teams own entire lifecycle (build, test, deploy, debug, operate, maintain; you build it you run it) • Platform teams for Service teams • Small, more frequent service releases • Mature delivery capabilities • Mature observability capabilities • Reduce the cost of running experiments so you can run more of them! @christianposta
  27. 27. Microservices is how we learn to split our work into parallelizable units to run more experiments and ultimately reduce our time to deliver value. @christianposta
  28. 28. Microservices is about optimizing… for speed. @christianposta
  29. 29. Should you break up your monolith? @christianposta
  30. 30. How do you go fast? @christianposta
  31. 31. @christianposta
  32. 32. Platform
  33. 33. Applications run in Linux Containers @christianposta
  34. 34. Kubernetes @christianposta
  35. 35. Cluster management • Distributed configuration • Service Discovery • Loadbalancing • Versioning/Routing • Deployments • Scaling/Autoscaling • Liveness/Health checking • Self healing • Logging, Metrics, Tracing @christianposta
  36. 36. • Team self service application deployment • Developer workflow • Enterprise focused (LDAP, RBAC, Oauth, etc) • Integrated Docker registry • Jenkins Pipeline out of the box • Build/deployment triggers • Software Defined Networking (SDN) • Docker native format/packaging • CLI/IDE/Web based tooling OpenShift is Kubernetes @christianposta
  37. 37. @christianposta
  38. 38. @christianposta
  39. 39. @christianposta
  40. 40. Boundaries (aka, “how big is a microservice”)
  41. 41. @christianposta
  42. 42. Book checkout / purchase Title Search Recommendations Weekly reporting @christianposta
  43. 43. @christianposta
  44. 44. • 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
  45. 45. @christianposta
  46. 46. @christianposta
  47. 47. @christianposta
  48. 48. We’re building a distributed system (a developer’s perspective)
  49. 49. @christianposta
  50. 50. • Security • Integration of services • System Resilience • Making changes • Data consistency • Monolith evolution • Reliable delivery of services to production The hardest parts of microservices @christianposta
  51. 51. @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
  52. 52. @christianposta OpenShift Application Runtimes
  53. 53. Service Integration @christianposta
  54. 54. Do we need integration? • REST, RPC • Streams/Events(ActiveMQ, JMS, AMQP, STOMP, Kafka, etc) • Legacy (SOAP, mainframe, file processing, proprietary) • Routing, Aggregation, Splitting, Transactions, Compensations, Filtering, etc. @christianposta
  55. 55. Real developers ride camels! @christianposta
  56. 56. • 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
  57. 57. @christianposta
  58. 58. 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
  59. 59. What about our services APIs?
  60. 60. • Publish APIs externally and between organizations • Documentation portal • Rate limiting and policies • Security and authentication • Lifecycle management • Provisioning & alerting • Metering and billing • Testing Scaling with APIs… @christianposta
  61. 61. Mono+Micro with API Gateway @christianposta
  62. 62. @christianposta
  63. 63. @christianposta
  64. 64. Microservices patterns
  65. 65. • Distributed configuration • Service Discovery • Loadbalancing • Circuit Breakers • Bulkheading • Versioning/Routing • Based on AWS “Microservices” patterns What about non-java? @christianposta
  66. 66. Cluster management • Distributed configuration • Service Discovery • Loadbalancing • Versioning/Routing • Deployments • Scaling/Autoscaling • Liveness/Health checking • Self healing • Logging, Metrics, Tracing @christianposta
  67. 67. What if you’re already using things like Spring Cloud and/or Netflix OSS?! @christianposta
  68. 68. 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
  69. 69. What’s next!? http://blog.christianposta.com http://blog.openshift.com http://developers.redhat.com/blog @christianposta
  70. 70. What’s next!? http://blog.christianposta.com http://blog.openshift.com http://developers.redhat.com/blog @christianposta
  71. 71. • 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
  72. 72. • 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!
  73. 73. • CI/CD • Event-driven architectures • Automated testing (integration, system, contract) • Service architecture observability • Intra-service routing, policy control • Security • Developer tooling • Chaos engineering Things we should dig into deeper next time we meet! @christianposta
  74. 74. 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

×