InfoQ Homepage Microservices Content on InfoQ
-
Towards a Unified, Standard API for Consolidating Service Meshes
Service mesh architectures enable a control and observability loop. At the moment, service mesh implementations vary in regard to API and technology, and this shows no signs of slowing down. Building on top of volatile APIs can be hazardous. Here we suggest to use a simplified, workflow-friendly API to shield organization platform code from specific service-mesh implementation details.
-
Application Integration for Microservices Architectures: A Service Mesh Is Not an ESB
A service mesh is only meant to be used as infrastructure for communication between services, and developers should not be building any business logic inside the service mesh. Other frameworks and libraries can be used to implement cloud native enterprise application integration patterns.
-
The Potential for Using a Service Mesh for Event-Driven Messaging
In this article, we discuss one of the most challenging and unexplored areas in service mesh architecture; supporting event-driven messaging. There are two main architectural patterns that we discuss here: the protocol proxy sidecar, and the HTTP bridge sidecar. Regardless of the pattern that is used, the sidecar can facilitate features such as observability, throttling, tracing etc.
-
API Gateways and Service Meshes: Opening the Door to Application Modernisation
Modernising applications by decoupling them from the underlying infrastructure on which they are running can enable innovation, reduce costs, and improve security. An API Gateway can decouple applications from external consumers, and a service mesh decouples applications from internal consumers.
-
To Multicluster, or Not to Multicluster: Inter-Cluster Communication Using a Service Mesh
Communication within Kubernetes clusters is a solved issue, but communication across clusters requires more design and operational overhead. Before deciding on whether to implement multicluster support, you should understand your communication use case.
-
Linkerd v2: How Lessons from Production Adoption Resulted in a Rewrite of the Service Mesh
Linkerd 2.0 introduced a substantial rewrite of the widely adopted service mesh, using a split between Go and Rust. In this article, we discuss the lessons learned in the "cauldron of production adoption", and how those lessons became the basis of Linkerd 2.x’s philosophy, design, and implementation.
-
Monitoring and Managing Workflows across Collaborating Microservices
This article argues that you need to balance orchestration and choreography in a microservices architecture in order to be able to understand, manage and change the system.
-
DevOps and Cloud InfoQ Trends Report - February 2019
An overview of how the “cloud computing” and DevOps space is evolving in 2019 including updates on Kubernetes, Chaos Engineering, Service meshes and more.
-
Tap Compare Testing with Diferencia and Java Microservices
“Tap compare” is a testing technique that allows you to test the behavior and performance of the new service by comparing its results against the old service. This article provides an example of using a new open source tool, Diferencia, and mirroring production traffic across both old and new services to compare the difference in result.
-
Ambassador: Building a Control Plane for an Envoy-Powered API Gateway on Kubernetes
This article provides an insight into the creation of the Ambassador open source API gateway for Kubernetes, and discusses the technical challenges and lessons learned from building a developer-focused control plane for managing ingress or "edge" traffic within microservice-based applications.
-
Service Catalog and Kubernetes
Cloud-native applications do not just live inside Kubernetes—they also benefit from using the available cloud managed services. Similar to Kubernetes' declarative object configuration model, the Open Service Broker API with the Service Catalog provides a declarative way to describe cross-platform/cross-cloud managed service dependencies.
-
Rewriting an API Gateway Service from Clojure to Golang: AppsFlyer Experience Report
AppsFlyer processes nearly 70+ billion HTTP requests a day, and is built using a microservices architecture style. The entry point to the system that wraps all of the frontend services is a mission-critical (non-micro) service called the API Gateway. This article is an experience reporting of migrating from a Clojure-based gateway to a newly designed Go-based implementation.