Jonathan Lalou's Blog

Posts Tagged ‘Microservices’

In the world of modern application deployment, particularly in cloud-native and microservice architectures, fast startup time is a crucial factor impacting scalability, resilience, and cost efficiency. Slow-starting applications can delay deployments, hinder auto-scaling responsiveness, and consume resources unnecessarily. Olivier Bourgain, in his presentation, delved into strategies for significantly accelerating the startup time of Java applications, focusing on optimizations at both the Java Virtual Machine (JVM) level and within popular frameworks like Spring Boot. He explored techniques ranging from garbage collection tuning to leveraging emerging technologies like OpenJDK’s Project Leyden and Spring AOT (Ahead-of-Time Compilation) to make Java applications lighter, faster, and more efficient from the moment they start.

The Importance of Fast Startup

Olivier began by explaining why fast startup time matters in modern environments. In microservices architectures, applications are frequently started and stopped as part of scaling events, deployments, or rolling updates. A slow startup adds to the time it takes to scale up to handle increased load, potentially leading to performance degradation or service unavailability. In serverless or function-as-a-service environments, cold starts (the time it takes for an idle instance to become ready) are directly impacted by application startup time, affecting latency and user experience. Faster startup also improves developer productivity by reducing the waiting time during local development and testing cycles. Olivier emphasized that optimizing startup time is no longer just a minor optimization but a fundamental requirement for efficient cloud-native deployments.

JVM and Garbage Collection Optimizations

Optimizing the JVM configuration and understanding garbage collection behavior are foundational steps in improving Java application startup. Olivier discussed how different garbage collectors (like G1, Parallel, or ZGC) can impact startup time and memory usage. Tuning JVM arguments related to heap size, garbage collection pauses, and just-in-time (JIT) compilation tiers can influence how quickly the application becomes responsive. While JIT compilation is crucial for long-term performance, it can introduce startup overhead as the JVM analyzes and optimizes code during initial execution. Techniques like Class Data Sharing (CDS) were mentioned as a way to reduce startup time by sharing pre-processed class metadata between multiple JVM instances. Olivier provided practical tips and configurations for optimizing JVM settings specifically for faster startup, balancing it with overall application performance.

Framework Optimizations: Spring Boot and Beyond

Popular frameworks like Spring Boot, while providing immense productivity benefits, can sometimes contribute to longer startup times due to their extensive features and reliance on reflection and classpath scanning during initialization. Olivier explored strategies within the Spring ecosystem and other frameworks to mitigate this. He highlighted Spring AOT (Ahead-of-Time Compilation) as a transformative technology that analyzes the application at build time and generates optimized code and configuration, reducing the work the JVM needs to do at runtime. This can significantly decrease startup time and memory footprint, making Spring Boot applications more suitable for resource-constrained environments and serverless deployments. Project Leyden in OpenJDK, aiming to enable static images and further AOT compilation for Java, was also discussed as a future direction for improving startup performance at the language level. Olivier demonstrated how applying these framework-specific optimizations and leveraging AOT compilation can have a dramatic impact on the startup speed of Java applications, making them competitive with applications written in languages traditionally known for faster startup.

Links:

• Olivier Bourgain: https://www.linkedin.com/in/olivier-bourgain/
• Mirakl: https://www.mirakl.com/
• Spring Boot: https://spring.io/projects/spring-boot
• OpenJDK Project Leyden: https://openjdk.org/projects/leyden/
• Devoxx France LinkedIn: https://www.linkedin.com/company/devoxx-france/
• Devoxx France Bluesky: https://bsky.app/profile/devoxx.fr
• Devoxx France Website: https://www.devoxx.fr/

George Gkogkolis from Travelite Group shared a 15-minute case study at Devoxx Greece 2025 on re-platforming to process 1 million emails per hour.

The Challenge

