Pragmatica Aether: A Modern Distributed Runtime for Java Microservices
Pragmatica Aether proposes a return to Java's managed runtime roots, offering a distributed, fault-tolerant environment where applications focus solely on business logic. It aims to decouple infrastructure concerns (like service discovery, configuration, and fault tolerance) from application code, which are currently bundled in fat JARs and managed by orchestrators like Kubernetes. This approach seeks to simplify microservice development and deployment by centralizing infrastructure management within the Aether runtime.
Read original on DZone MicroservicesThe Problem with Modern Java Microservices
The article argues that modern Java applications, packaged as fat JARs within Docker containers and deployed to Kubernetes, have strayed from Java's original design philosophy. Historically, Java applications ran within managed environments (app servers, OSGi containers) that handled infrastructure concerns. Today, each microservice often bundles its own web server, serialization, service discovery, configuration, and observability frameworks, leading to significant coupling and complexity. This tight coupling means infrastructure changes ripple through many services, increasing rebuild, test, and redeployment cycles, and creating conflicts between different layers (e.g., Spring DI vs. Kubernetes service mesh for routing).
Aether's Core Architectural Idea
Pragmatica Aether reintroduces the concept of a managed runtime where the application provides only business logic, expressed as annotated interfaces and their implementations. The runtime transparently handles all infrastructure aspects: inter-slice communication (direct method invocations via generated proxies, no HTTP clients), service discovery, retry logic, circuit breakers, serialization, resource provisioning, scaling, transport, configuration, observability, logging, tracing, monitoring, and security. This clear separation enables applications to scale from local development to global distributed deployments without code changes, with the only application-level design requirement being that slice methods should be idempotent to facilitate transparent retry, scaling, and fault tolerance.
Idempotency in Distributed Systems
Idempotency is crucial when operations might be retried due to transient network failures or node outages. An idempotent operation produces the same result regardless of how many times it's executed with the same input. For example, a "charge customer" operation is not idempotent by default, but can be made so with an idempotency key to prevent double charging.
Under the Hood: Key Architectural Decisions
- Consensus KV Store: Aether uses a built-in, crash-fault-tolerant, leaderless consensus protocol (Rabia) for all configuration, deployment state, and service discovery, eliminating external dependencies like etcd or Consul.
- Built-in Artifact Repository: A DHT-based storage with configurable replication (e.g., 3 replicas with quorum reads/writes) stores application artifacts, removing the need for external repositories like Nexus or Artifactory. Artifacts are chunked, distributed via consistent hashing, and integrity-verified.
- ClassLoader Isolation: Each "slice" (microservice unit) runs in its own ClassLoader, preventing dependency conflicts when different slices use different versions of the same library.
- Declarative Deployment: TOML blueprints define the desired state (slices, instance counts), and the Aether cluster automatically converges to this state, handling artifact resolution, instance distribution, and routing.
- Infrastructure Independence: Aether nodes are identical, simplifying infrastructure management. Node, runtime, and application updates can occur on independent schedules without downtime, leveraging the inherent separation of concerns.
Fault Tolerance and Rolling Updates
Aether is designed for fault tolerance, surviving the failure of less than half its nodes. It maintains functionality even with degraded performance until replacements are provisioned. Quorum-based consensus ensures operations continue as long as a majority of nodes are alive. Leader failover is near-instant, and node replacement is automatic, with requests to failed nodes immediately retried on healthy ones. Rolling updates support zero-downtime deployments through weighted traffic routing, allowing gradual traffic shifts (canary deployments) and instant rollbacks based on health metrics, significantly reducing the risk of deployments.