Atlanta Microservices Day: Istio Service Mesh

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

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.

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.

The document discusses microservices and APIs. It covers how microservices optimize for speed by shedding dependencies and having dependencies on demand through services and APIs. It discusses consumer contracts for APIs and service versioning. It also discusses using an API gateway pattern for scalability, security, monitoring and more. It promotes API management for benefits like access control, analytics, and monetization of microservices.

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.

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.

The document summarizes the new features of Istio 1.1, an open-source service mesh. Some key highlights include improved performance and scalability, namespace isolation, multi-cluster capabilities, easier installation with Helm, and locality-aware load balancing. A new Sidecar resource was introduced to improve performance by configuring resources for individual proxies. The presentation demonstrates performance improvements with the Sidecar resource and highlights additional functionality in Istio like traffic control and metrics collection.

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.

Microservices architecture is a very powerful way to build scalable systems optimized for speed of change. To do this, we need to build independent, autonomous services which by definition tend to minimize dependencies on other systems. One of the tenants of microservices, and a way to minimize dependencies, is “a service should own its own database”. Unfortunately this is a lot easier said than done. Why? Because: your data. We’ve been dealing with data in information systems for 5 decades so isn’t this a solved problem? Yes and no. A lot of the lessons learned are still very relevant. Traditionally, we application developers have accepted the practice of using relational databases and relying on all of their safety guarantees without question. But as we build services architectures that span more than one database (by design, as with microservices), things get harder. If data about a customer changes in one database, how do we reconcile that with other databases (especially where the data storage may be heterogenous?). For developers focused on the traditional enterprise, not only do we have to try to build fast-changing systems that are surrounded by legacy systems, the domains (finance, insurance, retail, etc) are incredibly complicated. Just copying with Netflix does for microservices may or may not be useful. So how do we develop and reason about the boundaries in our system to reduce complexity in the domain? In this talk, we’ll explore these problems and see how Domain Driven Design helps grapple with the domain complexity. We’ll see how DDD concepts like Entities and Aggregates help reason about boundaries based on use cases and how transactions are affected. Once we can identify our transactional boundaries we can more carefully adjust our needs from the CAP theorem to scale out and achieve truly autonomous systems with strictly ordered eventual consistency. We’ll see how technologies like Apache Kafka, Apache Camel and Debezium.io can help build the backbone for these types of systems. We’ll even explore the details of a working example that brings all of this together.

Building microservices requires more than just infrastructure, but infrastructure does have a role. In this talk we look at microservices from an enterprise perspective and talk about DDD, Docker, Kubernetes and how established open-source projects in the integration space fits a microservices architecture

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.

Microservices are everywhere and they help in solving business problems. But they also introduce complexity. Istio Service Mesh will help you solve it.

The document discusses continuous delivery of integration applications using JBoss Fuse and OpenShift. It covers the cost of change in software development, how JBoss Fuse can help with integration challenges, and how OpenShift enables continuous delivery through automation and a developer self-service platform as a service model. The presentation demonstrates how to build a continuous delivery pipeline using tools like Git, Jenkins, Fabric8, and OpenShift to deploy and test applications.

This document discusses microservices with Docker, Kubernetes and Jenkins. It provides an overview of Kubernetes concepts like pods, replication controllers, services and labels. It also discusses how Kubernetes can help manage containers across multiple hosts and address challenges of scaling, avoiding port conflicts and keeping containers running. The document promotes using Jenkins and Kubernetes for continuous integration and delivery of containerized microservices applications. It recommends Fabric8 as a tool that can help create and deploy microservices on Kubernetes.

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.

Istio is a service mesh, and it's a cool new project from Google, IBM, Lyft and others. This talk describes at a high level how Istio works as a sidecar, and how it works great with Weave Cloud, which provides visualization to understand what's going on when you deploy Istio, and long-term Prometheus metrics storage with its built-in Prometheus service.

Making it easy to integrate legacy and iterative microservices with REST/CQRS and deploy to Docker/Kubernetes/OpenShift all on a developer laptop!

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.

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.

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.

