Recent Posts
Archives

Posts Tagged ‘Microservices’

PostHeaderIcon [ScalaDaysNewYork2016] Lightbend Lagom: Crafting Microservices with Precision

Microservices have become a cornerstone of modern software architecture, yet their complexity often poses challenges. At Scala Days New York 2016, Mirco Dotta, a software engineer at Lightbend, introduced Lagom, an open-source framework designed to simplify the creation of reactive microservices. Mirco showcased how Lagom, meaning “just right” in Swedish, balances developer productivity with adherence to reactive principles, offering a seamless experience from development to production.

The Philosophy of Lagom

Mirco emphasized that Lagom prioritizes appropriately sized services over the “micro” aspect of microservices. By focusing on clear boundaries and isolation, Lagom ensures services are neither too small nor overly complex, aligning with the Swedish concept of sufficiency. Built on Play Framework and Akka, Lagom is inherently asynchronous and non-blocking, promoting scalability and resilience. Mirco highlighted its opinionated approach, which standardizes service structures to enhance consistency across teams, allowing developers to focus on domain logic rather than infrastructure.

Development Environment Efficiency

Lagom’s development environment, inspired by Play Framework, is a standout feature. Mirco demonstrated this with a sample application called Cheerer, a Twitter-like service. Using a single SBT command, runAll, developers can launch all services, including an embedded Cassandra server, service locator, and gateway, within one JVM. The environment supports hot reloading, automatically recompiling and restarting services upon code changes. This streamlined setup, consistent across different machines, frees developers from managing complex scripts, enhancing productivity and collaboration.

Service and Persistence APIs

Lagom’s service API is defined through a descriptor method, specifying endpoints and metadata for inter-service communication. Mirco showcased a “Hello World” service, illustrating how services expose endpoints that other services can call, facilitated by the service locator. For persistence, Lagom defaults to Cassandra, leveraging its scalability and resilience, but allows flexibility for other data stores. Mirco advocated for event sourcing and CQRS (Command Query Responsibility Segregation), noting their suitability for microservices. These patterns enable immutable event logs and optimized read views, simplifying data management and scalability.

Production-Ready Features

Transitioning to production is seamless with Lagom, as Mirco demonstrated through its integration with SBT Native Packager, supporting formats like Docker images and RPMs. Lightbend Conductor, available for free in development, simplifies orchestration, offering features like rolling upgrades and circuit breakers for fault tolerance. Mirco highlighted ongoing work to support other orchestration tools like Kubernetes, encouraging community contributions to expand Lagom’s ecosystem. Circuit breakers and monitoring capabilities further ensure service reliability in production environments.

Links:

PostHeaderIcon [DevoxxFR2015] Reactive Applications on Raspberry Pi: A Microservices Adventure

Alexandre Delègue and Mathieu Ancelin, both engineers at SERLI, captivated attendees at Devoxx France 2015 with a deep dive into building reactive applications on a Raspberry Pi cluster. Leveraging their expertise in Java, Java EE, and open-source projects, they demonstrated a microservices-based system using Play, Akka, Cassandra, and Elasticsearch, testing the Reactive Manifesto’s promises on constrained hardware.

Embracing the Reactive Manifesto

Alexandre opened by contrasting monolithic enterprise stacks with the modular, scalable approach of the Reactive Manifesto. He introduced their application, built with microservices and event sourcing, designed to be responsive, resilient, and elastic. Running this on Raspberry Pi’s limited resources tested the architecture’s ability to deliver under constraints, proving its adaptability.

This philosophy, Alexandre noted, prioritizes agility and resilience.

Microservices and Event Sourcing

Mathieu detailed the application’s architecture, using Play for the web framework and Akka for actor-based concurrency. Cassandra handled data persistence, while Elasticsearch enabled fast search capabilities. Event sourcing ensured a reliable audit trail, capturing state changes as events. The duo’s live demo showcased these components interacting seamlessly, even on low-powered Raspberry Pi hardware.

This setup, Mathieu emphasized, ensures robust performance.

Challenges of Clustering on Raspberry Pi

The session highlighted configuration pitfalls encountered during clustering. Alexandre shared how initial deployments overwhelmed the Raspberry Pi’s CPU, causing nodes to disconnect and form sub-clusters. Proper configuration, tested pre-production, resolved these issues, ensuring stable heartbeats across the cluster. Their experience underscored the importance of thorough setup validation.

These lessons, Alexandre noted, are critical for constrained environments.

Alternative Reactive Approaches

Mathieu explored other reactive libraries, such as Spring Boot with reactive Java 8 features and async servlets, demonstrating versatility beyond Akka. Their demo included Gatling for load testing, though an outdated plugin caused challenges, since resolved natively. The session concluded with a nod to the fun of building such systems, encouraging experimentation.

