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 NYC


Published on

Microservices architectures have many benefits, but they also come with some unique challenges. Knowledge and preparation are key to maximizing the benefits of microservices.

In this talk, you'll learn when to consider a microservices architecture, how to get started, and how it relates to other IT trends, like DevOps, Internet of Things (IoT), and big data.


Overview of microservices architectures—and why you should consider it
Discussion about when to use frameworks like Spring Boot, WildFly Swarm, Netflix OSS
Monitoring and metrics collections, KPIs, business value
The importance of Continuous Integration, Continuous Delivery
Why APIs and API management are critical foundations of any cloud-native architecture
Best practices, demonstrations and recommendations for next steps

Published in: Software

Microservices Journey NYC

  1. 1. A Microservices Journey @christianposta
  2. 2. Christian Posta Principal Middleware Specialist/Architect Twitter: @christianposta Blog: Email: •  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. Microservices Journey •  Why? •  Microservices Architectures •  Cloud platforms with Kubernetes/OpenShift •  Demos! •  Concurrency, Transactions and Data! (time permitting) Q & A throughout!
  4. 4. 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
  5. 5. Fortune 500 firms in 1955 vs. 2014; 88% are gone
  6. 6. We need to innovate, not just keep up. (Red Queen’s Race)
  7. 7. Source: Dave Gray, The Connected Company
  8. 8. Source: Dave Gray, The Connected Company
  9. 9. Post industrialism: Value delivered through services, not mass production of product.
  10. 10. To deliver services which provide value, we need to listen and react. We need to deal with variety.
  11. 11. Software is eating the world. Marc Andreesen
  12. 12. IT as a core competency; a driver of business value
  13. 13. How to drive innovation and deliver value: •  Admit you don’t have all the answers; figure out how to ask the right questions! •  Feed back driven adaptation •  Decentralized decision making •  Purpose driven
  14. 14. Characteristics of complex, agile, systems •  Small teams •  Autonomy •  Own their existence •  Freedom + Responsibility •  Purpose driven •  Feedback/data driven •  Simple rules, emergent results
  15. 15. People try to copy Net,lix, but they can only copy what they see. They copy the results, not the process. Adrian Cockcroft, former Chief Cloud Architect, Netflix
  16. 16. “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
  17. 17. Microservices Architectures
  18. 18. organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations Melvin Conway
  19. 19. “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.” Martin Fowler’s definition
  20. 20. “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” Red Hat’s definition
  21. 21. Break things down (organizations, teams, IT systems, etc) down into smaller pieces for greater parallelization and autonomy and focus on reducing time to value.
  22. 22. •  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 What benefits of breaking this down?
  23. 23. Microservices is about optimizing … for speed.
  24. 24. Quick example
  25. 25.
  26. 26. @christianposta
  27. 27. Microservices is about optimizing … for speed.
  28. 28. How do you go fast?
  29. 29. Many things to consider: contracts, versioning, forward/backward compatibility, continuous integration, continuous delivery, self-service automation, monitoring, feedback loops, logging, chaos testing ,self-healing infrastructure, A/B testing, data, and many others….
  30. 30. Shed dependencies!
  31. 31. How to shed dependencies?
  32. 32. Shedding dependencies •  Team self service •  Organize teams around a service •  Teams own entire lifecycle (build, test, deploy, debug, operate, maintain; you build it you run it) •  Teams communicate via APIs (or you’re fired!) •  Services own their own data •  Boundaries establish a “bounded context” •  Services communicate via promises •  Make contracts explicit: contract evolution as a first- class citizen
  33. 33. But we still have dependencies on other services!
  34. 34. We need boundaries
  35. 35. Book checkout / purchase Title Search Recommendations Weekly reporting
  36. 36. Domain Complexity •  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
  37. 37. Services and teams make promises
  38. 38. Services make promises •  Health checking •  Autoscaling •  Self healing •  Circuit breakers •  Bulkheading •  Throttling/rate limiting •  Fallbacks •  Apologies
  39. 39. Services make promises
  40. 40. Consumer contracts?
  41. 41. Consumer contracts?
  42. 42. Consumer contracts? { "request" : { "url" : "/user/ceposta", "method" : ”GET” }, "response" : { "status" : 200, "body" : ([ “first”: “christian” “last”: 'posta' “twitter”: '@christianposta' ]), "headers" : { "X-Application-Context" : "application:-1", "Content-Type" : "text/plain" } } }
  43. 43. Consumer driven contracts!
  44. 44. Do we need integration? •  REST, RPC •  Streams/Events(ActiveMQ, JMS, AMQP, STOMP, Kafka, etc) •  Legacy (SOAP, mainframe, file processing, proprietary) •  Managed file processing •  Streaming •  Message transformation •  EIPs
  45. 45. •  Automatic retries, back-off algorithms •  Dynamic routing •  Powerful testing/mocking framework •  Circuit breakers, fallbacks •  Idempotent consumers •  Backpressure mechanisms •  Beautiful REST DSL with built in Swagger support Apache Camel for resilient Microservices
  46. 46. •  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 compatibility? Are you doing microservices?
  47. 47. •  Maybe it doesn’t matter so much… What we really care about is speed, reduced time to value, and business outcomes. •  Maybe a data-driven approach is a better way to answer this question... Are you doing microservices?
  48. 48. •  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) •  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! Are you doing microservices?
  49. 49. Are there any drawbacks?
  50. 50. •  System complexity •  Operational complexity •  Testing is harder across services •  Security •  Hard to get boundaries right (transactions, etc) •  Resource overhead •  Network overhead •  Lack of tooling Drawbacks to microservices
  51. 51. Microservices for Java Developers
  52. 52. •  Simple configuration •  Curated dependencies and transitive dependencies •  Built in metrics, monitoring •  Slim profile for deployment (…micro even?) #microprofile
  53. 53. Docker
  54. 54. •  Distributed configuration •  Service Discovery •  Loadbalancing •  Circuit Breakers •  Bulkheading •  Versioning/Routing •  Based on AWS
  55. 55. What about non-java?
  56. 56. Kubernetes
  57. 57. Container cluster management •  Distributed configuration •  Service Discovery •  Loadbalancing •  Versioning/Routing •  Deployments •  Scaling/Autoscaling •  Liveness/Health checking •  Self healing
  58. 58. •  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
  59. 59. Kubernetes is declarative microservices infrastructure.
  60. 60. Elasticity, resiliency, self healing
  61. 61. Service discovery
  62. 62. What about client-side load balancing? Eg, Ribbon, Zuul, etc
  63. 63. Twitter: @christianposta Blog: Email: Thanks! BTW: Hand drawn diagrams made with Paper by J