InfoQ Homepage Microservices Content on InfoQ
-
/articles/cellery-code-first-kubernetes/en/smallimage/cellery-code-first-kubernetes-l-1566554395052.jpg)
Cellery: A Code-First Approach to Deploy Applications on Kubernetes
Cellery is a code-first approach to building, integrating, running, and managing composite applications on Kubernetes, using a cell-based architecture. Learn what cells are, how Cellery works, and see how an existing Kubernetes application written by Google can be deployed, managed, and observed using Cellery.
-
/articles/engineers-guide-to-sleep/en/smallimage/logo-1565941207544.jpg)
An Engineer’s Guide to a Good Night’s Sleep
Increased microservices adoption, fueled by the move to the cloud where architectures and infrastructure can flex and be ephemeral, adds complexity every day to the systems we create and maintain. This takes place alongside operating models with autonomous and totally empowered teams, so each distributed system has its own tapestry of technical approaches, languages, and services.
-
/articles/twelve-testing-techniques-microservices-intro/en/smallimage/twelve-testing-techniques-microservices-intro-s-1565852740949.jpeg)
Testing Microservices: an Overview of 12 Useful Techniques - Part 1
When building a microservice system, you will need to manage inter-dependent components in order to test in a cost and time effective way. You can use test doubles in your microservice tests that pretend to be real dependencies for the purpose of the test. However, there are many options for implementing this. This article provides an overview and tradeoffs of 12 techniques.
-
/articles/kubernetes-workloads-serverless-era/en/smallimage/logo-1564662062598.jpg)
Kubernetes Workloads in the Serverless Era: Architecture, Platforms, and Trends
Explore how microservices architecture has evolved into cloud-native architecture, where many of the infrastructure concerns are provided by Kubernetes in combination with additional abstractions provided by service mesh and serverless frameworks. In addition, the serverless ecosystem is evolving by exploring standard and open packaging, runtimes, and event formats.
-
/articles/java-jvm-trends-2019/en/smallimage/InfoQ-Trend-Report-Java2019-s-1563268318310.jpg)
Java InfoQ Trends Report - July 2019
The InfoQ Java trend report provides an overview of technology adoption and commentary on how we see the Java and JVM-related space evolving in 2019. Key developments include the release of Java 13, the rise of non-HotSpot JVMs and the evolution of GraalVM, and the changing landscape of Java microservice frameworks.
-
/articles/evolve-devops-devsecops/en/smallimage/How-to-Seamlessly-Evolve-DevOps-into-DevSecOps-logo-small-1561367768393.jpg)
How to Seamlessly Evolve DevOps into DevSecOps
As DevOps evolved, it became obvious that it was about more than just software development and operations management. With each new story of a massive data breach and its catastrophic consequences, cybersecurity swiftly became recognized as a critical part of any IT ecosystem. This realization led to DevSecOps. This article looks at how to embrace a DevSecOps approach.
-
/articles/obscuring-complexity/en/smallimage/obscuring-complexity-s-1560786483000.jpeg)
Obscuring Complexity
One of the most important things that software architects do is manage the complexity of their systems in order to mitigate release disruption while maintaining sufficient feature velocity. When we cannot reduce complexity, we try to hide or shift it. Software architects tend to manage that complexity with the time-honored strategies covered in this article.
-
/articles/service-mesh-api-federating/en/smallimage/service-mesh-api-federating-s-1558080393545.jpeg)
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.
-
/articles/application-integration-service-mesh/en/smallimage/role-application-integration-cloud-native-microservices-landscape-logo-small-1557478517420.jpg)
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.
-
/articles/service-mesh-event-driven-messaging/en/smallimage/using-service-mesh-for-event-driven-messaging-logo-small-1557145841741.jpg)
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.
-
/articles/api-gateway-service-mesh-app-modernisation/en/smallimage/api-gateway-service-mesh-app-modernisation-s-1556793369643.jpeg)
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.
-
/articles/kubernetes-multicluster-comms/en/smallimage/kubernetes-multicluster-comms-s-1555590645353.jpeg)
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.