Travelite Group, a global OTA handling flight tickets in 75 countries, processes 350,000 emails daily, expected to hit 2 million. Previously, a SaaS ticketing system struggled with growing traffic, poor licensing, and subpar user experience. Sharding the system led to complex agent logins and multiplexing issues with the booking engine. Market research revealed no viable alternatives, as vendors’ licensing models couldn’t handle the scale, prompting an in-house solution.

The New Platform

The team built a cloud-native, microservices-based platform within a year, going live in December 2024. It features a receiving app, a React-based web UI with Mantine Dev, a Spring Boot backend, and Amazon DocumentDB, integrated with Amazon SES and S3. Emails land in a Postfix server, are stored in S3, and processed via EventBridge and SQS. Data migration was critical, moving terabytes of EML files and databases in under two months, achieving a peak throughput of 1 million emails per hour by scaling to 50 receiver instances.

Lessons Learned

Starting with migration would have eased performance optimization, as synthetic data didn’t match production scale. Cloud-native deployment simplified scaling, and a backward-compatible API eased integration. Open standards (EML, Open API) ensured reliability. Future plans include AI and LLM enhancements by 2025, automating domain allocation for scalability.

Links

• Travelite Group
• Devoxx Greece

At Devoxx Greece 2025, Laila Bougria, representing Particular Software, delivered an insightful presentation on the nuances of orchestration and choreography in microservice architectures. Leveraging her extensive banking industry experience, Laila provided a practical framework to navigate the trade-offs of these coordination strategies, using real-world scenarios to guide developers toward informed system design choices.

The Essence of Microservice Interactions

Laila opened with a relatable story about navigating the mortgage process, underscoring the complexity of interservice communication in microservices. She explained that while individual services are streamlined, the real challenge lies in orchestrating their interactions to deliver business value. Orchestration employs a centralized component to direct workflows, maintaining state and issuing commands, much like a conductor guiding a symphony. Choreography, by contrast, embraces an event-driven model where services operate autonomously, reacting to events with distributed state management. Through a loan broker example, Laila illustrated how orchestration simplifies processes like credit checks and offer ranking by centralizing control, yet risks creating dependencies that can halt workflows if services fail. Choreography, facilitated by an event bus, enhances autonomy but complicates tracking the overall process, potentially obscuring system behavior.

Navigating Coupling and Resilience

Delving into the mechanics, Laila highlighted the distinct coupling profiles of each approach. Orchestration often leads to efferent coupling, with the central component relying on multiple downstream services, necessitating resilience mechanisms like retries or circuit breakers to mitigate failures. For instance, if a credit scoring service is unavailable, the orchestrator must handle retries or fallback strategies. Choreography, however, increases afferent coupling through event subscriptions, which can introduce bidirectional dependencies when addressing business failures, such as reversing a loan if a property deal collapses. Laila stressed the importance of understanding coupling types—temporal, contract, and control—to make strategic decisions. Asynchronous communication in orchestration reduces temporal coupling, while choreography’s event-driven nature supports scalability but challenges visibility, as seen in her banking workflow example where emergent behavior obscured process clarity.

Addressing Business Failures and Workflow Evolution

Laila emphasized the critical role of managing business failures, or compensating flows, where actions must be undone due to unforeseen events, like a failed property transaction requiring the reversal of interest provisions or direct debits. Orchestration excels here, leveraging existing service connections to streamline reversals. In contrast, choreography demands additional event subscriptions, risking complex bidirectional coupling, as demonstrated when adding a background check to a loan process introduced order dependencies. Laila introduced the concept of “passive-aggressive publishers,” where services implicitly rely on others to act on events, akin to expecting a partner to address a chaotic kitchen without direct communication. She advocated for explicit command-driven interactions to clarify dependencies, ensuring system robustness. Additionally, Laila addressed workflow evolution, noting that orchestration simplifies modifications by centralizing changes, while choreography requires careful management to avoid disrupting event-driven flows.

A Strategic Decision Framework

