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

At Spring I/O 2024 in Barcelona, Jatin Makhija, an engineering leader at Deutsche Telekom Digital Labs, delivered an insightful presentation on leveraging Spring Boot Admin to enhance application monitoring and management. With a rich background in startups like Exigo and VWO, Jatin shared practical use cases and live demonstrations, illustrating how Spring Boot Admin empowers developers to streamline operations in complex, distributed systems. This talk, filled with actionable insights, highlighted the tool’s versatility in addressing real-world challenges, from log management to feature flag automation.

Empowering Log Management

Jatin began by addressing a universal pain point for developers: debugging production issues. He emphasized the critical role of logs in resolving incidents, noting that Spring Boot Admin allows engineers to dynamically adjust log levels—from info to trace—in seconds without redeploying applications. Through a live demo, Jatin showcased how to filter logs at the class level, enabling precise debugging. However, he cautioned about the costs of excessive logging, both in infrastructure and compliance with GDPR. By masking personally identifiable information (PII) and reverting log levels promptly, teams can maintain security and efficiency. This capability ensures rapid issue resolution while keeping customers satisfied, as Jatin illustrated with real-time log adjustments.

Streamlining Feature Flags

Feature flags are indispensable in modern applications, particularly in multi-tenant environments. Jatin explored how Spring Boot Admin simplifies their management, allowing teams to toggle features without redeploying. He presented two compelling use cases: a legacy discount system and a mobile exchange program. In the latter, Jatin demonstrated dynamically switching locales (e.g., from German to English) to adapt third-party integrations, ensuring seamless user experiences across regions. By refreshing application contexts on the fly, Spring Boot Admin reduces downtime and enhances testing coverage. Jatin’s approach empowers product owners to experiment confidently, minimizing technical debt and ensuring robust feature validation.

Automating Operations

Automation is a cornerstone of efficient development, and Jatin showcased how Spring Boot Admin’s REST APIs can be harnessed to automate testing workflows. By integrating with CI/CD pipelines like Jenkins and test frameworks such as Selenium, teams can dynamically patch configurations and validate multi-tenant setups. A recorded demo illustrated an automated test toggling a mobile exchange feature, highlighting increased test coverage and early defect detection. Jatin emphasized that this automation reduces manual effort, boosts regression testing accuracy, and enables scalable deployments, allowing teams to ship with confidence.

Scaling Monitoring and Diagnostics

Monitoring distributed systems is complex, but Spring Boot Admin simplifies it with built-in metrics and diagnostics. Jatin demonstrated accessing health statuses, thread dumps, and heap dumps through the tool’s intuitive interface. He shared a story of debugging a Kubernetes pod misconfiguration, where Spring Boot Admin revealed discrepancies in CPU allocation, preventing application instability. By integrating the Git Commit Plugin, teams can track deployment details like commit IDs and timestamps, enhancing traceability in microservices. Jatin also addressed scalability, showcasing a deployment managing 374 instances across 24 applications, proving Spring Boot Admin’s robustness in large-scale environments.

Links:

• Deutsche Telekom Digital Labs on LinkedIn

In a dynamic session at Spring I/O 2024 in Barcelona, Dan Erez, lead architect at ZIM, a global shipping company, championed Spring Cloud Gateway as a versatile and powerful API gateway solution. Drawing on his extensive experience with Java and Spring, Dan demonstrated how Spring Cloud Gateway addresses the complexities of microservices architectures, offering features like dynamic routing, rate limiting, and circuit breakers. His talk underscored the gateway’s customizability and integration with Spring, making it an ideal choice for organizations seeking to streamline API management.

The Role of API Gateways in Microservices

API gateways simplify microservices architectures by acting as a unified entry point, hiding the complexity of multiple services. Dan traced the evolution from monolithic applications to microservices, noting that while microservices enhance modularity, they introduce challenges like service discovery and load balancing. An API gateway mitigates these by routing requests, authenticating users, and managing traffic. Spring Cloud Gateway excels in these areas, supporting functionalities like caching, rate limiting, and authentication with JWT tokens. Dan highlighted its ability to integrate with service discovery tools like Eureka, ensuring seamless communication across services.

Configuring and Customizing Routes

Spring Cloud Gateway’s flexibility shines in its routing capabilities. Dan showcased two configuration approaches: declarative YAML files and code-based Java configurations. Routes can be defined based on predicates like paths, headers, or query parameters, allowing fine-grained control. For example, a route for “/orders” can direct to an internal service, while “/invoices” targets a third-party API. Dan demonstrated a simple route adding a request header, executed via WebFlux for high concurrency. This customizability, paired with Spring’s familiarity, empowers developers to tailor the gateway to specific needs without relying on external DevOps teams.

Enhancing Resilience with Circuit Breakers and Caching

Resilience is critical in distributed systems, and Spring Cloud Gateway offers robust tools to handle failures. Dan illustrated circuit breakers, which redirect requests to fallback endpoints when a service is unavailable, preventing timeouts. In a demo, a delayed service triggered a fallback response, showcasing how developers can return cached data or custom errors. Caching, implemented with libraries like Caffeine, reduces database load by storing frequent responses. Dan’s example showed a cached HTTP response remaining consistent across refreshes, highlighting performance gains. These features ensure reliable and efficient API interactions.

Dynamic Rate Limiting and Cost Savings

Dan emphasized Spring Cloud Gateway’s ability to implement dynamic rate limiting, a feature that adapts to server load. In his demo, a custom filter adjusted the maximum request size based on simulated load, allowing larger requests during low traffic and restricting them during peaks. This approach maintains service availability without costly infrastructure scaling. Dan also shared a real-world use case at ZIM, where Spring Cloud Gateway enabled developers to run local services within a shared environment, routing requests dynamically to avoid conflicts. This solution saved significant costs by reducing the need for individual cloud environments.

Links:

• Slides on Spring I/O Website
• Spring Cloud Gateway Documentation

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