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.

 

Like this information? Share it:

You may also want to review these recent posts.

Create a Multi-node Production-like Kubernetes Development Environment
Create a Multi-node Production-like Kubernetes Development Environment
25 October, 2021

How you can run and test containerized applications on a local systems. For Developers to run and test their containeriz...

See How Fast & Easy it is to Create and Share a Kubernetes Cluster
See How Fast & Easy it is to Create and Share a Kubernetes Cluster
1 November, 2021

See how easy it is for developers to enable and share a Kubernetes multi-tenant cluster and share it with others outside...

New & Unique Way to do CI so Code Changes are Always Production-Ready
New & Unique Way to do CI so Code Changes are Always Production-Ready
15 November, 2021

What is the primary purpose of continuous integration (CI)? The primary purpose of CI is to integrate code/service chang...