Concluding her talk, Laila offered a decision-making framework anchored in five questions: the nature of communication (synchronous or asynchronous), the complexity of prerequisites, the extent of compensating flows, the likelihood of domain changes, and the need for centralized responsibility. Orchestration suits critical workflows with frequent changes or complex dependencies, such as banking processes requiring clear state visibility. Choreography is ideal for stable domains with minimal prerequisites, like retail order systems. By segmenting workflows into sub-processes, developers can apply the appropriate pattern strategically, blending both approaches for optimal outcomes. Laila’s banking-inspired insights provide a practical guide for architects to craft systems that balance control, flexibility, and maintainability.

Links:

• Particular Software company website

In the torrent of event-driven ecosystems, where streams supplant silos and resilience reigns, Ian Cooper, a polyglot architect and Brighter’s steward, demystifies Kafka for .NET artisans. As London’s #ldnug founder and a messaging maven, Ian unravels Kafka’s enigma—records, offsets, SerDes, schemas—from novice nods to nuanced integrations. His hour, a whirlwind of wisdom and wireframes, equips ensembles to embed Kafka as backbone, blending brokers with .NET’s breadth for robust, reactive realms.

Ian immerses immediately: Kafka, a distributed commit log, chronicles changes for consumption, contrasting queues’ ephemera. Born from LinkedIn’s logging ledger in 2011, it scaled to streams, spawning Connect for conduits and Flink for flows. Ian’s inflection: Kafka as nervous system, not notification nook—durable, disorderly, decentralized.

Unpacking the Pipeline: Kafka’s Primal Primitives

Kafka’s corpus: topics as ledgers, partitioned for parallelism, replicated for redundancy. Producers pen records—key-value payloads with headers—SerDes serializing strings or structs. Consumers cull via offsets, groups coordinating coordination, enabling elastic elasticity.

Ian illuminates inroads: Confluent’s Cloud for coddling, self-hosted for sovereignty. .NET’s ingress: Confluent.Kafka NuGet, crafting IProducer for publishes, IConsumer for pulls. His handler: await producer.ProduceAsync(topic, new Message {Key = key, Value = serialized}).

Schemas safeguard: registries register Avro or Protobuf, embedding IDs for evolution. Ian’s caveat: magic bytes mandate manual marshaling in .NET, yet compatibility curtails chaos.

Forging Flows: From Fundamentals to Flink Frontiers

Fundamentals flourish: idempotent producers preclude duplicates, transactions tether topics. Ian’s .NET nuance: transactions via BeginTransaction, committing confluences. Exactly-once semantics, once Java’s jewel, beckon .NET via Kafka Streams’ kin.

Connect catalyzes: sink sources to SQL, sources streams from files—redpanda’s kin for Kafka-less kinship. Flink forges further: stream processors paralleling data dances, yet .NET’s niche narrows to basics.

Ian’s interlude: brighter bridges, abstracting brokers for seamless swaps—Rabbit to Kafka—sans syntactic shifts.

Safeguarding Streams: Resilience and Realms

Resilience roots in replicas: in-sync sets (ISR) insure idempotence, unclean leader elections avert anarchy. Ian’s imperative: tune retention—time or tally—for traceability, not torrent.

His horizon: Kafka as canvas for CQRS, where commands commit, queries query—event sourcing’s engine.

Links:

• BrighterCommand GitHub
• Ian Cooper on LinkedIn
• Ian Cooper on GitHub

In a world where systems are becoming increasingly distributed and cloud-native, microservices have emerged as the de facto architecture. But as we scale
microservices horizontally—running multiple instances for each service—one of the biggest challenges becomes inter-service communication.

How do we ensure that our services talk to each other reliably, efficiently, and in a way that’s resilient to failures?

Welcome to the world of Feign and Spring Cloud.

The Challenge: Multi-Instance Microservices

Imagine you have a user-service that needs to talk to an order-service, and your order-service runs 5 instances behind a
service registry like Eureka. Hardcoding URLs? That’s brittle. Manual load balancing? Not scalable.

You need:

• Service discovery to dynamically resolve where to send the request
• Load balancing across instances
• Resilience for timeouts, retries, and fallbacks
• Clean, maintainable code that developers love

