Christian Posta is a principal middleware specialist and architect who has worked with large microservices architectures. He discusses why companies are moving to microservices and cloud platforms like Kubernetes and OpenShift. He covers characteristics of microservices like small autonomous teams and decentralized decision making. Posta also discusses breaking applications into independent services, shedding dependencies between teams, and using contracts and APIs for communication between services.
2. Christian Posta
Principal Middleware Specialist/Architect
Twitter: @christianposta
Blog: http://blog.christianposta.com
Email: christian@redhat.com
• 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.
4. Microservices Journey
• Why?
• Microservices Architectures
• Cloud platforms with Kubernetes/OpenShift
• Demos!
• Concurrency, Transactions and Data! (time
permitting)
Q & A throughout!
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
15. IT as a core competency; a driver
of business value
16. 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
17.
18.
19. Characteristics of complex, agile, systems
• Small teams
• Autonomy
• Own their existence
• Freedom + Responsibility
• Purpose driven
• Feedback/data driven
• Simple rules, emergent results
21. “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
23. organizations which design systems ...
are constrained to produce designs which
are copies of the communication structures
of these organizations
Melvin Conway
24. “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
25. “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
26. Break things down (organizations, teams,
IT systems, etc) down into smaller pieces for
greater parallelization and autonomy and
focus on reducing time to value.
27. • 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?
39. 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
43. Book checkout / purchase Title Search
Recommendations
Weekly reporting
44. 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
55. • 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
56.
57. • 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?
58. • 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?
59. • 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!
Are you doing microservices?
61. • 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
81. Twitter: @christianposta
Blog: http://blog.christianposta.com
Email: christian@redhat.com
Thanks!
BTW: Hand drawn diagrams made with Paper by FiftyThree.com J
http://openshift.com
http://kubernetes.io
http://fabric8.io
http://events.linuxfoundation.org/events/kubecon
http://camel.apache.org