Microservices

R3zk0n · October 2, 2025

Contents
    • With the adoption of Agile software development, some development teams have moved away from monolithic web applications in favor of many smaller (“micro”) web services. These services provide data to users or execute actions on their behalf.
      • The term microservice can refer to these individual services or to the architectural pattern of decomposing applications into multiple small or single-function modules.
      • When well-coded, microservices provide the basic required functionality without dependencies. Because of this, developers can create and deploy the individual services independently. Multiple applications or users can leverage the services without having to re-implement functionality.
      • For example, an e-commerce website might provide individual microservices for Auth, Users, Carts, Products, and Checkout. The developers working on the Products service can update their application without needing to redeploy the entire website. The Products service could even use its own database backend.
      • In this type of environment, microservices are often run in containers and must intercommunicate. Since containers and their IP addresses are ephemeral, they often rely on DNS for service discovery. In a common example, Docker networks created with Compose treat each container’s name as their hostname for networking purposes. Applications running in Docker containers can then connect to each other based on those hostnames without needing to include IP addresses in their configurations. There are many other software solutions that can aid in service discovery by acting as a service registry but we will not go in to those details here.
      • Each microservice module exposes its functionality via an API. When an API is exposed over HTTP or HTTPS, it is called a web service. There are two common types of web services: SOAP and RESTful. We’ll focus on the more-common RESTful web services in this module.
      • Rather than expose microservices directly on the Internet, an API gateway acts as a single point of entry to the service. Since API gateways often provide controls (such as authentication, rate limiting, input validation, TLS, etc), the microservices often do not implement those controls independently. In these cases, if we can somehow bypass the API gateway, we could subvert these controls or even call backend services without authenticating.
      • https://microservices.io/patterns/apigateway.html
      • API gateways can also implement security controls (such as input validation or TLS). While an API gateway may require HTTPS traffic from external connections, sometimes they are configured to terminate encrypted traffic and use cleartext HTTP when they send data to internal services, as that traffic traverses what is considered an internal or trusted network.

    Twitter, Facebook