The Solution: Feign + Spring Cloud

OpenFeign is a declarative web client. Think of it as a smart HTTP client where you only define interfaces — no more boilerplate REST calls.

When combined with Spring Cloud, Feign becomes a first-class citizen in a dynamic, scalable microservices ecosystem.

✅ Features at a Glance:

• Declarative REST client
• Automatic service discovery (Eureka, Consul)
• Client-side load balancing (Spring Cloud LoadBalancer)
• Integration with Resilience4j for circuit breaking
• Easy integration with Spring Boot config and observability tools

Step-by-Step Setup

1. Add Dependencies

If using Eureka:

       config:

           default:

                connectTimeout:3000

                readTimeout:500

[/yml]

Enable retry:

What Happens Behind the Scenes?

When user-service calls order-service:

1. Spring Cloud uses Eureka to resolve all instances of order-service.
2. Spring Cloud LoadBalancer picks an instance using round-robin (or your chosen strategy).
3. Feign sends the HTTP request to that instance.
4. If it fails, Resilience4j (or your fallback) handles it gracefully.

Observability & Debugging

Use Spring Boot Actuator to expose Feign metrics:

And tools like Spring Cloud Sleuth + Zipkin for distributed tracing across Feign calls.

Beyond the Basics

To go even further:

• Integrate with Spring Cloud Gateway for API routing and external access.
• Use Spring Cloud Config Server to centralize configuration across environments.
• Secure Feign calls with OAuth2 via Spring Security and OpenID Connect.

✨ Final Thoughts

Using Feign with Spring Cloud transforms service-to-service communication from a tedious, error-prone task into a clean, scalable, and cloud-native solution.
Whether you’re scaling services across zones or deploying in Kubernetes, Feign ensures your services communicate intelligently and resiliently.

Lecturer: Tamar Twena-Stern

Tamar Twena-Stern is an experienced software professional, serving as a developer, manager, and architect with a decade of expertise spanning server-side development, big data, mobile, web technologies, and security. She possesses a deep specialization in Node.js server architecture and performance optimization. Her work is centered on practical strategies for improving Node.js REST API performance, encompassing areas from database interaction and caching to efficient framework and library selection.

Relevant Links:
* GitNation Profile (Talks): https://gitnation.com/person/tamar_twenastern
* Lecture Video: Implementing a performant URL parser from scratch

Abstract

This article systematically outlines and analyzes key strategies for optimizing the performance of Node.js-based REST API microservices, a requirement necessitated by the high concurrency demands of modern, scalable web services. The analysis is segmented into three primary areas: I/O optimization (database access and request parallelism), data locality and caching, and strategic library and framework selection. Key methodologies, including the use of connection pooling, distributed caching with technologies like Redis, and the selection of low-overhead utilities (e.g., Fastify and Pino), are presented as essential mechanisms for minimizing latency and maximizing API throughput.

Performance Engineering in Node.js API Architecture

I/O Optimization: Database and Concurrency

The performance of a Node.js API is heavily constrained by Input/Output (I/O) operations, particularly those involving database queries or external network requests. Optimizing this layer is paramount for achieving speed at scale:

1. Database Connection Pooling: At high transaction volumes, the overhead of opening and closing a new database connection for every incoming request becomes a critical bottleneck. The established pattern of connection pooling is mandatory, as it enables the reuse of existing, idle connections, significantly reducing connection establishment latency.
2. Native Drivers vs. ORMs: For applications operating at large scale, performance gains can be realized by preferring native database drivers over traditional Object-Relational Mappers (ORMs). While ORMs offer abstraction and development convenience, they introduce an layer of overhead that can be detrimental to raw request throughput.
3. Parallel Execution: Latency within a single request often results from sequential execution of independent I/O tasks (e.g., multiple database queries or external service calls). The implementation of Promise.all allows for the parallel execution of these tasks, ensuring that the overall response time is determined by the slowest task, rather than the sum of all tasks.
4. Query Efficiency: Fundamental to performance is ensuring an efficient database architecture and optimizing all underlying database queries.

