How to publish Micro-Service Contracts

One of the excellent off-stage questions which came up from one of the attendees of my presentation at Sydney Node Ninjas was how do you know your Micro-Service API is ready to be published. The specific questions were: when is it too soon, and when is it too late?

The reason why the above questions are of interest is that one of the primary ideas which I pushed during my presentation is that organic growth by external members outside of your organization would be ideal as this means your product will grow exponentially.

So when do you define a contract?

In response, I referred to some material from the book How Google Tests Software. There are interesting topics but let us summarize how defining a contract and building the service as quickly as possible.

Before we get into the details, the book highlights that Google appointed Software Engineers in Test (SET’s). These were the guys who rolled in from team to team to bring their expertise to each team in how to go about building their next API for their product. In my words, they were the A-Team.

Contract First Development

The very first thing which would be sketched out is the public API. The team and the engineers would then define the user code which would interact with the API and define the various edge cases. These tests would ensure that the consumer of the new API which was being built would be useable by external parties.

That process also ensures that the service only exposed the endpoints and interactions needed to ensure that the consumer had not only an accessible service but also an usable one.

As would lawyers, both the API ‘consumer’ and the producer on each side would negotiate what protocols and procedures to follow in order to conclude successful commercial contracts, the same would be for the developers to negotiate the nitty gritty details on how to get a steady flow of messages from system to system to conclude the necessary transactions required.

Stage Set - Go!

With the public API’s defined and the surface area kept to a minimum, it was now easy to rapidly build the software according to the designed and agreed behavior during the acceptance tests which was predefined by the team.

They had a micro-service to implement; the minimum requirement to launch and expose the endpoint to others.

With such a defined footprint defined, the team would deliver the agreed product knowing two things: they exposed the least amount of API’s thus probably creating a micro-service; secondly, ensuring their API was useful to the product which they were developing for.

blog comments powered by Disqus