This flexibility, Mathieu concluded, broadens reactive development options.

Links:

PostHeaderIcon [DevoxxFR2014] Runtime stage

FROM nginx:alpine
COPY –from=builder /app/dist /usr/share/nginx/html
EXPOSE 80


This pattern reduces final image size from hundreds of megabytes to tens of megabytes. **Layer caching** optimization requires careful instruction ordering:

COPY package.json package-lock.json ./
RUN npm ci
COPY . .


Copying dependency manifests first maximizes cache reuse during development.

## Networking Models and Service Discovery
Docker’s default bridge network isolates containers on a single host. Production environments demand multi-host communication. **Overlay networks** create virtual networks across swarm nodes:

docker network create –driver overlay –attachable prod-net
docker service create –network prod-net –name api myapp:latest


Docker’s built-in DNS enables service discovery by name. For external traffic, **ingress routing meshes** like Traefik or NGINX provide load balancing, TLS termination, and canary deployments.

## Persistent Storage for Stateful Applications
Stateless microservices dominate container use cases, but databases and queues require durable storage. **Docker volumes** offer the most flexible solution:

docker volume create postgres-data
docker run -d \
–name postgres \
-v postgres-data:/var/lib/postgresql/data \
-e POSTGRES_PASSWORD=secret \
postgres:13


For distributed environments, **CSI (Container Storage Interface)** plugins integrate with Ceph, GlusterFS, or cloud-native storage like AWS EBS.

## Orchestration and Automated Operations
Docker Swarm provides native clustering with zero external dependencies:

