Learn how validating the interoperability of the microservices in development avoids service integration issues prior to release or in production.

Containers are fantastic enablers for cloud-native journeys. Containerized architecture has paved the way for enhanced scalability and flexibility in applications. As an increasing number of applications are being developed with or migrated to container architecture, it has led to the proliferation of them.

Services are essential for decoupling responsibilities and leading to a more autonomous and scalable solution, but they also increase the application complexity.

Validating the interoperability of these services, however, can pose a significant challenge for development teams. The interoperability of these services can be a substantial contributor to delayed-release cycles, as integration issues between services are often discovered later in the development cycle, closer to the release, and can impact release timelines.

 

Certifying Services with Roost DesktopRoostScreenshot-Desktop-Cloud-Events-2021-10-800px

Roost provides a collaborative change certification platform that helps developers discover interaction and interdependencies’ issues much earlier in the development cycle. With the help of Roost, development teams are enabled to improve the predictability and stability of releases, enhancing developer productivity. Roost spins up a temporary, sharable production-like environment. Once the release is complete the instance can be disposed of reducing the need for cloud services.

Suppose an application has hundreds of services, and therefore hundreds of separate repositories, managed by different teams. These services are interdependent, and the dependency graph could be pretty complex. When any service goes through a change, testing the changed service with its downstream dependencies and conducting integration testing of the entire application with that service change is required. Once this two-step testing process is complete, the next challenge is to validate the service’s change independently and verify it for release.

Roost’s collaborative service certification platform brings the entire certification pipeline into the development process. Using tools like helm or service-mesh, Roost identifies service dependencies automatically and maps them for efficient management.

WATCH AN 8-MINUTE DEMO VIDEO >>

 

Local testing with Multi-node Kubernetes Clusters

Example of How Roost Works – Bob & Divyesh

Suppose a developer, Bob, is working on a service change. First, he needs to test his service with the dependent services. Once he deploys his service change to Roost’s policy driven multi-node Kubernetes cluster and completes unit and integration testing, he can certify the change locally. Roost then marks it as a Local Certified Change, while keeping the required metadata (collaboration id, source repo/commit details, patch files, timestamp, owner, and dependencies’ state etc.).

Once Bob has the Local Certified Change, he can transfer this change to his team member, Divyesh. Divyesh is running the exact same development environment, controlled by the Roost control plane’s policies.

Blog-change-notification1
Figure 1. Roost creates a peer-to-peer, real-time, and policy-driven process that allows developers to test and certify services and then share with others to ensure interoperability.

 

Once Divyesh receives the change, Divyesh can test the change in the similar way and mark it as a Local Certified Change.

Blog-change-notification2
Figure 2. Received workload/service running on the team member’s Roost instance

 

Blog-change-notification3
Figure 3. Certify workload once unit, integration testing is done


Any of Bob and Divyesh team members can come to the Collaboration Activities section within the Team Dashboard and mark it as a Local Certified Change. Team members are enabled to push an atomic commit on behalf of the project owner.

Blog-change-notification4

Figure 4. See source repo details, needed for atomic commit

 

The Local Certified Change pipeline can be based on the number of team members testing it. The service change can then be sent to a Roost UAT server as well as any other Kubernetes UAT server. On that UAT service, the complete application testing can be completed with hundreds of services. Once testing is completed, it can be marked as the Last Known Certified Version.

Blog-change-notification5
Figure 5. Teams can see certified workloads

 

 


WATCH VIDEO DEMO >>Laptop-DemoVideo 500

Roost provides a production-like environment to developers to ensure services are interoperable between environments. Developers can certify that services are working together prior to release ensuring absolute consistency between environments.

See how Roost helps developers validate the interoperability of microservices avoiding service integration issues discovered prior to release.

 

Sudhir Jangir

About Sudhir Jangir

Sudhir is the CTO and Co-Founder of Roost. He has 20 years of experience developing enterprise applications and leading technology teams.

Please Share this Blog

You may find these blog posts of interest too.

How to use Event Framework for Complex Test Environments
How to use Event Framework for Complex Test Environments
October 26, 2021

With the increasing number of services in cloud-native applications and their dependence on various third-party applicat...

Accelerate Software Delivery Releases - Eliminate Staging Environment
Accelerate Software Delivery Releases - Eliminate Staging Environment
October 26, 2021

Current Testing and Staging Processes are Slow & Cumbersome Current DevOps pipelines have multiple test environments...

Remove friction between product managers and dev by using preview URLs
Remove friction between product managers and dev by using preview URLs
October 26, 2021

What captivated me about Heisenberg's Uncertainty Principle, was not just the principle itself, but its fundamental natu...