13 posts · 6 companies · newest first
A URL is a name, and names get reused. Replace the bytes behind https://repo.example.org/order-processor.jar and every permission granted to that URL still applies, now to code nobody audited. So far in this series, Part 1 declared constraints on a remote call, Part 2 vetted code before a client loaded it, Part 3 established who is calling, and Part 4 carried that chain of identities across the wire.
Alice calls the order service. The order service calls the ledger on her behalf. At the second hop, the ledger has to decide whose authority the debit is being made under. Most stacks answer badly. Forward Alice’s bearer token verbatim, and the ledger cannot tell her from the service that relayed it. Drop the token and the ledger sees a machine, with no record that a human started the chain. Neither option lets the ledger authorize the combination.
The constraint system stops a bad call before it leaves the JVM. The Safe Codebase Audit Pipeline stops bad code before a client ever loads it. What remains is identity: who is calling, and can you verify it? Most frameworks answer with a token check at the door. A filter validates a bearer token, sets a thread-local variable, and hopes that nothing downstream forgets to look at it. DirtyChai answers differently.
In Part 1, the minimal deployment showed constraints traveling with the proxy: authentication, encryption, hardened deserialization, all declared in configuration and enforced at the call boundary. The proxy is a JAR. That JAR was downloaded and unmarshalled before any constraint ran. That step is the earlier problem. Distributed Java systems that load remote code are vulnerable to supply chain compromise: an attacker can replace a legitimate JAR with one containing malicious bytecode.
The more distributed a system, the harder it is to secure. Code crosses JVM boundaries. Objects are serialized across trust boundaries. Third-party proxies run inside your process. The usual answer is a network firewall. It helps, but it operates at the wrong level. Java 17 deprecated the SecurityManager, Java 24 put the final nail in its coffin. Most developers didn’t notice.
Distributed unique timestamp identifiers provide a powerful means of generating globally unique, human-readable 64-bit values at sub-microsecond speeds. By embedding a host identifier directly into a nanosecond-resolution timestamp, you gain a simple, chronologically sortable, and intuitive scheme for correlating events across multiple hosts. This approach offers significant benefits in latency-sensitive systems where even small delays can become expensive at scale. Introduction In a world of horizontally scaled microservices, ensuring that each event or message receives a unique identifier…
The Jobteaser application contains a lot of different relatively independent modules to help universities provide career guidance to students: a job board, a career event management system, a career advice appointment management system…When we decided to migrate our application’s backend from a monolith to a service-oriented architecture, we strived to keep each module as isolated as possible from the others in the event of an incident. If the career appointment system was down, students should still be able to browse and apply to job ads.That isolation is achieved through what we’ve called…
When it comes to the communication between microservices, there are 2 possible extremes:All-sync: whenever a service needs data from another service, it fetches it via a synchronous API call (REST, gRPC, GraphQL). Service calls service calls service… which tends to evolve into layers of APIs, where each layer has dependencies on the next.All-async: no sync calls between services, all communication is event-driven or in the form of data replication. This tends to form silos: independent services that are fed all the data they need by an async mechanism and can function independently of any…
This is an introduction to how we’ve implemented microservices at a mid-size scale-up called Jobteaser, with a mix of Go and Ruby service chassis, gRPC APIs and data replication via Kafka.Foundation: The service chassisBack in early 2019, when Jobteaser decided to get serious about breaking up its decade-old Rails monolith into microservices, we assembled a Foundation team that started working on an in-house service chassis.It was soberly coined service and came in two flavours: the rb-service framework in Ruby and the go-service framework in Go. Four years later, they still form the…
My name is Avery Dunn and I am a rising master’s student at Washington University in St. Louis studying computer science. For the past 12 weeks, I have been a software engineering intern on the API & Platform pod of the Foundation team. I am an active Strava user and have been for approximately 3 years with my favorite activity being running. Some other activities I enjoy are playing the piano, reading novels, or skiing (more of a luxury rather than a hobby). My internship at Strava has been a wonderful experience to help me learn, grow, and develop into becoming a more well-rounded,…
This is the story of how we used the Strangler pattern to migrate our public API from a monolithic codebase to a fully fledged BFF over the…
This article is the last part in a series of posts aiming to cast some light onto how service architecture has evolved at SoundCloud over…
Today is the starting of the fourth year since I began my journey with microservices. I started with a theoretical knowledge about this architecture and now I ended up with a more deep and practical experience. While I still believe I can find news problems in microservices, I prepared an article with a list of problems which I had a chance to face in my work. You will read short stories which I faced during my work. If you don’t agree with them and think that they could be fixed and identified earlier - that’s okay, I believe that you can’t find a microservices structure with identical…