Design

Without a doubt, Microservices as an architecture has grasped the imagination of modern development like no other.

We’ve found that, contrary to what many will tell you, it defies tight definition. Specifying how microservices should interact with each other, how they should store and master data, and how they should be deployed is great for a conference talk, but the style has been adopted too broadly now to be prescriptively tied down by anyone. Opinions abound, and yet you will find no consensus in what microservices actually are beyond the use of some form of effective isolation, usually network based.

When building microservices, you have to naturally distribute your application around a network. It is almost always the case that you are building in a cloud environment, and often using immutable infrastructure.

The Challenge of Dynamic Service Location

In traditional monolithic applications, components communicate through in-process method calls. With microservices, these components are distributed across a network, and their locations can change dynamically due to:

• Auto-scaling events
• Service failures and recovery
• Deployments and updates
• Infrastructure changes
• Container orchestration

This dynamic nature makes hardcoding service locations impractical and brittle. Service discovery provides a solution by enabling services to dynamically find and communicate with each other.

A question often posed to us during our research and project work is “how should I secure a Microservice?”

When it comes to securing microservices, two primary approaches dominate the landscape: session-based security and OAuth/token-based security. Each has its strengths and weaknesses, and understanding these differences is crucial for making the right architectural decisions.

Session-Based Security

Session-based security represents the traditional approach to web application security. In this model: