Mocking Microservices Made Easy with Microcks

Whilst microservices-based architecture offers a great deal of flexibility to your first applications, its generalization within the enterprise may raise concerns about service lifecycle management and efficient test and release of new applications.

Multiplicity is the Main Challenge with Microservices

From the service provider point of view, there’s a need to develop, deploy, scale and manage dozens or hundreds of services. Lately, we have seen that PaaS/Caas solutions like OpenShift and Kubernetes are perfectly suited for that; mainly because container technology offers a uniform way to package and deploy components, and because the infrastructure services of this platform will allow you to manage components the same way. These services may include features such as clustering, monitoring, or self-healing.

However, from the whole enterprise management point of view, there is a need to coordinate and synchronize dependent artifacts and projects at scale. Actually, the first services built as pilot projects will not yield any scaling issues as they are usually created for experimentation and demonstration purposes. It is the next generation of microservices-based applications to be built that will amplify these challenges as they may involve many components that are both providers and consumers. This will require a lot of effort to avoid the waterfall effect as described below.

Where Service Oriented Architecture (SOA) practices have failed many years ago to provide a means for earlier synchronisation and to reduce project lifespan, there’s little chance microservices-based architecture will succeed without making changes. Especially when this situation may occur more and more frequently because of more fine-grained services!

Add a Pinch of Service Contractualisation

Injecting an extra "service contractualisation" step into the process to ease parallel development for both providers and consumers of services now becomes more important. This step should provide effective documentation on your service/API implementation as well as create a comprehensive set of request/response samples. In a service-based architecture, it is really important that the provider endorses this responsibility so that the provided samples are more representative of the service/API expected behavior.

Such samples should include nominal expected behavior and should also illustrate the edge and exception cases when using the service/API. This extra step may be indeed associated with agile practices like specification-driven development or behavior-driven development and may include explicit assertions on what response is expected regarding an incoming request.

Because we’re now living in an agile world where each step should be fluid, integrated with the toolchain, and repeatable in a continuous improvement loop, there’s a challenge for inserting this extra step without consuming too much time. Moreover, we’re looking for a solution:

• Supporting different kinds of service technologies (REST, SOAP, etc.), being the most agnostic possible to the specification format (Swagger, Open API, WSDL, and others) because of the diversity within enterprises,
• Usable by functional experts in order to concentrate the most of the business logic and thus being the most complete,
• Able to deploy and manage mocks of service at enterprise scale, on-premise, or in the cloud,
• Harnessing contracts, samples, and rules so that they can be used as validation artifacts for our service/API during development.

Microcks for Easy Mocking

Microservices Mocks (Microcks) is a new tool trying to solve this problem and addressing the concerns above. Its goal is to provide a platform for referencing, deploying mocks, and allow contract-testing of services and APIs. It can also be considered a service virtualization solution because it will allow you to provide a fake API or service implementation before development is actually done.

It is an open source project hosted on GitHub. It supports both REST API and SOAP web services and perfectly integrates into an iterative, contract-first delivery process.

Microcks is not trying to reinvent the wheel and lets you capitalize on already known tools. For example, at the time of writing, it relies on popular tools like SoapUI or Postman to edit your API request/response samples as well as your test scripts.

Once new artifacts have been created with these tools and saved into your source code repository, they just have to be referenced into Microcks so that it can start processing them. Thus, it discovers services/API, samples and tests, and is able to automatically publish new mock endpoints for the described cases. The web UI of Microcks allows to you to browse an internal registry of discovered services and display comprehensive information on available mocks. Developers wanting to consume a new service or API can directly start coding their application using provided mocks without depending on a provider’s release or availability.

The process of scanning artifacts and discovering new services or samples can be done repeatedly as Microcks schedules the scans or is able to be triggered via a commit webhook on your source code repository.

Microcks for Easy Testing

In case your SoapUI or Postman artifacts have defined assertions or tests, Microcks will be able to leverage them by running those tests on the endpoint of your choice. You’ll then be able to easily replay the same set of tests on different environments to check that the implementation of the service/API is matching the specifications!

Microcks offers a comprehensive summary of executed tests allowing you to check which operations are passing or failing as well as getting the payload and headers exchanged with the endpoint under test. Launching new tests can be done manually on-demand, but also via an API call. You can then consider launching new tests automatically; for example, when a new deployment of the application occurs. This last scenario is made easy because Microcks also provides a Jenkins plugin for easily integrating the execution of tests within your CI/CD pipeline:

The Jenkins plugin is available as normal build step into a free-form job or as a workflow step into a pipeline defined using a DSL.

Demo on OpenShift

The following video shows how easy it is to deploy Microcks on OpenShift as templates are provided in ephemeral or persistent flavors and samples for both REST and SOAP services are available as well. Installing it for a test drive is a matter of few minutes!

Summary

Service contractualisation is a strategic step to add into your process if you plan to deliver service-based architecture applications the efficient way. Harnessing artifacts from this step allows you to parallelize development of both provider and consumers of services and APIs and it allows efficient contract testing of your services in kind of a specification-driven development.

Microcks creates a solution for implementing this step by reusing some popular tools that lets functional experts contribute artifacts that may be the most representative of real-life use cases. Although it is still in early stages, it already has support for:

• Discovering REST API and SOAP web services from Postman or SoapUI artifacts,
• Dynamically exposing new mock endpoints for discovered services,
• Testing multiples endpoints reusing assertions and tests scripts to check compliance,
• Integrating all this stuff in a CI/CD pipeline managed by Jenkins,
• Providing UI and API for easy access to comprehensive information.

Microcks is easily deployable using the method of your choice; it provides deployment templates for OpenShift and Kubernetes and bare Docker images for other platforms or binary/source releases. Integrations with other tools (for example, Cucumber at time of writing) may be realized in the future as its open source with some extension capabilities and a set of APIs.

Many usages can be considered for it, such a providing pragmatic documentation complementary to Swagger files, deploying mock implementations of services to avoid dependency hell or for stubbing an API Management backend, harnessing executable specifications for services when using a Behavior Driven Development, etc.

When developing microservices, mind the API Mocking step as a way to develop faster and without dependencies. In the meantime, have a look at Microcks “Getting started” guide with provided examples and at the introduction video on the home page.