Data Locality and Caching Strategies

Caching is an essential architectural pattern for reducing I/O load and decreasing request latency for frequently accessed or computationally expensive data.

• Distributed Caching: In-memory caching is strongly discouraged for services deployed in multiple replicas or instances, as it leads to data inconsistency and scalability issues. The professional standard is distributed caching, utilizing technologies such as Redis or etcd. A distributed cache ensures all service instances access a unified, shared source of cached data.
• Cache Candidates: Data recommended for caching includes results of complex DB queries, computationally intensive cryptographic operations (e.g., JWT parsing), and external HTTP requests.

Strategic Selection of Runtime Libraries

The choice of third-party libraries and frameworks has a profound impact on the efficiency of the Node.js event loop.

• Web Framework Selection: Choosing a high-performance HTTP framework is a fundamental optimization. Frameworks like Fastify or Hapi offer superior throughput and lower overhead compared to more generalized alternatives like Express.
• Efficient Serialization: Performance profiling reveals that JSON serialization can be a significant bottleneck when handling large payloads. Utilizing high-speed serialization libraries, such as Fast-JSON-Stringify, can replace the slower, default JSON.stringify to drastically improve response times.
• Logging and I/O: Logging is an I/O operation and, if handled inefficiently, can impede the main thread. The selection of a high-throughput, low-overhead logging utility like Pino is necessary to mitigate this risk.
• Request Parsing Optimization: Computational tasks executed on the main thread, such as parsing components of an incoming request (e.g., JWT token decoding), should be optimized, as they contribute directly to request latency.

Links

• Lecture Video: JS Perf Wins & New Node.js Features with Yagiz Nizipli – Syntax #716
• Lecturer’s GitNation Profile: https://gitnation.com/person/tamar_twenastern

In the sprawling digital expanse of Norway’s welfare agency, NAV, where 143 million lines of code burgeon, Audun Fauchald Strand and Trond Arve Wasskog, principal engineers, confront the Sisyphean challenge of maintenance. Their discourse, a clarion call for strategic reuse, dissects NAV’s labyrinthine codebase, advocating for shared components to curb redundancy. With a nod to domain-driven design and Conway’s Law, Audun and Trond weave a narrative of organizational alignment, technical finesse, and cultural recalibration, urging a shift from ad-hoc replication to deliberate commonality.

NAV, serving Norway’s social safety net, grapples with legacy sprawl. Audun and Trond, seasoned navigators of this terrain, challenge the mantra “reuse should be discovered, not designed.” Their thesis: intentional reuse, underpinned by product thinking, demands ownership, incentives, and architecture harmonized with organizational contours. From open-source libraries to shared services, they map a spectrum of reuse, balancing technical feasibility with social dynamics.

Redefining Reuse: From Code to Culture

Reuse begins with understanding context. Audun outlines NAV’s scale: thousands of developers, hundreds of teams, and a codebase ballooning through modernization. Copy-pasting code—tempting for speed—breeds technical debt. Instead, they champion shared libraries and services, like payment gateways or journaling systems, already reused across NAV’s ecosystem. Open-source, they note, exemplifies external success; internally, however, reuse falters without clear ownership.

Trond delves into Conway’s Law: systems mirror organizational structures. NAV’s fragmented teams spawn siloed solutions unless guided by unified governance. Their solution: designate component owners, aligning incentives to prioritize maintenance over novelty. A payment service, reused across domains, exemplifies success, reducing duplication while enhancing reliability.

Technical Tactics and Organizational Orchestration

Technically, reuse demands robust infrastructure. Audun advocates platforms—centralized APIs, standardized pipelines—to streamline integration. Shared libraries, versioned meticulously, prevent divergence, while microservices enable modular reuse. Yet, technical prowess alone suffices not; social engineering is paramount. Trond emphasizes cross-team collaboration, ensuring components like letter-sending services are maintained by dedicated squads, not orphaned.

