Making sense of microservices, service mesh, and serverless
•Télécharger en tant que PPTX, PDF•
6 j'aime•692 vues
As companies move to become digital, we can get sidetracked and distracted by some of the changes in the technology landscape. Ideally we will be harnessing technology to solve the problems we have and leverage it to deliver software faster and safer. In this talk, I'll we'll take a look at some new technology trends in the open-source communities and when and how to use them.
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à Making sense of microservices, service mesh, and serverless
Similaire à Making sense of microservices, service mesh, and serverless (20)
Plus de Christian Posta
Plus de Christian Posta (20)
Dernier
Dernier (20)
Making sense of microservices, service mesh, and serverless
- 1. Making sense of microservices, service mesh, and serverless @christianposta
- 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 “Introducing Istio Service Mesh” • Committer/contributor lots of open-source projects • Blogger, speaker, mentor, leader
- 3. Microservice A highly distracting word that serves to confuse developers, architects, and IT leaders into believing that we can actually have a utopian application architecture. @christianposta
- 4. Microservice A highly distracting word that serves to confuse developers, architects, and IT leaders into believing that we can actually have a utopian application architecture. An architecture optimization that treats the modules of an application as independently owned and deployed services for the purposes of increasing an organization’s velocity @christianposta
- 5. Microservices is about optimizing for speed. @christianposta
- 6. Why would one implement a system as microservices? @christianposta
- 7. Pain we may feel… • Making changes in one place negatively affects unrelated areas • Low confidence making changes that don’t break things • Spend lots of time trying to coordinate work between team members • Structure in the application has eroded or is non- existant • We have no way to quantify how long code merges will@christianposta
- 8. • Development time is slow simply because the project is so big (IDE bogs down, running tests is slow, slow bootstrap time, etc) • Changes to one module force changes across other modules • Difficult to sunset outdated technology • We’ve built our new applications around old premises like batch processing • Application steps on itself at runtime managing resources, allocations, computations Pain we may feel…
- 9. Ask a very honest, and critical, question: Is our application architecture the bottleneck for being able to go faster? @christianposta
- 10. “No”, “Not really”, “Not yet”… then stop Go find out what is. Improve that. Then come back.
- 11. @christianposta Pioneers, Settlers, Town Planners http://blog.gardeviance.org/2012/06/pioneers-settlers-and-town-planners.html
- 14. MVP tests, experiments, small apps (co-locate if you have to write an app), leverage serverless? possibly… Product development, initial scale (co-locate perfectly okay!! Microservices? possibly…) Starting to feel the weight of maintenance, need to shoot for efficiencies, integrate new approaches to increase revenue (microservices land) http://blog.gardeviance.org/2012/06/pioneers-settlers-and-town-planners.html
- 15. DON’T optimize for microservices if… • You’re building a Minimum Viable Product (MVP), testing a hypothesis • You’re building a CRUD application • Your application is simple • Your system doesn’t have > 10 people all trying to coordinate to work on it • Your application doesn’t need to scale • You deliver packaged software • You’re building HPC systems
- 16. https://www.infoq.com/articles/cloud-native-panel "Cloud native” describes applications, architectures, platforms/infrastructure, and processes, that together make it economical to work in small batches to learn and reduce uncertainty. @christianposta
- 18. @christianposta Come on… how hard can it be!?
- 19. @christianposta
- 20. @christianposta
- 21. As we move to services architectures, we push the complexity to the space between our services. @christianposta
- 22. New challenges in a cloudy, services world • Service discovery • Retries • Timeouts • Load balancing • Rate limiting • Thread bulk heading • Circuit breaking @christianposta
- 23. …continued • Routing between services (adaptive, zone-aware) • Deadlines • Back pressure • Outlier detection • Health checking • Traffic shaping • Request shadowing @christianposta
- 24. …continued • Edge/DMZ routing • Surgical / fine / per-request routing • A/B rollout • Internal releases / dark launches • Fault injection • Stats, metric, collection • Logging • Tracing
- 26. • Netflix Hystrix (circuit breaking / bulk heading) • Netflix Zuul (edge router) • Netflix Ribbon (client-side service discovery / load balance) • Netflix Eureka (service discovery registry) • Brave / Zipkin (tracing) • Netflix spectator / atlas (metrics) “Microservices” patterns @christianposta
- 27. But I’m using Spring! • spring-cloud-netflix-hystrix • spring-cloud-netflix-zuul • spring-cloud-netflix-eureka-client • spring-cloud-netflix-ribbon • spring-cloud-netflix-atlas • spring-cloud-netflix-spectator • spring-cloud-netflix-hystrix-stream • ….. • ...... • @Enable....150differentThings
- 28. But I’m using Vert.x! • vertx-circuit-breaker • vertx-service-discovery • vertx-dropwizard-metrics • vertx-zipkin? • ….. • ...... @christianposta
- 29. 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
- 30. • 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 • Inconsistent implementations • Incorrect implementations Some drawbacks to this approach? @christianposta
- 31. What if we could push these concerns to the cloud platform / infrastructure? @christianposta
- 33. Meet Istio.io http://istio.io A service mesh for cloud-native applications
- 34. 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:
- 35. “mesh” part of service mesh
- 38. What does Istio do for you? • App Resilience • Request-level control • Graduated deployment and release • Service observability • Cluster reliability • Chaos testing • Policy enforcement
- 39. Resilience with timeouts, retries, budgets, circuit breakers, service discovery, etc @christianposta
- 40. Zone aware, sophisticated client-side load balancing @christianposta
- 41. Fine-grained traffic control and routing @christianposta
- 43. Secure transport with mTLS @christianposta
- 44. Metrics, logs, distributed tracing out of the box http://bit.ly/application-networking
- 45. ● Don’t adopt all functionality of a service mesh all at once ● Service mesh will impact a lot of areas in your organization; slowly introduce capabilities based on biggest wins ● Start by introducing gateways/proxies to collect metrics and go from there ● Install and manage Istio in lower environments, wait a few more releases before putting it into production Guidelines
- 47. @christianposta Another option? Serverless: outsourcing core infrastructure services to cloud providers and stitching it all together through APIs (and functions) to deliver business value
- 49. ● Pay only for usage without regard for topology (Serverless) ● Event driven by nature ● On demand ● Write only code, heavy lifting is handled for you ● High parallelization ● High utilization Functions as a Service (FaaS)
- 50. ● Usually not well understood ● MVPs are throwaway ● Usage patterns unknown ● Adoption unpredictable Exploratory use cases
- 51. ● Low number of hours/minutes of use ● Event-driven, spikey utilization ● Lots of compute for very short period of time ● Latency/startup time okay Under-utilization use cases
- 52. ● Webhook callbacks ● Scheduled tasks ● File processing ● Reacting to database changes ● Limited stream processing Limited integration use cases
- 53. ● Improve automation and ability to deploy software quickly ● Leverage cloud platforms ● Use microservices when your application architecture has become a bottleneck ● Take a piece by piece approach to adopting service mesh ● Use monoliths/start simple when exploring new problem domains ● Use serverless for exploration, spikey, and service- integration Recommendations
- 54. 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://launch.openshift.io • http://istio.io • http://envoyproxy.io • http://developers.redhat.com/blog • http://blog.christianposta.com/istio-workshop/slides/ • http://blog.openshift.com • https://www.redhat.com/en/open-innovation-labs
Notes de l'éditeur
- Optimized for speed…. Speed of what?! Raw Performance? Speed of competition? Like agile? How many in this room practice agile?
- Open question to the audience: Looking for participation
- Inherently unknown….
- "Cloud native" is an adjective that describes the applications, architectures, platforms/infrastructure, and processes, that together make it *economical* to work in a way that allows us to improve our ability to quickly respond to change and reduce unpredictability. This includes things like services architectures, self-service infrastructure, automation, continuous integration/delivery pipelines, observability tools, freedom/responsibility to experiment, teams held to outcomes not output, etc.
- …… 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
- 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.
- 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
- 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.
- …… new challenge….. Let’s come back to that…..