The Application of Theseus' Paradox

The study of philosophy, at least in the past, has involved asking questions that seem, on the surface, to be, well, irrelevant. After all, is it really all that important to know “whether a ship that had been restored by replacing every single wooden part” remains the same ship? That’s the question Plutarch asked in Life of Theseus and thereafter became known as Theseus’ paradox. More generally stated, it asks “whether an object that has had all of its components replaced remains fundamentally the same object.” (Ship of Theseus, Wikipedia)

We might ask the same thing of microservices which, when applied to existing monolithic applications, seeks to essentially restore the application by replacing functions with a complementary services. Functions are small (or should be), by design, and thus the term “micro” is applied to the resulting, decoupled services. The differences between the two can be viewed in terms of communication. In a monolithic application functions are invoked by referencing a specific address in memory. In a microservices-based application, functions (services) are invoked by referencing a specific IP address in the network.

Conceptually, the two are the same, with only the mechanism for invocation of individual functional components differing. A resulting diagram would show essentially little difference but that the monolith’s “box” is a single server and the microservices’ “box” is the entire data center.One uses localized addressing, the other network addressing. The code for each of these functions could be exactly the same, just like the wood in Theseus’ ship. 

But its business functions remain consistent and, in fact, if we’ve properly decomposed the application the user should see no discernable difference between the two. One could argue that from the perspective of the passenger on Theseus’ ship, there is no difference between the two. Nor should there be.

But philosophers tend to dig deeper, and, like them, so must we, because the difference between a monolithic application and a microservices-based one are, in fact, quite important to operations.

The Complexification of Network Operations

Microservices simplifies many aspects of the application development process but in doing so creates a great deal of operational complexity. The number of network connections between the disparate parts of a microservices-based application necessarily require associated overhead in managing the various network characteristics required: IP addresses, VLANs, NAT tables, and more. Scalability, too, becomes a challenge that even Dijkstra might find frustrating as placement of the microservices and load balancing service has a very real impact on performance based on how many segments in the network must be traversed.

Additional policies are suddenly required, for the security policies applicable to one service that directly access a sensitive data source are not those that are necessary to secure another service that manages preferences or session state. The resulting web of micro-security policies certainly provides many of the same benefits as microservices themselves, that is finer-grained control and a kind of elegant simplicity, but at the same time becomes an operational nightmare as policies must suddenly move with services, wherever they might pop up in the architecture.

Deployment, too, suddenly becomes exponentially more difficult, like moving from a simple box-step dance to the more complicated Flamenco, with many more steps and a lot more movement across the dance floor (data center). Orchestration and automation become a requirement to ensure the consistency and predictability necessary to move all the pieces into place at the right time.

Those responsible for providing these network and security services for applications need to recognize that the ship is not the same, no matter what the fifty-foot thousand view may be. It sounds simple; one application is simply replaced by ten services. Voila! The app has been recreated, just like Theseus’ ship. But from the operational perspective this ship is not the same at all. The joins (integration) in the new ship are completely different, which can change the friction created against the sea (network) and tend to cause the ship to sail more slowly.

Microservices are still emergent. They aren’t taking over the world (yet) but it’s important to recognize that it isn’t as simple a matter as tearing down Theseus’ ship and rebuilding it. Network and security service operations teams must take the philosopher’s view rather than the passenger (user) view because the impact on the network and on security is very, very different.