Their lesson: reuse is a socio-technical dance. Without organizational buy-in—financing, accountability, clear roles—components decay. NAV’s pivot to product-oriented teams, guided by domain-driven design, fosters reusable assets, aligning technical solutions with business imperatives.

Navigating Pitfalls: Ownership and Maintenance

The core challenge lies in the “blue box”—NAV’s monolithic systems. Audun and Trond dissect failures: reused components falter when unowned, leading to outages or obsolescence. Their antidote: explicit ownership models, where teams steward components, supported by funding and metrics. They cite successes—journaling services, payment APIs—where ownership ensures longevity.

Their vision: an internal open-source ethos, where teams contribute to and consume shared assets, mirrored by external triumphs like Kubernetes. By realigning incentives, NAV aims to transform reuse from serendipity to strategy, reducing code bloat while accelerating delivery.

Fostering a Reuse-First Mindset

Audun and Trond conclude with a cultural clarion: reuse thrives on intentionality. Teams must evaluate trade-offs—forking versus libraries, services versus platforms—within their context. Their call to action: join NAV’s mission, where reuse reshapes welfare delivery, blending technical rigor with societal impact.

Links:

• NAV company website
• Audun Fauchald Strand on LinkedIn
• Trond Arve Wasskog on LinkedIn

In an engaging session at Devoxx Belgium 2023, Per Minborg, a Java Core Library team member at Oracle and an OpenJDK contributor, guided attendees through the intricacies of the Foreign Function and Memory (FFM) API, a pivotal component of Project Panama. With a blend of theoretical insights and live coding, Per demonstrated how this API, in its third preview in Java 21, enables seamless interaction with native memory and functions using pure Java code. His talk, dubbed the “Panama Dojo,” showcased the API’s potential to enhance performance and safety, culminating in a hands-on demo of a lightweight microservice framework built with memory segments, arenas, and memory layouts.

Unveiling the FFM API’s Capabilities

Per introduced the FFM API as a solution to the limitations of Java Native Interface (JNI) and direct buffers. Unlike JNI, which requires cumbersome C stubs and inefficient data passing, the FFM API allows direct native memory access and function calls. Per illustrated this with a Point struct example, where a memory segment models a contiguous memory region with 64-bit addressing, supporting both heap and native segments. This eliminates the 2GB limit of direct buffers, offering greater flexibility and efficiency.

The API introduces memory segments with constraints like size, lifetime, and thread confinement, preventing out-of-bounds access and use-after-free errors. Per highlighted the importance of deterministic deallocation, contrasting Java’s automatic memory management with C’s manual approach. The FFM API’s arenas, such as confined and shared arenas, manage segment lifecycles, ensuring resources are freed explicitly, as demonstrated in a try-with-resources block that deterministically deallocates a segment.

Structuring Memory with Layouts and Arenas

Memory layouts, a key FFM API feature, provide a declarative way to define memory structures, reducing manual offset computations. Per showed how a Point layout with x and y doubles uses var handles to access fields safely, leveraging JIT optimizations for atomic operations. This approach minimizes bugs in complex structs, as var handles inherently account for offsets, unlike manual calculations.

Arenas further enhance safety by grouping segments with shared lifetimes. Per demonstrated a confined arena, restricting access to a single thread, and a shared arena, allowing multi-threaded access with thread-local handshakes for safe closure. These constructs bridge the gap between C’s flexibility and Rust’s safety, offering a balanced model for Java developers. In his live demo, Per used an arena to allocate a MarketInfo segment, showcasing deterministic deallocation and thread safety.

Building a Persistent Queue with Memory Mapping

The heart of Per’s session was a live coding demo constructing a persistent queue using memory mapping and atomic operations. He defined a MarketInfo record for stock exchange data, including timestamp, symbol, and price fields. Using a record mapper, Per serialized and deserialized records to and from memory segments, demonstrating immutability and thread safety. The mapper, a potential future JDK feature, simplifies data transfer between Java objects and native memory.

