The Future of Services: Building Asynchronous, Resilient and Elastic Systems

In this talk by David Ogren, Enterprise Architect at Lightbend, we draw from experiences helping our clients successfully create, migrate to, and manage cloud-native system architectures. We look at some of the common pitfalls and anti-patterns of modernization efforts, and some of the best practices for taking an incremental approach to transforming legacy systems. See the full post with video on the Lightbend blog: https://www.lightbend.com/blog/microservices-kubernetes-application-modernization

Tony Parker, Head of EMEA Sales, Mesosphere, Inc. presents "Journey to the Modern App with Containers, Microservices and Big Data"

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

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.

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.

This document discusses using the actor model with domain-driven design for reactive systems. It provides an overview of the actor model and how it relates to DDD. Key points include: - The actor model uses message passing between independent units called actors to build distributed, concurrent systems. - The actor model is well-suited for building reactive systems to handle high volumes of asynchronous data and messages. - DDD focuses on modeling the core domain and business logic, while actors and messaging enable rapid implementation in a clear and understandable way. - Together, the actor model and DDD support building systems that can respond quickly to changing business needs through loose coupling and isolation of concerns.

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 discusses designing microservices architectures. It begins by defining microservices as small, autonomous services that work together. The benefits of microservices include continuous innovation, independent deployments, and fault isolation. Challenges include complexity, testing, and service discovery. Key principles in designing microservices are modeling them around business domains, making each independently deployable, and decentralizing all components. Additional topics covered include service boundaries, communication patterns, data management, and monitoring microservices applications. The document provides examples and recommendations for implementing microservices on Azure.

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.

An update to my talk about concurrency abstractions, including event loops (node.js and Vert.x), CSP (Go, Clojure), Futures, CPS/Dataflow (RxJava) and Actors (Erlang, Akka)

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.

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

This document discusses designing applications for resiliency in cloud environments. It defines resiliency, high availability, and disaster recovery. It describes why resiliency is important given the transient faults that can occur in cloud systems. The document outlines a process for improving resiliency that includes planning, designing, implementing, testing, deploying, monitoring, and responding to failures. It provides examples of resiliency techniques like load balancing, failover/failback, data replication, retries, circuit breakers, and deployment strategies.

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.

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