Come for the traffic management, stay for the security

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

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

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.

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.

A quick glance into the Microservices architecture and what the architecture offers over its precursor - Monolith Architecture

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.

Spring Cloud/Netflix OSS way of building microservices on Kubernetes -- preso from Spring One Platform 2016

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.

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.

The document discusses cloud-native application architectures and how they enable speed, safety, and scale through approaches like twelve-factor applications and microservices. It outlines the cloud-native stack and where governance is needed to secure different components like code, orchestration tools, containers, services, and infrastructure. The document argues that while cloud-native approaches are well-suited for technology companies, traditional enterprises face challenges in fully adopting these architectures due to differences in priorities, skills, and scale.

Service mesh abstracts the network from developers to solve three main pain points: How do services communicate securely with one another How can services implement network resilience When things go wrong, can we identify what and why Service mesh implementations usually follow a similar architecture: traffic flows through control points between services (usually service proxies deployed as sidecar processes) while an out-of-band set of nodes is responsible for defining the behavior and management of the control points. This loosely breaks out into an architecture of a "data plane" through which requests flow and a "control plane" for managing a service mesh. Different service mesh implementations use different data planes depending on their use cases and familiarity with particular technology. The control plane implementations vary between service-mesh implementations as well. In this talk, we'll take a look at three different control plane implementations with Istio, Linkerd and Consul, their strengths, and their specific tradeoffs to see how they chose to solve each of the three pain points from above. We can use this information to make choices about a service mesh or to inform our journey if we choose to build a control plane ourselves.

If you have an existing Java monolith, you know you must take care making changes to it or altering it in any negative way. Often times these monoliths are very valuable to the business and generate a lot of revenue. At the same time, since it’s difficult to make changes to the monolith it’s desirable to move to a microservices architecture. Unfortunately you cannot just do a big-bang migration to a greenfield architecture and will have to incrementally adopt microservices. In this talk, we’ll look at using Gloo proxy which is based on Envoy Proxy and GraphQL to do surgical, function-level traffic control and API aggregation to safely migrate your monolith to microservices and serverless functions.

Today’s products - devices, software and services - are well instrumented to permit users, vendors and service providers to gather maximum insight into how they are used, when they need repair and many other operational insights. Ensuring that products can rapidly adapt to a constantly changing environment and changing customer needs requires that the events they generate are analyzed continuously and in context. Insights can be synthesized from many sources in context - geospatial and proximity, trajectory and even predicted future states.Customers, vendors and service providers need to analyze, learn, and predict directly from streaming events because data volumes are huge and automated responses must often be delivered in milliseconds. To achieve insights quickly, we need to build models on-the-fly whose predictions are accurate and in sync with the real world, often to support automation. Many insights depend on analyzing the joint evolution of data sources whose behavior is correlated in time or space.In this talk we present Swim, an Apache 2.0 licensed platform for continuous intelligence applications. Swim builds a fluid model of data sources and their changing relationships in real-time - Swim applications analyze, learn and predict directly from event data. Swim applications integrate with Apache Kafka for event streaming. Developers need nothing more than Java skills. Swim deploys native or in containers on k8s, with the same code in each instance. Instances link to build an application layer mesh that facilitates distribution and massive scale without sacrificing consistency. We will present several continuous intelligence applications in use today that depend on real-time analysis, learning and prediction to power automation and deliver responses that are in sync with the real-world. We will show how easy it is to build, deploy and run distributed, highly available event streaming applications that analyze data from hundreds of millions of sources - petabytes per day. The architecture is intuitively appealing and blazingly fast.

The document discusses how being reactive is good. It argues that reactive principles like being asynchronous, non-blocking, elastic and resilient help engineers, businesses and enterprises capture opportunities. Being message-driven and responsive to events within the business and market allows systems to scale efficiently. The Lightbend Reactive Platform and tools like Akka and Play can be used to build fully reactive microservices systems that are responsive, elastic and resilient. Reactive architectures allow modernizing existing systems and responding to changes in technology, users and opportunities.

Embracing open source software for critical platform operations is a tough organizational evolution for a company of any size. This is particularly daunting for technology teams accustomed to a fully supported managed service. Come learn about how we are using OSS to modernize Health Care at UnitedHealth Group as a roadmap to adopt and offer OSS in your own organization! Over the last three years, Kafka as a Service within UnitedHealth Group has gone from non-existent to being centrally managed and utilized by over 200 internal application teams as an essential component to our ecosystem. In this session, I will share how to tactically implement a Kafka as a Service platform offering within any organization with a very lean team and how to get broad adoption from engineers and leadership. I'll discuss the engineering cultural changes needed, both on the DevOps team as well as more broadly, to adopt OSS. Spoiler: Documentation is the key to success. I will talk about some of our "aha" moments, including the importance of internal Terms of Service and how to encourage teams to "Google first." I will include things that haven't worked as well, such as requiring manual review of all topic creation PRs (this doesn't scale!). Attendees will learn how to both stand up their own OSS offering as well as how to be a good internal consumer of other such offerings. Come ready to learn and laugh about my journey to offering OSS to thousands of people!

Node.js is a very popular framework for developing asynchronous, event-driven, reactive applications. Red Hat JBoss Data Grid, an in-memory distributed database designed for fast access to large volumes of data and scalability, has recently gained compatibility with Node.js letting reactive applications use it as a persistence layer. Thanks to near caching, JBoss Data Grid offers excellent response times for data queried regularly, and its continuous remote event support means data can get pushed from the data grid to the Node.js application instead of having to wait for the data grid to serve it. In this session, we'll show how to build Node.js applications that use JBoss Data Grid as a persistence layer.

A quick overview of application networking and microservice resilience and how a service mesh like Istio.io can help alleviate some of this pain.