Per then implemented a memory-mapped queue, where a file-backed segment stores headers and payloads. Headers use atomic operations to manage mutual exclusion across threads and JVMs, ensuring safe concurrent access. In the demo, a producer appended MarketInfo records to the queue, while two consumers read them asynchronously, showcasing low-latency, high-performance data sharing. Per’s use of sparse files allowed a 1MB queue to scale virtually, highlighting the API’s efficiency.

Crafting a Microservice Framework

The session culminated in assembling these components into a microservice framework. Per’s queue, inspired by Chronicle Queue, supports persistent, high-performance data exchange across JVMs. The framework leverages memory mapping for durability, atomic operations for concurrency, and record mappers for clean data modeling. Per demonstrated its practical application by persisting a queue to a file and reading it in a separate JVM, underscoring its robustness for distributed systems.

He emphasized the reusability of these patterns across domains like machine learning and graphics processing, where native libraries are prevalent. Tools like jextract, briefly mentioned, further unlock native libraries like TensorFlow, enabling Java developers to integrate them effortlessly. Per’s framework, though minimal, illustrates how the FFM API can transform Java’s interaction with native code, offering a safer, faster alternative to JNI.

Performance and Safety in Harmony

Throughout, Per stressed the FFM API’s dual focus on performance and safety. Native function calls, faster than JNI, and memory segments with strict constraints outperform direct buffers while preventing common errors. The API’s integration with existing JDK features, like var handles, ensures compatibility and optimization. Per’s live coding, despite its complexity, flowed seamlessly, reinforcing the API’s practicality for real-world applications.

Conclusion: Embracing the Panama Dojo

Per’s session was a masterclass in leveraging the FFM API to push Java’s boundaries. By combining memory segments, layouts, arenas, and atomic operations, he crafted a framework that exemplifies the API’s potential. His call to action—experiment with the FFM API in Java 21—invites developers to explore this transformative tool, promising enhanced performance and safety for native interactions. The Panama Dojo left attendees inspired to break new ground in Java development.

Links:

• Oracle Java
• Per Minborg’s GitHub
• Per Minborg’s Blog

At Devoxx Poland 2022, Viktor Gamov, a dynamic developer advocate at Kong, delivered an engaging presentation on zero trust security and its integration with service mesh technologies. With a blend of humor and technical depth, Viktor demystified the complexities of securing modern microservice architectures, emphasizing a philosophy that eliminates implicit trust to bolster system resilience. His talk, rich with practical demonstrations, offered developers and architects actionable insights into implementing zero trust principles using tools like Kong’s Kuma service mesh, making a traditionally daunting topic accessible and compelling.

The Philosophy of Zero Trust

Viktor begins by challenging the conventional notion of trust, using the poignant analogy of The Lion King to illustrate its exploitable nature. Trust, he argues, is a vulnerability when relied upon for system access, as it can be manipulated by malicious actors. Zero trust, conversely, operates on the premise that no entity—human or service—should be inherently trusted. This philosophy, not a product or framework, redefines security by requiring continuous verification of identity and access. Viktor outlines four pillars critical to zero trust in microservices: identity, automation, default denial, and observability. These principles guide the secure communication between services, ensuring robust protection in distributed environments.

Identity in Microservices

In the realm of microservices, identity is paramount. Viktor likens service identification to a passport, issued by a trusted authority, which verifies legitimacy without relying on trust. Traditional security models, akin to fortified castles with IP-based firewalls, are inadequate in dynamic cloud environments where services span multiple platforms. He introduces the concept of embedding identity within cryptographic certificates, specifically using the Subject Alternative Name (SAN) in TLS to encode service identities. This approach, facilitated by service meshes like Kuma, allows for encrypted communication and automatic identity validation, reducing the burden on individual services and enhancing security across heterogeneous systems.

Automation and Service Mesh

