Skip to main content

Use APIs to Decouple From Implementation Details

Context​

Microservices are being adopted. Microservices can get data from other microservices by directly accessing their database.

Problem​

  • Internal schema changes leads to breaking other microservices.

Solution​

Decouple from the implementation details like database schema using an API as single point of access to the microservices' data. The API hides the implementation details of the microservice's internals. The microservice's internals can be changed without breaking any consuming microservice as long as the API stays backward compatible.

To remove teh temptation of accessing another microservice's internals, we advise isolating the storage area of each microservice.

Maturity​

Proposed, evaluation required.

Sources of Evidence​

L3:

  • Example of migration to microservices
    • RESTful API => dependent services not affected by internal structure changes

L7:

  • microservices encapsulate data and expose processing logic remotely via RESTful HTTP or async message queues
  • => independent deployment, changes, substitution, scaling
  • Hide internal implementation details (Newman's principle)
    • e.g. the databases
    • use tech-agnostic APIs
    • Resembles componentization via services of Flower and Lewis
    • Viewpoints: Logical and development
    • Intent: flexibility, portability, maintainability
    • SOA pendant: common sense to do that

L8:

  • Cites Werner Vogel at Amazon:
    • encapsulate data with business logic that operates on the data
    • only access through published service interface

L12:

  • Same as L3

L16:

  • Data kept by service should not be accessible from outside
  • enforces to use API
    • decouples external data consumers from internal representaiton of data
    • enables independent evolution of services
    • internal data model can be freely changed while interoperability is maintained

L22:

  • James: Shared-nothing approach
    • always program to external interfaces rather than using domain lib of other team
  • Mike: refactoring scenarios
    • decouple shared interface from internal models and source code
      • no matter size or shape of components behind interface
      • establish standards and practices for defining and implementing interfaces
        • stateless, message-oriented, hypermedia-driven
    • resize components to better match speed and safety requirements of domain
    • challenge: most people tackle code/boundary refactoring without dealing with the decoupled interface
      • => lot of breakage and problems
    • Interface agreements
      • not code-centric objects
      • standard messaging models as HTML, Atom, Collection+JSON, HAL, Siren

L25:

  • Interface design must be fixed
    • individual services may change internally
    • need to update interface
      • => requires all connected services to adapt
      • Keeping interface definition stable minimizes impact of changes!

L41:

  • develop open API for clients and traders in bank to use
    • eliminate direct db queries and the likes
    • team takes full ownership and control over internal implementation details!

L42:

  • Migration to microservices, survey

  • 50% reported not migrating the data

    • not align well with "hide internal implementation detail", nor with "decentralized data management"
    • may hinder independent evolution of microservices
    • may hinder to scale up services and their data
    • might be an option if they have no stringent need for scalability

L44:

  • Interactions between microservices restricted to data exchange using exposed interface

L53:

  • microservices should communicate over well-defined message interfaces
  • possible three microservices developed by different teams/companies as long as interfaces well maintained

L58:

  • Context: Synapse architecture (message pub-sub system)
  • new features / refactoring => local DB schema must be changed / new data must be published/subscribed
  • Updating publisher DB in isolation => consumers should not observe internal changes done to the publisher
    • e.g. before removing published attribute from DB, a virtual attribute of same name must be added
  • Semantics of published attribute must not change
    • e.g. type must not change
    • instead: publish new attribute, eventually stop publishing the old one
  • Publishing new attribute often motivated by subscriber need
    • Publisher needs to be deployed first
    • Partial data boostratp to allow subscribers to digest newly subscribed data

L59:

  • when DB big, data structures change frequently, or dataflows at high volume
    • => need for encapsulating data within service
    • API as point of access
    • structure of API calls should be stable and backward compatible, even if underlying data/schema changes

LN43:

  • team has ownership over service and what happens inside
  • other teams only have to care about the interface of the service
  • Good interfaces hide implementation details
  • Figure 3: microservice owns data (one database per service approach)
    • if other service needs to know about the data, they go thru the API
    • => loose coupling
    • can modify underlying database without chaning other service as long as the API stays teh same
  • Figure 4: one db for all services => tight coupling
    • access to data that they should get over API
    • easy to quickly access data from different table instead of service call

LN48:

  • microservices expose endpoints to transfer any data or information to other services

LM43:

  • Context: SLR findings about microservices in DevOps
  • S24 suggest guidelines
    • keep microservice interfaces as simple as possible
    • use technology that does not require specific programming language => avoid integration issues
  • Table 10: lists the API access pattern

Interview D:

  • shared databases counteracts moving fast => coupling
    • cannot change or evolve shema without affecting other microservices
    • tables become the API
  • Views on a table is already better than accessing the original table directly
    • View can code what the receiver needs and not what is there
    • Decouples from the underlying implementation as well
    • Same for GraphQL: must never be hard-coupled to schema, has to base on logic interface or API scheme of its data

Interview E:

  • process boundaries for isolation
  • no temptation to grap from the other side => has to be a conscious decision

Interview F:

  • Decoupling of components
  • => combine multiple technologies because they talk via an API