Cloud-native describes a way of building applications on a cloud platform to iteratively discover and deliver business value. We now have access to a lot of similar technology that the large internet companies pioneered and used to their advantage to dominate their respective markets. What challenges arise when we start building applications to take advantage of this new technology?
In this mini-conference, we'll cover what it means to build applications with microservices, how cloud-native integration and concepts like service mesh have evolved to solve some of those problems, and how the next iteration of application development with Functions as a Service (FaaS) and serverless computing fit into this landscape.
You'll hear from industry experts Burr Sutter and Christian Posta who recently authored a book Introducing Istio Service Mesh for Microservices about these topics.
Attendees should come away from this mini-conference with the following:
Understanding of what cloud-native means and how to use it to influence positive business outcomes
How integration has evolved to create, connect and manage cloud-native APIs
How service-mesh technology like Istio can solve the challenges introduced with cloud-native applications
How the next iteration of applications deliver with FaaS and serverless computing fits in with a world of monoliths, microservices, and APIs
These talks will be of value for developers, architects, operators, platform directors, and technology leaders.
After the presentations, please stay and join Christian, Burr and your peers for networking, food and drinks. All attendees will also receive a copy of Christian and Burr's new book: Introducing Istio Service Mesh for Microservices.
Come for the traffic management, stay for the securityChristian Posta
Service mesh implementations help move critical application networking functionality out of the applications and into the infrastructure. With a service mesh like Istio, for example, you can move complicated traffic routing, resiliency aspects, and top-line metric collection out of the application code. This helps you build complicated distributed systems a bit more safely. But can Istio help with solving security issues?
Christian Posta explores some of the ways Istio helps you build more secure systems with mutual TLS, OAuth 2.0, and JSON Web Token verification. Security starts with defining trust boundaries and establishing identities. Istio helps do this by leveraging SPIFEE to assign identity and lay the foundation for zero-trust application networking. Istio then leverages this identity to take over the issuance and management of workload identity documents (e.g., x509 certificates), which can then be used to provide client authentication and mTLS. Istio also helps with OAuth flows, JWT verification, RBAC/ABAC, and much more.
You may be drawn into using Istio for its traffic management functionality, but most customers Christian works with find themselves much more interested in the security aspects once they learn what they can do with it. Join in to see for yourself.
Service-mesh technology promises to deliver a lot of value to a cloud-native application, but it doesn't come without some hype. In this talk, we'll look at what is a "service mesh", how it compares to similar technology (Netflix OSS, API Management, ESBs, etc) and what options for service mesh exist today.
Microservices and Integration: what's next with Istio service meshChristian Posta
This document discusses microservices architectures and emerging technologies to support them. It introduces Envoy proxy as a sidecar proxy that implements common microservices patterns like circuit breaking and load balancing. It then introduces Istio as a control plane that manages Envoy proxies and provides higher-level capabilities like traffic management, security, and observability across microservices. The presentation argues that 2018 will be the year of service meshes, with Istio being a prominent example for managing microservices communication using Envoy proxies.
Multicluster Kubernetes and Service Mesh PatternsChristian Posta
Building applications for cloud-native infrastructure that are resilient, scalable, secure, and meet compliance and IT objectives gets complicated. Another wrinkle for the organizations with which we work is the fact they need to run across a hybrid deployment footprint, not just Kubernetes. At Solo.io, we build application networking technology on Envoy Proxy that helps solve difficult multi-deployment, multi-cluster, and even multi-mesh problems.
In this webinar, we’re going to explore different options and patterns for building secure, scalable, resilient applications using technology like Kubernetes and Service Mesh without leaving behind existing IT investments. We’ll see why and when to use multi-cluster topologies, how to build for high availability and team autonomy, and solve for things like service discovery, identity federation, traffic routing, and access control.
Atlanta Microservices Day: Istio Service MeshChristian Posta
The document discusses the evolution of application networking from individual microservices libraries to shared proxies like Envoy and service meshes like Istio. It notes that as applications adopt microservices architectures, many common concerns around distributed systems must be addressed, such as service discovery, load balancing, and fault tolerance. Initially, different frameworks offered individual libraries to handle these issues, but this led to inconsistencies and increased complexity. Envoy proxy and the Istio service mesh aim to provide a standardized and shared way to address these cross-cutting distributed system concerns for all services regardless of language or framework.
This document discusses Istio, an open-source service mesh that connects, secures, and manages microservices. Istio solves challenges of running hybrid cloud deployments by providing service communication and routing, observability through metric collection, and security through features like mTLS and workload identity. The document outlines Istio's capabilities and provides an architecture for running Istio across Kubernetes and virtual machine environments. A demo is presented to illustrate Istio's capabilities in hybrid deployments.
Lowering the risk of monolith to microservicesChristian Posta
This document summarizes one organization's journey from a monolithic application architecture to a microservices architecture. It describes some of the pains of maintaining a monolithic application. It then discusses strategies for breaking the monolith into independently deployable microservices at low risk, including identifying module boundaries, deploying and releasing services independently, virtualizing data integration, and using traffic mirroring. The goal is to increase development velocity while lowering risk.
We consider a microservices architecture to achieve an end goal, not because it's "the cool thing to do". Every organization looking to adopt this architecture must realize (and adhere) to a set of foundational principles. Guided by those principles, we can correctly choose the technology to help support a microservices architecture and meet our end goals. This talk explains those core principles and gives you the tools needed for your microservices journey.
Knative builds on Kubernetes and Istio to provide "PaaS-like abstractions" that raise the level of abstraction for specifying, running, and modifying applications. Knative includes building blocks like Knative Serving for autoscaling container workloads to zero, Knative Eventing for composing event-driven services, Knative Build for building containers from source, and Knative Pipelines for abstracting CI/CD pipelines. While Knative can run any type of container, its building blocks help enable serverless-style functions by allowing compute resources to scale to zero and be driven by event loads.
The exploration of service mesh for any organization comes with some serious questions. What data plane should I use? How does this tie in with my existing API infrastructure? What kind of overhead do sidecar proxies demand? As I've seen in my work with various organizations over the years "if you have a successful microservices deployment, then you have a service mesh whether it’s explicitly optimized as one or not."
In this talk, we seek to understand the role of the data plane and how to pick the right component for the problem context. We start off by establishing the spectrum of data-plane components from shared gateways to in-code libraries with service proxies being along that spectrum. We clearly identify which scenarios would benefit from which part of the data-plane spectrum and show how modern service meshes including Istio, Linkerd, and Consul enable these optimizations.
Eight Miles High: Build Cloud-native and Cloud-aware SystemsChris Haddad
Achieve development agility, improve run-time application resiliency, and deliver highly-responsive applications by adopting cloud-native design patterns and building cloud-aware applications. Forklifting applications into the cloud is relatively fast, but the simple path into the cloud does not create better software. End-users may still complain about your development velocity, operations may still struggle to maintain uptime guarantees, and development iterations may continue at a glacial pace. By iteratively applying cloud-native design patterns and re-architecting applications, teams reduce technical debt, deploy with confidence, and build highly scalable solutions. Cloud-aware applications embrace microservices, actor model interactions, map-reduce processing, shared-nothing architecture, and the thirteen dwarf patterns. Learn about cloud-native design practices and frameworks that help you optimize scalability, foster anti-fragility, and decompose application monoliths into cloud-native microservices. Chris describes how Kubernetes, Akka, Hadoop, Eureka, Hysterix, and other open source projects make cloud-native design and implementation an approachable proposition.
Role of edge gateways in relation to service mesh adoptionChristian Posta
API Gateways provide functionality like rate limiting, authentication, request routing, reporting, and more. If you’ve been following the rise in service-mesh technologies, you’ll notice there is a lot of overlap with API Gateways when solving some of the challenges of microservices. If service mesh can solve these same problems, you may wonder whether you really need a dedicated API Gateway solution?
The reality is there is some nuance in the problems solved at the edge (API Gateway) compared to service-to-service communication (service mesh) within a cluster. But with the evolution of cluster-deployment patterns, these nuances are becoming less important. What’s more important is that the API Gateway is evolving to live at a layer above service mesh and not directly overlapping with it. In other words, API Gateways are evolving to solve application-level concerns like aggregation, transformation, and deeper context and content-based routing as well as fitting into a more self-service, GitOps style workflow.
In this talk we put aside the “API Gateway” infrastructure as we know it today and go back to first principles with the “API Gateway pattern” and revisit the real problems we’re trying to solve. Then we’ll discuss pros and cons of alternative ways to implement the API Gateway pattern and finally look at open source projects like Envoy, Kubernetes, and GraphQL to see how the “API Gateway pattern” actually becomes the API for our applications while coexisting nicely with a service mesh (if you adopt a service mesh).
This document discusses service mesh patterns for connecting microservices across multiple clusters. It describes using Envoy proxy to provide service discovery, load balancing, security and resiliency. Patterns are presented for connecting services across clusters with flat, controlled or separate networks. Managing connectivity across clusters can increase operator burden. Gloo Mesh is presented as a way to simplify management across multiple clusters with a centralized control plane.
The document discusses microservices architecture. It defines microservices as an approach to developing a single application as a suite of small services that communicate with each other via lightweight mechanisms like HTTP APIs. Each service runs independently, is built around business capabilities, and can be deployed independently. There is minimal centralized management of services, which can use different programming languages and data storage technologies.
A presentation on why or why not microservices, why a platform is important, discovering how to break down a monolith and some of the challenges you'll face (data, transactions, boundaries, etc). Last section is on Istio and service mesh introductions. Follow on twitter @christianposta for updates and more details
- Integration microservices are used to compose other microservices and APIs to create new services, similar to the concept of "miniservices". They help integrate web APIs, legacy systems, and microservices.
- Technologies for building integration microservices include frameworks like SpringBoot and Dropwizard, Apache Camel, and the Ballerina programming language. Ballerina is designed specifically for integration and allows graphical composition of services and connectors.
- Integration microservices are an important part of microservices architecture as they handle service compositions and orchestration between multiple microservices and external APIs.
The document discusses Christian Posta's journey with microservices architectures. It begins by explaining why organizations are moving to microservices and defines microservices. It then covers related topics like cloud platforms, container technologies like Kubernetes and OpenShift, benefits and drawbacks of microservices, and tools for developing microservices like Docker, Kubernetes, OpenShift, and Camel.
This document discusses microservices architecture and related concepts. It begins with an overview of microservices compared to earlier SOA approaches. Key aspects of microservices covered include developing single applications as independent services, common misconceptions, principles like single responsibility, and defining appropriate service boundaries. The document also discusses messaging approaches in microservices including REST, gRPC, and asynchronous messaging. Other sections cover organizing microservices, deployment, security, data management, governance, bridging monolithic and microservice systems, and implementing a service mesh.
Microservices Integration Patterns with KafkaKasun Indrasiri
Microservice composition or integration is probably the hardest thing in microservices architecture. Unlike conventional centralized ESB based integration, we need to leverage the smart-endpoints and dumb pipes terminology when it comes to integrating microservices.
There two main microservices integration patterns; service orchestration (active integrations) and service choreography (reactive integration). In this talk, we will explore on, Microservice Orchestration, Microservice Choreography, Event Sourcing, CQRS and how Kafka can be leveraged to implement microservices composition
The Hardest Part of Microservices: Calling Your ServicesChristian Posta
When building microservices, you must solve for a number of critical functions, but the process can be incredibly complex and expensive to maintain. Christian Posta offers an overview of Envoy Proxy and Istio.io Service Mesh, explaining how they solve application networking problems more elegantly by pushing these concerns down to the infrastructure layer and demonstrating how it all works.
Evolution of integration and microservices patterns with service meshJudy Breedlove
The document discusses the evolution of integration and microservice patterns with service mesh technologies like Istio. It describes how service meshes provide decentralized application networking infrastructure between services through a data plane and control plane. This includes features like advanced load balancing, traffic control, observability, and policy enforcement that help improve resilience, security, and reliability of distributed applications.
We consider a microservices architecture to achieve an end goal, not because it's "the cool thing to do". Every organization looking to adopt this architecture must realize (and adhere) to a set of foundational principles. Guided by those principles, we can correctly choose the technology to help support a microservices architecture and meet our end goals. This talk explains those core principles and gives you the tools needed for your microservices journey.
This document provides an overview of microservices from Christian Posta, a chief architect at Red Hat. It discusses what microservices are, reasons for using them, common microservices patterns and frameworks, decomposing monolithic applications into microservices, and ensuring resilience between services. The presentation also covers using Kubernetes and OpenShift for microservices and demonstrates sample applications.
Role of Integration and Service Mesh in Cloud Native Architecture KubeCon 2108Ballerina
Building useful services across our collection of existing applications, microservices, and now functions, we see a common theme: services must be able to communicate with each other, and solve problems like data mediation, routing, policy enforcement, security, and others. Service mesh is a technology that has emerged in container-based environments to help solve some of these problems; however, not all of them can be solved by pushing the problems to a different abstraction. Understanding the role and responsibility of service mesh and application-integration frameworks can help you successfully build useful business services on a cloud native platform. This talk will help you understand those roles and responsibilities and how service mesh and application integration co-exist to build cloud native applications.
Early Draft: Service Mesh allows developers to focus on business logic while the crosscutting network data layer code is handled by the Service Mesh. This is a boon because this code can be tricky to implement and hard to test all of the edge cases. Service Mesh takes this a few steps further than AOP or Servlet Filters or custom language-specific frameworks because it works regardless of the underlying programming language being used which is great for polyglot development shops. Thus standardizing how these layers work, while allowing teams to pick the best tools or languages for the job at hand. Kubernetes and Istio Service Mesh automate best practices for DevSecOps needs like: failover, scale-out, scalability, health checks, circuit breakers, rate limiters, metrics, observability, avoiding cascading failure, disaster recovery, and traffic routing; supporting CI/CD and microservices architecture.
Istio’s ability to automate and maintaining zero trust networks is its most important feature. In the age of high-profile data breaches, security is paramount. Companies want to avoid major brand issues that impact the bottom line and shrink market capitalization in an instant. Istio allows a standard way to do mTLS and auto certificate rotation which helps prevent a breach and limits the blast radius if a breach occurs. Istio also takes the concern of mTLS from microservices deployments and makes it easy to use taking the burden off of application developers.
10 yrs ago, SOA promised a lot of the same things Microservices promise use today. So where did we go wrong? What makes microservices different? In this talk, we discussed from an architectural view how we went sideways with SOA, why we must embrace things like Domain Driven Design and scaled-out architectures, and how microservices can be built with enterprises in mind. We also cover a step-by-step, in-depth tutorial that covers these concepts.
The document discusses microservices for Java developers. It introduces Christian Posta, a principal middleware specialist and architect who works with large microservices and is a blogger and speaker on topics like DevOps, integration, and microservices. It then discusses how creating value through software is about speed, iteration, and continuous improvement. It covers concepts like distributed configuration, service discovery, load balancing, circuit breakers, and versioning/routing that are important for microservices. Finally, it mentions container cluster management with Kubernetes and technologies like Kubernetes, OpenShift, and Fabric8 that can help with microservices development.
Techniques for scaling application with security and visibility in cloudAkshay Mathur
Akshay Mathur gives a presentation on techniques for scaling applications with security and visibility in the cloud. He discusses 8 growth phases applications typically go through including load balancing, gaining insights, content optimization, offloading services, content switching, preventing bot traffic and DDoS attacks, continuous delivery, and the need for a unified cloud application front end solution to manage these phases. He introduces Appcito CAFE as a service that provides capabilities across availability, performance, security and DevOps to simplify application scaling in the cloud.
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.
Effective Service Mesh to turbocharge Cloud ResiliencyLiang Gang Yu
This document discusses how service meshes can turbocharge cloud resiliency. It describes some key challenges with inter-service communication like failures, latency, routing, and observability. It then explains how a service mesh provides a dedicated infrastructure layer to address these issues through capabilities like traffic management, circuit breaking, telemetry, and fault injection. Specifically, it outlines how the service mesh provides resiliency through active health checks, timeouts, retries, and circuit breaking in the data plane. It also discusses capabilities for observability, tracing, and injecting faults to test resiliency.
This talk provides an architecture overview of data-centric microservices illustrated with an example application. The following Microservices concepts are illustrated - domain driven design, event-driven services, Saga transactions, Application tracing and Health monitoring with different microservices using a variety of data types supported in the database - business data, documents, spatial, graph, and events. A running example of a mobile food delivery application (called GrubDash) is used, with a hands-on-lab that is available for attendees to work through on the Oracle Cloud after these sessions. The rest of the talks will build upon this Microservices architecture framework.
From Monoliths to Services: Paying Your Technical DebtTechWell
This document discusses transitioning from monolithic applications to microservices and serverless architectures. It begins by defining technical debt and explaining how microservices can help pay it down incrementally. It then covers different architectural styles like monoliths and microservices. The rest of the document discusses moving to cloud infrastructure, breaking apart monolithic applications into independent services, communication between services, leveraging third-party services, and security considerations for microservices.
Beyond DevOps: How Netflix Bridges the Gap?C4Media
Video and slides synchronized, mp3 and slide download available at URL http://bit.ly/1mv6Kpr.
Josh Evans uses the Netflix Operations Engineering as a case study to explore the challenges faced by centralized engineering teams and approaches to addressing those challenges. Filmed at qconsf.com.
Josh Evans is Director of Operations Engineering at Netflix, with experience in e-commerce, playback control services, infrastructure, tools, testing, and operations.
This document discusses when a service mesh may be needed and provides an overview of the current service mesh landscape. It begins with why microservices are adopted and the challenges of operating distributed applications. It then describes a maturity journey where a service mesh is not initially needed but may become useful for applications that become more complex, distributed, and interdependent. The document outlines some current major service mesh implementations and notes that the technology is still new and changing rapidly. It recommends investigating service meshes through proof of concepts but cautions that production usage requires significant resources. It profiles F5 Aspen Mesh and NGINX solutions for service meshes and microservices.
This document compares and contrasts microservice architecture (MSA) and service-oriented architecture (SOA). SOA defines application components as loosely coupled services that communicate over a network, while MSA develops applications as suites of small services communicating via lightweight mechanisms like REST. The document also discusses Netflix's transition from a monolithic to a microservices architecture led by Adrian Cockcroft, highlighting benefits like speed, autonomy, and flexibility.
This document discusses cloud-native data and patterns for managing data in microservices architectures. It describes using data services and APIs to interface with existing data sources. Patterns like caching data at the edge with various caching strategies are discussed. The document also covers using multiple small databases with each microservice rather than a shared database. Event sourcing and CQRS patterns are presented as ways to integrate data across services. Finally, the impact on roles like database administrators is considered in cloud-native data environments.
<November 2017 Updated from earlier presentations on Cloud-native Data>
Cloud-native applications form the foundation for modern, cloud-scale digital solutions, and the patterns and practices for cloud-native at the app tier are becoming widely understood – statelessness, service discovery, circuit breakers and more. But little has changed in the data tier. Our modern apps are often connected to monolithic shared databases that have monolithic practices wrapped around them. As a result, the autonomy promised by moving to a microservices application architecture is compromised.
What we need are patterns and practices for cloud-native data. The anti-patterns of shared databases and simple proxy-style web services to front them give way to approaches that include use of caches (Netflix calls caching their hidden microservice), database per service and polyglot persistence, modern versions of ETL and data integration and more. In this session, aimed at the application developer/architect, Cornelia will look at those patterns and see how they serve the needs of the cloud-native application.
Are you jumping on the microservices bandwagon? When and when not to adopt micro services architecture? If you must, what are the considerations? This slidedeck will help answer a few of those questions...
Similar to Evolution of integration and microservices patterns with service mesh (20)
Move Auth, Policy, and Resilience to the PlatformChristian Posta
Developer's time is the most crucial resource in an enterprise IT organization. Too much time is spent on undifferentiated heavy lifting and in the world of APIs and microservices much of that is spent on non-functional, cross-cutting networking requirements like security, observability, and resilience.
As organizations reconcile their DevOps practices into Platform Engineering, tools like Istio help alleviate developer pain. In this talk we dig into what that pain looks like, how much it costs, and how Istio has solved these concerns by examining three real-life use cases. As this space continues to emerge, and innovation has not slowed, we will also discuss the recently announced Istio sidecar-less mode which significantly reduces the hurdles to adopt Istio within Kubernetes or outside Kubernetes.
Comparing Sidecar-less Service Mesh from Cilium and IstioChristian Posta
Service mesh is a powerful pattern for implementing strong zero-trust networking practices, introducing better network observability, and allowing for more fine-grained traffic control. Up until now, the sidecar pattern was used to implement service-mesh capability but as the technology matures, a new pattern has emerged: sidecarless service mesh. Two prominent open-source networking projects, Cilium and Istio, have implemented a sidecar-free approach to service mesh but they both make interesting design decisions and tradeoffs. In this talk we review the architecture of both, focusing on the pros and cons of implementations such as mutual authentication, ingress, and observability.
Understanding Wireguard, TLS and Workload IdentityChristian Posta
Zero Trust Networking has become a standard marketing buzzword but the underlying principles are critical for modern microservice-style architectures. Authentication, authorizations, policy, etc. can be difficult to implement between services and do so in a maintainable way. Google invented their own transparent encryption and authorization protocol called "ALTS" back in 2007 to serve the application layer of Google's Borg workload scheduler, but we don't see others using it outside Google.
In this webinar we look at existing technology like TLS and newcomer Wireguard and see how these technologies come together to provide a secure foundation for workload identity and modern service-to-service networking.
Istio ambient mesh uses a sidecar-less data plane that focuses on ease of operations, incremental adoption, and separation of security boundaries for applications and mesh infrastructure.
In this webinar, we'll explore:
- The forces of modernization and compliance pressures,
- How Zero Trust Architecture (ZTA) can help, and
- How Istio ambient mesh lowers the barrier for establishing the properties necessary to achieve Zero Trust and compliance
The document discusses Cilium and Istio with Gloo Mesh. It provides an overview of Gloo Mesh, an enterprise service mesh for multi-cluster, cross-cluster and hybrid environments based on upstream Istio. Gloo Mesh focuses on ease of use, powerful best practices built in, security, and extensibility. It allows for consistent API for multi-cluster north-south and east-west policy, team tenancy with service mesh as a service, and driving everything through GitOps.
Cloud-Native Application Debugging with Envoy and Service MeshChristian Posta
Microservices have been great for accelerating the software innovation and delivery, but they also present new challenges, especially as abstractions and automated orchestration at every layer make pinpointing the issue seem like walking around a maze with a blindfold. Existing tools weren’t designed for distributed environments, and the new tools need to consider how to leverage these abstraction layers to better observe, test, and troubleshoot issues.
Christian Posta walks you through Envoy Proxy and service mesh architecture for L7 data plane, the key features in Envoy that can help in debugging and troubleshooting, chaos engineering as a testing methodology for microservices, how to approach a testing and debugging framework for microservices, and new open source tools that address these areas. You’ll explore a workflow to discover and resolve microservices issues, including injecting experiments for stress testing the applications, gathering requests in flight, recording and replaying them, and debugging them step by step without affecting production traffic.
Kubernetes Ingress to Service Mesh (and beyond!)Christian Posta
Kubernetes users need to allow traffic to flow into and within the cluster. Treating the application traffic separately from the business logic allows presents new possibilities in how service to service traffic is served, controlled and observed — and provides a transition to intra cluster networking like Service Mesh. With microservices, there is a concept of both North / South traffic (incoming requests from end users to the cluster) and East / West (intra cluster) communication between the services. In this talk we will explain how Envoy Proxy works in Kubernetes as a proxy for both of these traffic directions and how it can be leveraged to do things like traffic shaping, security, and integrate the north/south to east/west behavior.
Christian Posta (@christianposta) is Global Field CTO at Solo.io, former Chief Architect at Red Hat, and well known in the community for being an author (Istio in Action, Manning, Istio Service Mesh, O'Reilly 2018, Microservices for Java Developers, O’Reilly 2016), frequent blogger, speaker, open-source enthusiast and committer on various open-source projects including Istio, Kubernetes, and many others. Christian has spent time at both enterprises as well as web-scale companies and now helps companies create and deploy large-scale, cloud-native resilient, distributed architectures. He enjoys mentoring, training and leading teams to be successful with distributed systems concepts, microservices, devops, and cloud-native application design.
Deep Dive: Building external auth plugins for Gloo EnterpriseChristian Posta
Using the plugin framework for Ext. Auth Service in Gloo Enterprise, we can build any custom AuthN/AuthZ plugins to handle security requirements not provided out of the box.
Navigating the service mesh landscape with Istio, Consul Connect, and LinkerdChristian Posta
The document discusses various service mesh options including Linkerd, Consul Connect, Istio, and AWS App Mesh. It provides an overview of each solution, describing their key features and strengths/opportunities. It emphasizes that the service mesh approach is useful for managing inter-service communication and that implementations are still evolving. It recommends starting simply and iteratively adopting capabilities to match needs.
Distributed microservices introduce new challenges: failure modes are harder to anticipate and resolve. In this session, we present a “Chaos Debugging” framework enabled by three open source projects: Gloo Shot, Squash, and Loop to help you increase your microservices’ “immunity” to issues.
Gloo Shot integrates with any service mesh to implement advanced, realistic chaos experiments. Squash connects powerful and mature debuggers (gdb, dlv, java debugging) to your microservices while they run in Kubernetes. Loop extends the capability of your service mesh to observe your application and record full transactions for sandboxed replay and debugging.
Come to this demo-heavy talk to see how together, Squash, Gloo Shot, and Loop allow you to trigger, replay, and investigate failure modes of your microservices in a language agnostic and efficient manner without requiring any changes to your code.
Sami provided a beginner-friendly introduction to Amazon Web Services (AWS), covering essential terms, products, and services for cloud deployment. Participants explored AWS' latest Gen AI offerings, making it accessible for those starting their cloud journey or integrating AI into coding practices.
React and Next.js are complementary tools in web development. React, a JavaScript library, specializes in building user interfaces with its component-based architecture and efficient state management. Next.js extends React by providing server-side rendering, routing, and other utilities, making it ideal for building SEO-friendly, high-performance web applications.
Software development... for all? (keynote at ICSOFT'2024)miso_uam
Our world runs on software. It governs all major aspects of our life. It is an enabler for research and innovation, and is critical for business competitivity. Traditional software engineering techniques have achieved high effectiveness, but still may fall short on delivering software at the accelerated pace and with the increasing quality that future scenarios will require.
To attack this issue, some software paradigms raise the automation of software development via higher levels of abstraction through domain-specific languages (e.g., in model-driven engineering) and empowering non-professional developers with the possibility to build their own software (e.g., in low-code development approaches). In a software-demanding world, this is an attractive possibility, and perhaps -- paraphrasing Andy Warhol -- "in the future, everyone will be a developer for 15 minutes". However, to make this possible, methods are required to tweak languages to their context of use (crucial given the diversity of backgrounds and purposes), and the assistance to developers throughout the development process (especially critical for non-professionals).
In this keynote talk at ICSOFT'2024 I presented enabling techniques for this vision, supporting the creation of families of domain-specific languages, their adaptation to the usage context; and the augmentation of low-code environments with assistants and recommender systems to guide developers (professional or not) in the development process.
Discover the Power of ONEMONITAR: The Ultimate Mobile Spy App for Android Dev...onemonitarsoftware
Unlock the full potential of mobile monitoring with ONEMONITAR. Our advanced and discreet app offers a comprehensive suite of features, including hidden call recording, real-time GPS tracking, message monitoring, and much more.
Perfect for parents, employers, and anyone needing a reliable solution, ONEMONITAR ensures you stay informed and in control. Explore the key features of ONEMONITAR and see why it’s the trusted choice for Android device monitoring.
Share this infographic to spread the word about the ultimate mobile spy app!
What is OCR Technology and How to Extract Text from Any Image for FreeTwisterTools
Discover the fascinating world of Optical Character Recognition (OCR) technology with our comprehensive presentation. Learn how OCR converts various types of documents, such as scanned paper documents, PDFs, or images captured by a digital camera, into editable and searchable data. Dive into the history, modern applications, and future trends of OCR technology. Get step-by-step instructions on how to extract text from any image online for free using a simple tool, along with best practices for OCR image preparation. Ideal for professionals, students, and tech enthusiasts looking to harness the power of OCR.
A captivating AI chatbot PowerPoint presentation is made with a striking backdrop in order to attract a wider audience. Select this template featuring several AI chatbot visuals to boost audience engagement and spontaneity. With the aid of this multi-colored template, you may make a compelling presentation and get extra bonuses. To easily elucidate your ideas, choose a typeface with vibrant colors. You can include your data regarding utilizing the chatbot methodology to the remaining half of the template.
WhatsApp Tracker - Tracking WhatsApp to Boost Online Safety.pdfonemonitarsoftware
WhatsApp Tracker Software is an effective tool for remotely tracking the target’s WhatsApp activities. It allows users to monitor their loved one’s online behavior to ensure appropriate interactions for responsive device use.
Download this PPTX file and share this information to others.
Efficient hot work permit software for safe, streamlined work permit management and compliance. Enhance safety today. Contact us on +353 214536034.
https://sheqnetwork.com/work-permit/
React Native vs Flutter - SSTech SystemSSTech System
Your project needs and long-term objectives will ultimately choose which of React Native and Flutter to use. For applications using JavaScript and current web technologies in particular, React Native is a mature and trustworthy choice. For projects that value performance and customizability across many platforms, Flutter, on the other hand, provides outstanding performance and a unified UI development experience.
An MVP (Minimum Viable Product) mobile application is a streamlined version of a mobile app that includes only the core features necessary to address the primary needs of its users. The purpose of an MVP is to validate the app concept with minimal resources, gather user feedback, and identify any areas for improvement before investing in a full-scale development. This approach allows businesses to quickly launch their app, test its market viability, and make data-driven decisions for future enhancements, ensuring a higher likelihood of success and user satisfaction.
In this talk, we will explore strategies to optimize the success rate of storing and retaining new information. We will discuss scientifically proven ideal learning intervals and content structures. Additionally, we will examine how to create an environment that improves our focus while you remain in the “flow”. Lastly we will also address the influence of AI on learning capabilities.
In the dynamic field of software development, this knowledge will empower you to accelerate your learning curve and support others in their learning journeys.
Responsibilities of Fleet Managers and How TrackoBit Can Assist.pdfTrackobit
What do fleet managers do? What are their duties, responsibilities, and challenges? And what makes a fleet manager effective and successful? This blog answers all these questions.
5. @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/
6. @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…
10. @christianposta
The end-to-end principle:
http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf
The function in question can completely and correctly be implemented only with the
knowledge and help of the application standing at the end points of the communication system.
Therefore, providing that questioned function as a feature of the communication system
itself is not possible. (Sometimes an incomplete version of the function provided by the
communication system may be useful as a performance enhancement.)
27. But I’m using Vert.x!
• vertx-circuit-breaker
• vertx-service-discovery
• vertx-dropwizard-metrics
• vertx-zipkin?
• …..
• ......
@christianposta
28. 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
29. • 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
33. 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
34. Envoy implements
• zone aware, least request load balancing
• circuit breaking
• outlier detection
• retries, retry policies
• timeout (including budgets)
• traffic shadowing
• rate limiting
• access logging, statistics collection
• Many other features!
39. 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:
42. What higher-order clusters semantics
does Istio enable?
• Request-level control
• Graduated deployment and release
• Service observability
• Cluster reliability
• Chaos testing
• Policy enforcement
43. Resilience with timeouts, retries, budgets,
circuit breakers, service discovery, etc
@christianposta
51. 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
Editor's Notes
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….
…… new challenge….. 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
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
Apache Camel can enable legacy backends to participate in a REST-based set of services by quickly exposing a REST service interface using its expressive DSL.. The DSL plugins right into the rest of the Apache Camel DSL allowing you to quickly expose a REST endpoint that can describe an API as well as integrate with backend services by mediating, routing, transforming and otherwise changing the shape of data or even content of a payload with enricher, resequence, and recipient list patterns.
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.
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.