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.

1. A Microservices Journey
@christianposta

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

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

6. Fortune 500 firms in 1955 vs. 2014;
88% are gone

8. We need to innovate, not just keep up.
(Red Queen’s Race)

9. Source: Dave Gray, The Connected Company

10. Source: Dave Gray, The Connected Company

11. Post industrialism:
Value delivered through services,
not mass production of product.

13. To deliver services which provide value,
we need to listen and react. We need
to deal with variety.

14. Software is eating the world.
Marc Andreesen

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

19. Characteristics of complex, agile, systems
• Small teams
• Autonomy
• Own their existence
• Freedom + Responsibility
• Purpose driven
• Feedback/data driven
• Simple rules, emergent results

20. 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

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

22. Microservices Architectures

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?

28. Microservices is about optimizing … for speed.

29. Quick example

30. http://www.jboss.org/ticket-monster/

33. @christianposta
blog.christianposta.com
github.com/christian-posta

34. Microservices is about optimizing … for speed.

35. How do you go fast?

36. 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….

37. Shed dependencies!

38. How to shed dependencies?

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

41. But we still have dependencies on
other services!

42. We need boundaries

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

46. Services and teams make promises

47. Services make promises
• Health checking
• Autoscaling
• Self healing
• Circuit breakers
• Bulkheading
• Throttling/rate limiting
• Fallbacks
• Apologies

48. Services make promises

49. Consumer contracts?

50. Consumer contracts?

51. 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"
}
}
}

52. Consumer driven contracts!

54. 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

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

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?

60. Are there any drawbacks?

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

62. Microservices for Java Developers

64. • Simple configuration
• Curated dependencies and
transitive dependencies
• Built in metrics, monitoring
• Slim profile for deployment
(…micro even?)
#microprofile

65. Docker

66. • Distributed configuration
• Service Discovery
• Loadbalancing
• Circuit Breakers
• Bulkheading
• Versioning/Routing
• Based on AWS

67. What about non-java?

68. Kubernetes

69. Container cluster management
• Distributed configuration
• Service Discovery
• Loadbalancing
• Versioning/Routing
• Deployments
• Scaling/Autoscaling
• Liveness/Health checking
• Self healing

70. • 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

71. Kubernetes is declarative
microservices infrastructure.

72. Elasticity, resiliency, self healing

73. Service discovery

78. What about client-side load balancing?
Eg, Ribbon, Zuul, etc

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