1) The document discusses best practices for running microservices at scale, including breaking monolithic architectures into loosely coupled microservices, using the right tools for each job, securing services, focusing on organizational transformation, and automating everything. 2) Five principles for running microservices are outlined: microservices only rely on each other's public APIs, using the right tool for the job, securing services with defense-in-depth, focusing on cross-functional teams for alignment, and automating everything. 3) Examples of event-driven serverless architectures using AWS Lambda and other AWS services are provided.

Speaker: Owen Garrett Sr. Director, Product Management NGINX, Inc. On-Deman Link: https://www.nginx.com/resources/webinars/need-service-mesh/ About the webinar: Service mesh is one of the hottest emerging technologies. Even though it’s a nascent technology, many vendors have already released their implementation. But do you really need a service mesh? Attend this webinar to learn about the levels of maturity on the journey to modernizing your apps using microservices, and the traffic management approaches best suited to each level. We’ll help you figure out if you really need a service mesh.

This session is targeted towards teams and organizations considering to migrate their applications from monolithic to Microservice architecture by proposing Istio as an enabler. Istio is an implementation of service mesh, a technology useful for migrating to Microservices iteratively and safely. Migrating application architectures to Microservices is considered a key area of transformation in the IT world. Modernizing legacy applications to Kubernetes-based Microservices can prove to be very challenging if not planned correctly, taking into consideration the right technologies and enablers. This session explains how Istio can be used as a bridge and enabler for modernizing legacy monolithic applications to Microservices. Topics covered in the session will include: 1- Advantages of migrating to Microservices and service mesh . 2- Designing a Microservice application based on splitting an existing monolithic application. 3- Implementing Microservices iteratively as a strangler fig application with Istio. 4- Features Istio provides as a service mesh platform.

These are my summarized notes from all the microservices session I attended at QCon 2015. These sessions had tons of learning around how to scale microservices and avoid common pitfalls

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.

Guest lecture talk in the CMU's Foundation of Software Engineering course: http://www.cs.cmu.edu/~ckaestne/15313/2017/

This document discusses MySQL proxy technologies including MySQL Router, ProxySQL, and MariaDB MaxScale. It provides an overview of each technology, including when they were released, key features, and comparisons between them. ProxySQL is highlighted as a popular option currently with integration with Percona tools, while MySQL Router may become more widely used due to its support for MySQL InnoDB Cluster. MariaDB MaxScale is noted for its binlog routing capabilities. Overall the document aims to help people understand and choose between the different MySQL proxy options.

The nature of containerized, cloud-native applications is rapidly advancing with a fundamentally different architecture that will rely on service meshes with smarter proxies, traffic management, and enhanced observability for cooperating microservices, serverless functions, and complex workflows. In this session we will highlight the features that characterize this architectural transformation in the Docker cloud-native ecosystem.

Most large-scale web companies have evolved their system architecture from a monolithic application and monolithic database to a set of loosely coupled micro-services. Using examples from Google, eBay, and KIXEYE, this talk outlines the pros and cons of these different stages of evolution, and makes practical suggestions about when and how other organizations should consider migrating to micro-services. It concludes with some more advanced implications of a micro-services architecture, including SLAs, cost-allocation, and vendor-customer relationships within the organization.

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.

Weaveworks discusses Microservices and best practices Visit Weave Cloud: https://www.weave.works/product/cloud/ For more free talks, join our Weave Online User Group: https://www.meetup.com/Weave-User-Group/

Slides for the session "Microservices in Go with Go kit", delivered at DevConf.IN 2019 in Bengaluru, India.

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 provides an overview of microservices including: - Defining microservices and comparing them to SOA - The benefits of a microservices architecture like improved agility, scalability, and innovation - Common microservice patterns on AWS like serverless and container-based services - How microservices can address business problems like long feature cycles and technical problems like lack of testability - A customer story of how MYOB adopted microservices on AWS to support their online products - Tips for evolving architectures including focusing on automation, organizational structure, and individual service design.

Brief overview of the KubeCon USA 2017 from the participants perspective. Provides summary of the events and some glance of the event activities.

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.

Presentation given during Start Up Day Hong Kong on September 15, 2017 within the Architecture track

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.

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.