The benefits of microservices over monolithic architectures are undeniable, but they don’t always come to fruition. Deven Phillips, a senior consulting engineer at Red Hat, explained while microservices accelerate delivery speeds, improve quality and reduce costs, it doesn’t happen instantly and it doesn’t provide a clear path to those results. 

“The major problem is that it is overused without really considering ‘if I move to microservices, distributed architecture, is it going to provide sufficient return on investment to justify the investment of modifying my existing applications?’ ” he said.

RELATED CONTENT:
With microservices, more isn’t always better
Simplifying microservices with a service mesh
APMs are more important than ever for microservice-based architectures

When moving to microservices, many teams take a “code-first” approach, according to Sundar Subramanian, a general manager at Progress. “This approach supports speed, automation and possibly faster time to value, which is especially true if the number of microservices endpoints are not too many and complexity is less,” he said. But unless the team has clear and detailed communications across their services, it will be hard to achieve any of the benefits. 

“We need good guarantees across web services so that everybody has a non-ambiguous way of understanding how to communicate with one another,” said Phillips.  

Another way a team can apply microservices is through a contract-first development approach. Phillips explained contract-first development is a modern practice that shares similarities with traditional development styles. He compared the approach to languages like C, C++ and Java where there are ways of writing libraries and hints for developers using those libraries. For instance “in C you, write a header file that basically tells someone who is consuming your software how to call that software,” he said. 

By defining how services communicate with one another, people can work independently, ensure consistency, provide strong guarantees about service contracts, collaborate better, and save time, according to Phillips.  

“A contract-first approach leads to robust APIs for microservices as the review and approval of the API happens before coding stage. Change management is much easier as it happens before coding starts, so it is better to work on the shape of the API before implementation. A contract-first approach also leads to clear separation of functionality between services, leading to a better microservices design with each microservice being as granular as possible,” Subramanian added.

In addition, a contract-first approach to microservices makes it easier for teams to develop in parallel. While the idea of microservices is to enable parallel development, often too much time is spent on resolving integration issues between services. “Since the contract-first approach defines the interface first, the service producer and consumer teams know what to expect and stub software can be used to mock each other’s behavior,” said Subramanian.

To successfully apply contract-first development, Subramanian explained teams need to:

  • Make sure the API description is tight and granular.
  • Make sure the review stage is intellectually honest and comprehensive.
  • Make sure the API design is consistent and API/Interface description formats like OpenAPI/RAML/WSDL help.
  • Make sure the feedback cycles are tight and clear.

The way Phillips approaches contract-first development is to build an API specification, publish the specification so others can access it, and generate code contracts. For API specifications, Phillips takes advantage of OpenAPI or gRPC. “From those API specifications, we can get some significant benefits from code generation tools that can basically eliminate the majority of the boilerplate you would normally write when you are creating a new API implementation,” he said.

However, just like with any other approach, there are some disadvantages to a contract-first approach. For example, it requires developers to put together their own chain of work, requires effort and upfront time, and buy-in from everyone on the team. 

Subramanian suggested teams experiment with different approaches before settling on one approach.

Contract-first development just enhances the implementation of microservices, according to Phillips. “You can develop microservices without contract first, but then you have to worry about the ambiguity between multiple teams implementing different services or consuming those services,” he added. “If you are going to be building microservices, you need to have really good definitions of how those teams are going to integrate with one another and having that contract gives you those guarantees.”