Automation is a cornerstone of effective zero trust implementation, particularly in managing the complexity of certificate generation and rotation. Viktor demonstrates how Kuma, a CNCF sandbox project built on Envoy, automates these tasks through its control plane. By acting as a certificate authority, Kuma provisions and rotates certificates seamlessly, ensuring encrypted mutual TLS (mTLS) communication between services. This automation alleviates manual overhead, enabling developers to focus on application logic rather than security configurations. During a live demo, Viktor showcases how Kuma integrates a gateway into the mesh, enabling mTLS from browser to service, highlighting the ease of securing traffic in real-time.

Deny by Default and Observability

The principle of denying all access by default is central to zero trust, ensuring that only explicitly authorized communications occur. Viktor illustrates how Kuma’s traffic permissions allow precise control over service interactions, preventing unauthorized access. For instance, a user service can be restricted to only communicate with an invoice service, eliminating wildcard permissions that expose vulnerabilities. Additionally, observability is critical for detecting and responding to threats. By integrating with tools like Prometheus, Loki, and Grafana, Kuma provides real-time metrics, logs, and traces, enabling developers to monitor service interactions and maintain an up-to-date system overview. Viktor’s demo of a microservices application underscores how observability enhances security and operational efficiency.

Practical Implementation with Kuma

Viktor’s hands-on approach culminates in a demonstration of deploying a containerized application within a Kuma mesh. By injecting sidecar proxies, Kuma ensures encrypted communication and centralized policy management without altering application code. He highlights advanced use cases, such as leveraging Open Policy Agent (OPA) to enforce fine-grained access controls, like restricting a service to read-only HTTP GET requests. This infrastructure-level security decouples policy enforcement from application logic, offering flexibility and scalability. Viktor’s emphasis on developer-friendly tools and real-time feedback loops empowers teams to adopt zero trust practices with minimal friction, fostering a culture of security-first development.

Links:

• Kong company website
• Kuma project website

Hashtags: #ZeroTrust #ServiceMesh #Microservices #Security #Kuma #Kong #DevoxxPoland #ViktorGamov

As Node.js architectures swell in complexity, particularly within microservices paradigms, maintaining visibility into system dynamics becomes paramount. Chinmay Gaikwad addresses this imperative, advocating distributed tracing as a cornerstone for holistic observability. His discourse illuminates the hurdles of scaling real-time applications and positions tracing tools as enablers of confident expansion.

Microservices, while promoting modularity, often obscure transaction flows across disparate services, complicating root-cause analysis. Chinmay articulates common pitfalls: elusive errors in nested calls, latency spikes from inter-service dependencies, and the opacity of containerized deployments. Without granular insights, teams grapple with “unknown unknowns,” where failures cascade undetected, eroding reliability and user trust.

Tackling Visualization Challenges in Distributed Environments

Effective observability demands mapping service interactions alongside performance metrics, a task distributed tracing excels at. By propagating context—such as trace IDs—across requests, tools like Jaeger or Zipkin reconstruct end-to-end journeys, highlighting bottlenecks from ingress to egress. Chinmay emphasizes Node.js-specific integrations, where middleware instruments HTTP, gRPC, or database queries, capturing spans that aggregate into flame graphs for intuitive bottleneck identification.

In practice, this manifests as dashboards revealing service health: error rates, throughput variances, and latency histograms. For Node.js, libraries like OpenTelemetry provide vendor-agnostic instrumentation, embedding traces in event loops without substantial overhead. Chinmay’s examples underscore exporting traces to backends for querying, enabling alerts on anomalies like sudden p99 latency surges, thus preempting outages.

Forging Sustainable Strategies for Resilient Systems

Beyond detection, Chinmay advocates embedding tracing in CI/CD pipelines, ensuring observability evolves with code. This proactive stance—coupled with service meshes for automated propagation—cultivates a feedback loop, where insights inform architectural refinements. Ultimately, distributed tracing transcends monitoring, empowering Node.js developers to architect fault-tolerant, scalable realms where complexity yields to clarity.

Links:

• Chinmay Gaikwad on LinkedIn
• OpenTelemetry for Node.js