Tag: microservices

The Anti-Corruption Microservice Pattern

Implement an anti-corruption microservice (ACM) to talk to an external system. Other microservices only communicate with the external system via the ACM. The ACM translates requests from the microservices system to the external system and back.

Use this pattern when you employ a microservices architecture and you want to ensure their designs are not limited by an external system. This pattern is an adaptation of the Anti-Corruption Layer (ACL) pattern for microservices architectures.

Context and problem

The context of the ACL pattern applies, but additionally, your application is made up of microservices and multiple of those communicate with the external system. If you’d only apply the ACL pattern, then you’d end up with multiple microservices that each have an ACL for the same external system.

Solution

Isolate the microservices from the external system by placing an Anti-Corruption Microservice (ACM) between them. This layer translates communications between the application’s microservices on the one hand and the external system on the other.

The diagram above shows an application consisting of 4 microservices, 3 of which communicate with the same external system via an Anti-Corruption Microservice. Communication between the microservices and the ACM always uses the data model and architecture of the application. Calls from the ACM to the external system conform to the external system’s data model and methods. The ACM contains all the logic necessary to translate between the two systems.

Issues and considerations

  • The ACM may add latency to calls between the two systems. Conversely, by caching data from calls by one microservice, the ACM might speed up calls by a different microservice.
  • The ACM is another microservice to be managed, maintained, and scaled.
  • The ACM doesn’t need to support all the features of the external system, just the ones used by the application’s microservices.

When to use this pattern

Use this pattern when:

  • Two or more systems have different semantics, but still need to communicate.
  • The external system is provided by a vendor and you want to minimize vendor lock-in. This elevates the idea of hexagonal architecture to the microservices world, where the ACM is a port and the external system an adapter.

Related resources

Acknowledgements

Thanks to Dev for pushing me to write up this pattern.

The Poetry of Microservices

This post is dedicated to she-who-wears-my-code-poet-shirt, my muse, my Valentine, my Angel.

code-poetMy favorite forms of poetry are the sonnet and the haiku. I’ve found their constraints to be helpful in guiding creativity rather than restricting it.

Programming and writing poetry are very similar, which is proven beyond reasonable doubt by the fact that the first programmer was the child of a famous poet.

It therefore makes sense to consider that constraints on programming would actually help us write better programs as well. Uncle Bob Martin argues in The Last Programming Language that indeed it does.

The four major programming paradigms have all taken away some of our freedoms as programmers, and that has gotten us better results.

Modular programming limits the size of the parts that make up a program. Structured programming limits the flow of execution to a couple of well-established patterns. Object-oriented programming limits data exposure across units. Finally, functional programming limits side-effects.

Since the constraints on size, execution patterns, data exposure, and side-effects have served us so well when writing programs, we may wonder if we can apply them elsewhere in our field.

One example would be in how we deploy applications. Applying the four constraints results in applications that are made up of small components that communicate using a couple of well-established patterns, hide their data, and limit their side-effects. In other words, we would end up with microservices.

After watching The Last Programming Language, I wondered where aspect-oriented programming fits in. Wikipedia does indeed list it as a programming paradigm, but Uncle Bob probably left it out because it isn’t as widely used as the other four.

That doesn’t mean that aspects can’t be extremely useful in some specific situations. Applying the concept to application deployment gives us the API gateway pattern, for instance.

Have you found yourself in situations where following constraints actually improved the end solution? Please leave a comment below.

Bug in my software
Disappears when in testing
Curse you, Heisenberg
–Andrew from Ottawa, Canada

See also this TED talk on computers writing poetry.