docker swarm init
docker stack deploy -c docker-compose.yml myapp
“`

For advanced workloads, Kubernetes offers:
Deployments for rolling updates and self-healing.
Horizontal Pod Autoscaling based on CPU/memory or custom metrics.
ConfigMaps and Secrets for configuration management.

Migration paths typically begin with stateless services in Swarm, then progress to Kubernetes for stateful and machine-learning workloads.

Security Hardening and Compliance

Production containers must follow security best practices:
– Run as non-root users: USER appuser in Dockerfile.
– Scan images with Trivy or Clair in CI/CD pipelines.
– Apply seccomp and AppArmor profiles to restrict system calls.
– Use RBAC and Network Policies in Kubernetes to enforce least privilege.

Production Case Studies and Operational Wisdom

Spotify manages thousands of microservices using Helm charts and custom operators. Airbnb leverages Kubernetes for dynamic scaling during peak booking periods. The New York Times uses Docker for CI/CD acceleration, reducing deployment time from hours to minutes.

Common lessons include:
– Monitor with Prometheus and Grafana.
– Centralize logs with ELK or Loki.
– Implement distributed tracing with Jaeger or Zipkin.
– Use chaos engineering to validate resilience.

Strategic Impact on DevOps Culture

Docker fundamentally accelerates the CI/CD pipeline and enables immutable infrastructure. Success requires cultural alignment: developers embrace infrastructure-as-code, operations teams adopt GitOps workflows, and security integrates into every stage. Orchestration platforms bridge the gap between development velocity and operational stability.

Links:

PostHeaderIcon [DevoxxFR2014] Reactive Programming with RxJava: Building Responsive Applications

Lecturer

Ben Christensen works as a software engineer at Netflix. He leads the development of reactive libraries for the JVM. Ben serves as a core contributor to RxJava. He possesses extensive experience in constructing resilient, low-latency systems for streaming platforms. His expertise centers on applying functional reactive programming principles to microservices architectures.

Abstract

This article provides an in-depth exploration of RxJava, Netflix’s implementation of Reactive Extensions for the JVM. It analyzes the Observable pattern as a foundation for composing asynchronous and event-driven programs. The discussion covers essential operators for data transformation and composition, schedulers for concurrency management, and advanced error handling strategies. Through concrete Netflix use cases, the article demonstrates how RxJava enables non-blocking, resilient applications and contrasts this approach with traditional callback-based paradigms.

The Observable Pattern and Push vs. Pull Models

RxJava revolves around the Observable, which functions as a push-based, composable iterator. Unlike the traditional pull-based Iterable, Observables emit items asynchronously to subscribers. This fundamental duality enables uniform treatment of synchronous and asynchronous data sources:

Observable<String> greeting = Observable.just("Hello", "RxJava");
greeting.subscribe(System.out::println);

The Observer interface defines three callbacks: onNext for data emission, onError for exceptions, and onCompleted for stream termination. RxJava enforces strict contracts for backpressure—ensuring producers respect consumer consumption rates—and cancellation through unsubscribe operations.

Operator Composition and Declarative Programming

RxJava provides over 100 operators that transform, filter, and combine Observables in a declarative manner. These operators form a functional composition pipeline:

Observable.range(1, 10)
          .filter(n -> n % 2 == 0)
          .map(n -> n * n)
          .subscribe(square -> System.out.println("Square: " + square));

The flatMap operator proves particularly powerful for concurrent operations, such as parallel API calls:

Observable<User> users = getUserIds();
users.flatMap(userId -> userService.getDetails(userId), 5)
     .subscribe(user -> process(user));

This approach eliminates callback nesting (callback hell) while maintaining readability and composability. Marble diagrams visually represent operator behavior, illustrating timing, concurrency, and error propagation.

Concurrency Control with Schedulers

RxJava decouples computation from threading through Schedulers, which abstract thread pools:

Observable.just(1, 2, 3)
          .subscribeOn(Schedulers.io())
          .observeOn(Schedulers.computation())
          .map(this::cpuIntensiveTask)
          .subscribe(result -> display(result));

Common schedulers include:
Schedulers.io() for I/O-bound operations (network, disk).
Schedulers.computation() for CPU-bound tasks.
Schedulers.newThread() for fire-and-forget operations.

This abstraction enables non-blocking I/O without manual thread management or blocking queues.

Error Handling and Resilience Patterns

RxJava treats errors as first-class citizens in the data stream:

Observable risky = Observable.create(subscriber -> {
    subscriber.onNext(computeRiskyValue());
    subscriber.onError(new RuntimeException("Failed"));
});
risky.onErrorResumeNext(throwable -> Observable.just("Default"))
     .subscribe(value -> System.out.println(value));

Operators like retry, retryWhen, and onErrorReturn implement resilience patterns such as exponential backoff and circuit breakers—critical for microservices in failure-prone networks.

Netflix Production Use Cases

Netflix employs RxJava across its entire stack. The UI layer composes multiple backend API calls for personalized homepages:

Observable<Recommendation> recs = userIdObservable
    .flatMap(this::fetchUserProfile)
    .flatMap(profile -> Observable.zip(
        fetchTopMovies(profile),
        fetchSimilarUsers(profile),
        this::combineRecommendations));

The API gateway uses RxJava for timeout handling, fallbacks, and request collapsing. Backend services leverage it for event processing and data aggregation.

Broader Impact on Software Architecture

RxJava embodies the Reactive Manifesto principles: responsive, resilient, elastic, and message-driven. It eliminates common concurrency bugs like race conditions and deadlocks. For JVM developers, RxJava offers a functional, declarative alternative to imperative threading models, enabling cleaner, more maintainable asynchronous code.

Links:

PostHeaderIcon [DevoxxFR2012] Node.js and JavaScript Everywhere – A Comprehensive Exploration of Full-Stack JavaScript in the Modern Web Ecosystem

Matthew Eernisse is a seasoned web developer whose career spans over fifteen years of building interactive, high-performance applications using JavaScript, Ruby, and Python. As a core engineer at Yammer, Microsoft’s enterprise social networking platform, he has been at the forefront of adopting Node.js for mission-critical services, contributing to a polyglot architecture that leverages the best tools for each job. Author of the influential SitePoint book Build Your Own Ajax Web Applications, Matthew has long championed JavaScript as a first-class language beyond the browser. A drummer, fluent Japanese speaker, and father of three living in San Francisco, he brings a unique blend of technical depth, practical experience, and cultural perspective to his work. His personal blog at fleegix.org remains a valuable archive of JavaScript patterns and web development insights.

This article presents an exhaustively elaborated, deeply extended, and comprehensively restructured expansion of Matthew Eernisse’s 2012 DevoxxFR presentation, Node.js and JavaScript Everywhere, transformed into a definitive treatise on the rise of full-stack JavaScript and its implications for modern software architecture. Delivered at a pivotal moment, just three years after Node.js’s initial release, the talk challenged prevailing myths about server-side JavaScript while offering a grounded, experience-driven assessment of its real-world benefits. Far from being a utopian vision of “write once, run anywhere,” Matthew argued that Node.js’s true power lay in its event-driven, non-blocking I/O model, ecosystem velocity, and developer productivity, advantages that were already reshaping Yammer’s backend services.

This expanded analysis delves into the technical foundations of Node.js, including the V8 engine, libuv, and the event loop, the architectural patterns that emerged at Yammer such as microservices, real-time messaging, and API gateways, and the cultural shifts required to adopt JavaScript on the server. It includes detailed code examples, performance benchmarks, deployment strategies, and lessons learned from production systems handling millions of users.

EDIT
In 2025 landscape, this piece integrates Node.js 20+, Deno, Bun, TypeScript, Server Components, Edge Functions, and WebAssembly, while preserving the original’s pragmatic, hype-free tone. Through rich narratives, system diagrams, and forward-looking speculation, this work serves as both a historical archive and a practical guide for any team evaluating JavaScript as a backend language.

Debunking the Myths of “JavaScript Everywhere”

The phrase JavaScript Everywhere became a marketing slogan that obscured the technology’s true value. Matthew opened his talk by debunking three common myths. First, the idea that developers write the same code on client and server is misleading. In reality, client and server have different concerns, security, latency, state management. Shared logic such as validation or formatting is possible, but full code reuse is rare and often anti-patterned. Second, the notion that Node.js is only for real-time apps is incorrect. While excellent for WebSockets and chat, Node.js excels in I/O-heavy microservices, API gateways, and data transformation pipelines, not just real-time. Third, the belief that Node.js replaces Java, Rails, or Python is false. At Yammer, Node.js was one tool among many. Java powered core services. Ruby on Rails drove the web frontend. Node.js handled high-concurrency, low-latency endpoints. The real win was developer velocity, ecosystem momentum, and operational simplicity.

The Node.js Architecture: Event Loop and Non-Blocking I/O

Node.js is built on a single-threaded, event-driven architecture. Unlike traditional threaded servers like Apache or Tomcat, Node.js uses an event loop to handle thousands of concurrent connections. A simple HTTP server demonstrates this:

const http = require('http');

http.createServer((req, res) => {
  setTimeout(() => {
    res.end('Hello after 2 seconds');
  }, 2000);
}).listen(3000);

While one request waits, the event loop processes others. This is powered by libuv, which abstracts OS-level async I/O such as epoll, kqueue, and IOCP. Google’s V8 engine compiles JavaScript to native machine code using JIT compilation. In 2012, V8 was already outperforming Ruby and Python in raw execution speed. Recently, V8 TurboFan and Ignition have pushed performance into Java and C# territory.

Yammer’s Real-World Node.js Adoption

In 2011, Yammer began experimenting with Node.js for real-time features, activity streams, notifications, and mobile push. By 2012, they had over fifty Node.js microservices in production, a real-time messaging backbone using Socket.IO, an API proxy layer routing traffic to Java and Rails backends, and a mobile backend serving iOS and Android apps. A real-time activity stream example illustrates this:

io.on('connection', (socket) => {
  socket.on('join', (room) => {
    socket.join(room);
    redis.subscribe(`activity:${room}`);
  });
});

redis.on('message', (channel, message) => {
  const room = channel.split(':')[1];
  io.to(room).emit('activity', JSON.parse(message));
});

This architecture scaled to millions of concurrent users with sub-100ms latency.

The npm Ecosystem and Developer Productivity

Node.js’s greatest strength is npm, the largest package registry in the world. In 2012, it had approximately twenty thousand packages. Now, It exceeds two and a half million. At Yammer, developers used Express.js for routing, Socket.IO for WebSockets, Redis for pub/sub, Mocha and Chai for testing, and Grunt, now Webpack or Vite, for builds. Developers could prototype a service in hours, not days.

Deployment, Operations, and Observability

Yammer ran Node.js on Ubuntu LTS with Upstart, now systemd. Services were containerized early using Docker in 2013. Monitoring used StatsD and Graphite, logging via Winston to ELK. A docker-compose example shows this:

version: '3'
services:
  api:
    image: yammer/activity-stream
    ports: ["3000:3000"]
    environment:
      - REDIS_URL=redis://redis:6379

The 2025 JavaScript Backend Landscape

EDIT:
The 2025 landscape includes Node.js 20 with ESM and Workers, Fastify and Hono instead of Express, native WebSocket API and Server-Sent Events instead of Socket.IO, Vite, esbuild, and SWC instead of Grunt, and async/await and Promises instead of callbacks. New runtimes include Deno, secure by default and TypeScript-native, and Bun, Zig-based with ten times faster startup. Edge platforms include Cloudflare Workers, Vercel Edge Functions, and AWS Lambda@Edge.

Matthew closed with a clear message: ignore the hype. Node.js is not a silver bullet. But for I/O-bound, high-concurrency, real-time, or rapid-prototype services, it is unmatched. In 2025, as full-stack TypeScript, server components, and edge computing dominate, his 2012 insights remain profoundly relevant.

Links

Relevant links include Matthew Eernisse’s blog at fleegix.org, the Yammer Engineering Blog at engineering.yammer.com, the Node.js Official Site at nodejs.org, and the npm Registry at npmjs.com. The original video is available at YouTube: Node.js and JavaScript Everywhere.