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ā
and other soon to be announced books
ā¢ Committer/contributor lots of open-source projects
ā¢ Blogger, speaker
7. @christianposta
Scientific method anyone?
ā¢ Make observations
ā¢ Formulate hypothesis
ā¢ Design an experiment
ā¢ State the indicators you will evaluate
ā¢ Conduct the experiment
ā¢ Evaluate results
ā¢ Accept or reject hypothesis
ā¢ Make new hypothesis and continueā¦
8. @christianposta
Traditional user story ārequirementsā
ā¢ As Aā¦. <role>
ā¢ I Wantā¦ <goal/desire>
ā¢ So Thatā¦ <receive benefit>
https://barryoreilly.com/2013/10/21/how-to-implement-hypothesis-driven-development/
11. @christianposta
We can now assert with confidence that
high IT performance correlates with
strong business performance, helping
to boost productivity, profitability and
market share.
https://puppet.com/resources/whitepaper/2014-state-devops-report
27. ā¢ Require specific language to bring in new services
ā¢ A single language doesnāt fit for all use cases
ā¢ How do you patch/upgrade/manage lifecycle?
ā¢ Need strict control over application library choices
Some drawbacks to this approach?
29. But Iām using Vert.x!
ā¢ vertx-circuit-breaker
ā¢ vertx-service-discovery
ā¢ vertx-dropwizard-metrics
ā¢ vertx-zipkin?
ā¢ ā¦..
ā¢ ......
@christianposta
30. Screw Java - Iām using NodeJS!
JavaScript is for rookies, I use Go!
But python is so pretty!
I prefer unreadabilityā¦ Perl for me!
@christianposta
32. Letās abstract this functionality to a single
binary and apply to all services.
ā¢ Allow heterogeneous architectures
ā¢ Remove application-specific implementations of this
functionality
ā¢ Consistently enforce these properties
ā¢ Correctly enforce these properties
ā¢ Opt-in as well as safety nets
@christianposta
36. Envoy isā¦
ā¢ service proxy
ā¢ written in C++, highly parallel, non-blocking
ā¢ L3/4 network filter
ā¢ out of the box L7 filters
ā¢ HTTP 2, including gRPC
ā¢ baked in service discovery/health checking
ā¢ advanced load balancing
ā¢ stats, metrics, tracing
ā¢ dynamic configuration through xDS
42. ā2018 is the year of the service meshā
Clayton Coleman (@smarterclayton)
Red Hat OpenShift Platform Architect
@christianposta
43. A service mesh is decentralized application-
networking infrastructure between your services
that provides resiliency, security, observability,
and routing control.
A service mesh is comprised of a data plane
and control plane.
@christianposta
Time for definitions:
44. All traffic between our applications flows
through these proxies. The proxies make
up the ādata planeā
@christianposta
60. Thanks!
BTW: Hand drawn diagrams made with Paper by FiftyThree.com ļ
Twitter: @christianposta
Blog: http://blog.christianposta.com
Email: christian@redhat.com
Slides: http://slideshare.net/cepostaFollow up links:
ā¢ http://envoyproxy.io
ā¢ http://istio.io
ā¢ http://blog.christianposta.com/istio-workshop/slides/
ā¢ http://launch.openshift.io
ā¢ http://blog.openshift.com
ā¢ http://developers.redhat.com/blog
ā¢ https://www.redhat.com/en/open-innovation-labs
Editor's Notes
One large database!
We should focus on how we design our data models so that they can be sharded and distributedā¦. Focus on transactions, etc not 2PC
How many people are embarking on projects to drive innovation in their organizations?
How many people think those projects will succeed?
How many people can predict the future?
How many people believe their organizationās executives can predict the future?
Inherently unknownā¦.
Unknown Unknownsā¦..
As we look to āITā to lead innovation, we need to optimize IT to go fast, ask questions, experiment and learnā¦.
This is where containers and APIs help tremendouslyā¦.
One large database!
We should focus on how we design our data models so that they can be sharded and distributedā¦. Focus on transactions, etc not 2PC
ā¦ā¦ new challengesā¦.. Letās come back to thatā¦..
ā¦ā¦ new challengeā¦.. Letās come back to thatā¦..
One large database!
We should focus on how we design our data models so that they can be sharded and distributedā¦. Focus on transactions, etc not 2PC
One large database!
We should focus on how we design our data models so that they can be sharded and distributedā¦. Focus on transactions, etc not 2PC
One large database!
We should focus on how we design our data models so that they can be sharded and distributedā¦. Focus on transactions, etc not 2PC
One large database!
We should focus on how we design our data models so that they can be sharded and distributedā¦. Focus on transactions, etc not 2PC
This concept of defining language, developing models to describe a domain, implementing those models, enforcing assertions, etc all happen within a certain context, and that context is vitally important in software. In common language, we are smart enough to resolve these types of language conflicts within a sentence because of its context. The computer doesnāt have this context. We have to make it explicit. And any context needs to have explicit boundaries.
This model needs to be āusefulā ie, it should be able to be implemented. Try to establish a model thatās both useful for discussion with the domain experts and is implementable. There are infinite ways to model/think about something. Balance both masters with the model you choose.
Large complex domains may need multiple models. And really the only way to understand a language and model is within a certain context. That context should have boundaries so it doesnāt bleed or force others to bleed definitions and semantics.
Bounded context: within this space, this is the context of the language. This is what it means and itās not ambiguous.
Central thing about a model is the language you create to express the prblem and solution very crisply. Need clear language and need boundaries.
Anti corruption layers are translations between the different models that may exist in multiple bounded contexts. They keep an internal model consistent and pure without bleeding across the boundaries.
Bounded contexts tend to be āself contained systemsā themselves with a complete vertical stack of the software including UI, business logic, data models, and database. They tend to not share databases across multiple models.
This concept of defining language, developing models to describe a domain, implementing those models, enforcing assertions, etc all happen within a certain context, and that context is vitally important in software. In common language, we are smart enough to resolve these types of language conflicts within a sentence because of its context. The computer doesnāt have this context. We have to make it explicit. And any context needs to have explicit boundaries.
This model needs to be āusefulā ie, it should be able to be implemented. Try to establish a model thatās both useful for discussion with the domain experts and is implementable. There are infinite ways to model/think about something. Balance both masters with the model you choose.
Large complex domains may need multiple models. And really the only way to understand a language and model is within a certain context. That context should have boundaries so it doesnāt bleed or force others to bleed definitions and semantics.
Bounded context: within this space, this is the context of the language. This is what it means and itās not ambiguous.
Central thing about a model is the language you create to express the prblem and solution very crisply. Need clear language and need boundaries.
Anti corruption layers are translations between the different models that may exist in multiple bounded contexts. They keep an internal model consistent and pure without bleeding across the boundaries.
Bounded contexts tend to be āself contained systemsā themselves with a complete vertical stack of the software including UI, business logic, data models, and database. They tend to not share databases across multiple models.
This concept of defining language, developing models to describe a domain, implementing those models, enforcing assertions, etc all happen within a certain context, and that context is vitally important in software. In common language, we are smart enough to resolve these types of language conflicts within a sentence because of its context. The computer doesnāt have this context. We have to make it explicit. And any context needs to have explicit boundaries.
This model needs to be āusefulā ie, it should be able to be implemented. Try to establish a model thatās both useful for discussion with the domain experts and is implementable. There are infinite ways to model/think about something. Balance both masters with the model you choose.
Large complex domains may need multiple models. And really the only way to understand a language and model is within a certain context. That context should have boundaries so it doesnāt bleed or force others to bleed definitions and semantics.
Bounded context: within this space, this is the context of the language. This is what it means and itās not ambiguous.
Central thing about a model is the language you create to express the prblem and solution very crisply. Need clear language and need boundaries.
Anti corruption layers are translations between the different models that may exist in multiple bounded contexts. They keep an internal model consistent and pure without bleeding across the boundaries.
Bounded contexts tend to be āself contained systemsā themselves with a complete vertical stack of the software including UI, business logic, data models, and database. They tend to not share databases across multiple models.
This concept of defining language, developing models to describe a domain, implementing those models, enforcing assertions, etc all happen within a certain context, and that context is vitally important in software. In common language, we are smart enough to resolve these types of language conflicts within a sentence because of its context. The computer doesnāt have this context. We have to make it explicit. And any context needs to have explicit boundaries.
This model needs to be āusefulā ie, it should be able to be implemented. Try to establish a model thatās both useful for discussion with the domain experts and is implementable. There are infinite ways to model/think about something. Balance both masters with the model you choose.
Large complex domains may need multiple models. And really the only way to understand a language and model is within a certain context. That context should have boundaries so it doesnāt bleed or force others to bleed definitions and semantics.
Bounded context: within this space, this is the context of the language. This is what it means and itās not ambiguous.
Central thing about a model is the language you create to express the prblem and solution very crisply. Need clear language and need boundaries.
Anti corruption layers are translations between the different models that may exist in multiple bounded contexts. They keep an internal model consistent and pure without bleeding across the boundaries.
Bounded contexts tend to be āself contained systemsā themselves with a complete vertical stack of the software including UI, business logic, data models, and database. They tend to not share databases across multiple models.
This concept of defining language, developing models to describe a domain, implementing those models, enforcing assertions, etc all happen within a certain context, and that context is vitally important in software. In common language, we are smart enough to resolve these types of language conflicts within a sentence because of its context. The computer doesnāt have this context. We have to make it explicit. And any context needs to have explicit boundaries.
This model needs to be āusefulā ie, it should be able to be implemented. Try to establish a model thatās both useful for discussion with the domain experts and is implementable. There are infinite ways to model/think about something. Balance both masters with the model you choose.
Large complex domains may need multiple models. And really the only way to understand a language and model is within a certain context. That context should have boundaries so it doesnāt bleed or force others to bleed definitions and semantics.
Bounded context: within this space, this is the context of the language. This is what it means and itās not ambiguous.
Central thing about a model is the language you create to express the prblem and solution very crisply. Need clear language and need boundaries.
Anti corruption layers are translations between the different models that may exist in multiple bounded contexts. They keep an internal model consistent and pure without bleeding across the boundaries.
Bounded contexts tend to be āself contained systemsā themselves with a complete vertical stack of the software including UI, business logic, data models, and database. They tend to not share databases across multiple models.
This concept of defining language, developing models to describe a domain, implementing those models, enforcing assertions, etc all happen within a certain context, and that context is vitally important in software. In common language, we are smart enough to resolve these types of language conflicts within a sentence because of its context. The computer doesnāt have this context. We have to make it explicit. And any context needs to have explicit boundaries.
This model needs to be āusefulā ie, it should be able to be implemented. Try to establish a model thatās both useful for discussion with the domain experts and is implementable. There are infinite ways to model/think about something. Balance both masters with the model you choose.
Large complex domains may need multiple models. And really the only way to understand a language and model is within a certain context. That context should have boundaries so it doesnāt bleed or force others to bleed definitions and semantics.
Bounded context: within this space, this is the context of the language. This is what it means and itās not ambiguous.
Central thing about a model is the language you create to express the prblem and solution very crisply. Need clear language and need boundaries.
Anti corruption layers are translations between the different models that may exist in multiple bounded contexts. They keep an internal model consistent and pure without bleeding across the boundaries.
Bounded contexts tend to be āself contained systemsā themselves with a complete vertical stack of the software including UI, business logic, data models, and database. They tend to not share databases across multiple models.
Get back to first principles.
Focus on principles, patterns, methodologies.
Tools will help, but you cannot start with tools.
Get back to first principles.
Focus on principles, patterns, methodologies.
Tools will help, but you cannot start with tools.
Get back to first principles.
Focus on principles, patterns, methodologies.
Tools will help, but you cannot start with tools.
Get back to first principles.
Focus on principles, patterns, methodologies.
Tools will help, but you cannot start with tools.
Get back to first principles.
Focus on principles, patterns, methodologies.
Tools will help, but you cannot start with tools.
Get back to first principles.
Focus on principles, patterns, methodologies.
Tools will help, but you cannot start with tools.
Get back to first principles.
Focus on principles, patterns, methodologies.
Tools will help, but you cannot start with tools.
Get back to first principles.
Focus on principles, patterns, methodologies.
Tools will help, but you cannot start with tools.
Get back to first principles.
Focus on principles, patterns, methodologies.
Tools will help, but you cannot start with tools.
Get back to first principles.
Focus on principles, patterns, methodologies.
Tools will help, but you cannot start with tools.
Get back to first principles.
Focus on principles, patterns, methodologies.
Tools will help, but you cannot start with tools.
Get back to first principles.
Focus on principles, patterns, methodologies.
Tools will help, but you cannot start with tools.
Get back to first principles.
Focus on principles, patterns, methodologies.
Tools will help, but you cannot start with tools.
Get back to first principles.
Focus on principles, patterns, methodologies.
Tools will help, but you cannot start with tools.
Get back to first principles.
Focus on principles, patterns, methodologies.
Tools will help, but you cannot start with tools.
Get back to first principles.
Focus on principles, patterns, methodologies.
Tools will help, but you cannot start with tools.
Get back to first principles.
Focus on principles, patterns, methodologies.
Tools will help, but you cannot start with tools.
Get back to first principles.
Focus on principles, patterns, methodologies.
Tools will help, but you cannot start with tools.
Get back to first principles.
Focus on principles, patterns, methodologies.
Tools will help, but you cannot start with tools.
Get back to first principles.
Focus on principles, patterns, methodologies.
Tools will help, but you cannot start with tools.
Get back to first principles.
Focus on principles, patterns, methodologies.
Tools will help, but you cannot start with tools.
Get back to first principles.
Focus on principles, patterns, methodologies.
Tools will help, but you cannot start with tools.
Get back to first principles.
Focus on principles, patterns, methodologies.
Tools will help, but you cannot start with tools.