Lowering the risk of monolith to microservices

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

Developing integration microservices using CI/CD with apache camel, open shift, fabric8.io, jenkins, et al.

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 talk we'll explore the role of service meshes when building distributed systems, why they make sense, and where they don't make sense. We will look at a class of problem that crops up that service mesh cannot solve, but that frameworks and even new programming languages like Ballerina are aiming to solve

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

Christian Posta, principal architect at Red Hat discusses how to manage your data within a microservices architecture at the 2017 Microservices.com Practitioner Summit.

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.

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

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

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

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

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.

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

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.

Diapositivas con el contenido de mi charla en el XXIII BetaBeers. Microservices vs Monolithics. Granada - 14/12/2017

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

What does it take to scale a system? We'll learn how going distributed can pay dividends in areas like availability and fault tolerance by examining a real-world case study. However, we will also look at the inherent pitfalls. When it comes to distributed systems, for every promise there is a peril.

Microservice oriented architectures have been implemented and deployed by many and are on the near-term agenda of many others. However, the distributed nature of microservices is a double edged sword, being the source of many of the benefits, but also the source of the pain and confusion that teams have endured. We will review best practices and recommended architectures for deploying microservices on AWS with a focus on how to exploit the benefits of microservices to decrease feature cycle times and costs while increasing reliability, scalability, and overall operational efficiency. Speaker: Craig Dickson, Solutions Architect, Amazon Web Services Featured Customer - MYOB

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.

This document discusses the benefits of adopting a microservices architecture, including enabling independent life cycles, independent scalability, and failure isolation. It provides examples of how microservices allow developing and deploying parts of an application independently, scaling specific services rather than the entire monolith, and isolating failures to prevent bringing down the whole system. The document advocates for a responsible and data-driven approach to migrating from a monolith to microservices over time.

The number of connected devices is growing at an accelerated pace. We developers must have the knowledge & skills to help make that happen. But how? As device deployments and data collected grow exponentially, DevOps is the answer to fast, consistent, and sane systems, organizations, and developers. This session will provide a brief-but-thorough examination of key DevOps tenets and how they apply to large-scale deployments of small-scale devices and the platforms that tie them together. A live-coding demo will convert these concepts from ideas to implementations.

A whistlestop tour of how we use DevOps at the University of Warwick to continuously deliver software

aka "Wisdom from the Masters, learned the Hard Way" Disclaimer: not an AWS talk. All views expressed are my own only.

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 the efforts of a €600M online gaming company to adopt DevOps practices across their organization. They had previously merged two gaming platforms with different architectures and teams worked in silos. To improve, they have undertaken an agile transformation, encouraged cultural changes in developers to take more ownership, adopted new tools like Git, Jenkins, Puppet and AppDynamics for monitoring, and are moving to containerize applications. Monitoring in particular has helped improve quality by providing visibility. They are also working to improve testing environments to better simulate production. The company aims to continuously deploy changes through proliferating environments and automating infrastructure as code.

This document discusses strategies for refactoring monolithic applications into microservices when migrating from a relational database to a NoSQL database. It describes splitting the monolith by fracturing modules into encapsulated services. Alternatively, it proposes strangling the monolith by gradually creating new services around the edges of the existing monolith. When migrating data, it also discusses moving from shared database tables to independent data ownership between services. The document advocates for independent release cycles and a share-nothing architecture between loosely coupled microservices.

SpringOne Platform 2016 Speakers: Christopher Tretina; Director, Comcast & Vipul Savjani; Director of PaaS, Accenture Comcast is embarking on a multi-year application modernization and transformation journey to achieve application resiliency, velocity and cost optimization at enterprise scale. We will discuss how we are addressing significant technical architecture, engineering, and delivery challenges faced in transformation of Comcast’s Enterprise Services Platform (ESP) from SOA architecture to Cloud-Native architecture using Microservices, DevOps, and PaaS.

So, the citizen developers have all the cool tools, and those that actually code for a living are left with legacy stuff? Not so fast! The same tools that Microsoft is targeting for citizen developers make development easier, faster and cheaper for everyone! This session combines tools such as Flow, Azure Cognitive Services and Azure Functions with some actual simple development work to provide highly customized, Machine Learning powered analysis workflow for the newly baked Modern Team Sites in SharePoint Online. This demo-heavy session will look at real business scenarios, and how we can solve them using citizen developer tools and some code (Because we’re developers after all, right?) After this session, you'll know how to create rich and customized business automation processes that use the latest tools offered to us by Microsoft.

The document discusses 11 strategic considerations for SharePoint migrations. It begins with introducing the author and their background experience with SharePoint migrations. Then it discusses the importance of focusing migrations on planning rather than just the technical aspects. The main part of the document outlines 11 strategies that should be considered as part of migration planning, including understanding current and target environments, conducting capacity planning, understanding customizations, migration schedules, types of migrations, file shares, metadata, centralized vs decentralized environments, staging platforms, user involvement, and determining migration success.

So, the citizen developers have all the cool tools, and those that actually code for a living are left with legacy stuff? Not so fast! The same tools that Microsoft is targeting for citizen developers make development easier, faster and cheaper for everyone! This session combines tools such as Flow, Azure Cognitive Services and Azure Functions with some actual simple development work to provide highly customized, Machine Learning powered analysis workflow for the newly baked Modern Team Sites in SharePoint Online. This demo-heavy session will look at real business scenarios, and how we can solve them using citizen developer tools and some code (Because we’re developers after all, right?) After this session, you'll know how to create rich and customized business automation processes that use the latest tools offered to us by Microsoft.

So, the citizen developers have all the cool tools, and those that actually code for a living are left with legacy stuff? Not so fast! The same tools that Microsoft is targeting for citizen developers make development easier, faster and cheaper for everyone! This session combines tools such as Flow, Azure Cognitive Services and Azure Functions with some actual simple development work to provide highly customized, Machine Learning powered analysis workflow for the newly baked Modern Team Sites in SharePoint Online. This demo-heavy session will look at real business scenarios, and how we can solve them using citizen developer tools and some code (Because we’re developers after all, right?) After this session you'll know how to create rich and customized business automation processes that use the latest tools offered to us by Microsoft.

Almost every tech organisation right from start-ups to unimaginably big ones have had monolithic applications in the past and have moved on to nimbler approaches like microservices, making use of powerful cloud technologies. But not every organisation has made this move yet, with most of them still in analysing phase. If you are part of this or interested in exploring how major players in the industry have managed to convert monoliths to microservices, join us in the talk to get an in-depth knowledge about things that could go wrong and how to make the right choices using AWS services. On top of practical techniques and real-life case studies, we will also be exploring agile methodologies and discuss if microservices are the right choice for your field of work.

Almost every tech organisation right from start-ups to unimaginably big ones have had monolithic applications in the past and have moved on to nimbler approaches like microservices, making use of powerful cloud technologies. But not every organisation has made this move yet, with most of them still in analysing phase. If you are part of this or interested in exploring how major players in the industry have managed to convert monoliths to microservices, join us in the talk to get an in-depth knowledge about things that could go wrong and how to make the right choices using AWS services. On top of practical techniques and real-life case studies, we will also be exploring agile methodologies and discuss if microservices are the right choice for your field of work.

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.

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.

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.

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.

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

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.

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.

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