Responsible Microservices

Chapter 6. Indirection Layers

In computer science, there are three answers that work for every question you’ve ever been asked: “42,” “It depends,” and “Another layer of indirection.” Microservices do not live alone; they work in concert to deliver business value. Your services are constantly working with a veritable cornucopia of other services, all of which are changing and evolving at their own rate (see Chapter 2). How do you protect your services?

This principle is similar to failure isolation (see Chapter 5), but with a twist. Instead of guarding against the inevitable failures of our services, we seek to protect them. “From what?” you ask. From external dependencies that change frequently or are complex to use. This pattern is common in software. Often, this is a vendor dependency, where one service provider is swapped for another. It could be something large (like an ERP system), or something relatively simple (like a mapping service).

Abstract Away External Dependencies

Enterprise systems—monoliths and microservices alike—will inevitably rely on some set of third-party dependencies. Traditionally, your monolith would directly call those other systems or APIs. This was (often) done to ensure acceptable performance. When it came time to change the dependency (for whatever reason), you’d update your system accordingly. Sounds simple, right? It was, but that was a simpler time.

Today, your applications and the systems they often rely on are increasingly complex. When you ...