Microservices need to honor contracts

“The fox knows many things, but the hedgehog knows one big thing.” Archilochus said in 700 B.C. Centuries later, Unix was developed using similar philosophy: “Do one thing and do it well.”

Derived on the same principles, microservices aim to deliver specific functionality in an independent repeatable way, but any change to that microservice must not result in breaking other services or consumers that it interacts with. Because microservices often invoke other microservices, each must provide a well-defined contract for deployed versions so that any change in the producer microservice will not break the functionality of its consumer counterparts.

There may also be use cases of rolling back consumer microservices that rely on a previous version of producer service, and that brings the discussion how and when code deprecation be done. Importantly, no service should break the versioned contracts unless there are no more consumers with functionality dependent on that specific producer version.

Contracts must be honored

A good microservice implementation must be backward compatible and honoring service contracts must be high on priority. An ideal approach to accomplish this is to follow blue-green deployment model to deploy new microservice code along-side with existing production version code, and teams can test the new code before making it the default production version. This validation model makes the way to get old contracts out of service once every microservice is tested successfully for desired results.

Another option is to have each microservice API have major API version in the URL itself for example, http://myservice/v1 and http://myservice/v2 represent two version of the same service that produce different results.

Cloud-native implementation

One of the foundation premise of microservice architecture is to provide capability to develop and deploy microservices as small, independent but completely functional applications. This architecture has significant benefits—in enabling agile development process, and delivering complex distributed applications. However, microservices do not reduce or eliminate technical complexity but do encapsulate the complexity in a new, distinct wrapper and sometimes add to it.

The pattern requires keeping application logging, security, monitoring, and versioning separate for each microservice and adds development overhead compared to conventional practices. However, it enables a full level of code isolation in a cloud-native way. Each service can be deployed using multiple code versions. For each microservice, one version can be tagged as default serving version or production version. This approach enables various options, including preproduction testing and smoke testing, and it makes rollback operations much simpler.

Design easily, develop efficiently

In a nutshell, microservices aim to reduce complexity via modularization, loose coupling, and contextual bindings. You are in good state with microservices if you can develop independent microservices having version contracts and can release each one independently while maintaining contractual obligations with consumers. A complete implementation of microservice architecture uses the best practices and guidelines for microservice as a contract.

Developing these practices into organization will not only make teams and processes agile but also help your design, development, and testing work to deliver the best performance. Versioning approach not only supports backward compatibility but also allows enough lead time for migrations of consumer apps using the old API version. Apps can also provide feature and permission deprecations based on schedule agreed with the consumer apps, leading to smoother upgrade cycles.

Microservices are the emerging platform architecture that is here to stay, and there are many good reason to support this. The significant advantages provided by microservices architecture such as support and right fit for agile development make it a popular choice to enable develop and rollout quicker releases. Bonding those releases with version contract bindings with other microservices will guarantee the continuous support and availability of stable execution environment throughout the product life cycle.