Learn how validating the interoperability of the micro services in development avoids issues 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.ai
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 brings the entire certification pipeline into the development process. Using devops tools like helm or service-mesh, Roost identifies service dependencies automatically and maps them for efficient management.
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.
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.
Figure 2. Received workload/service running on the team member’s Roost instance
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.
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.
Figure 5. Teams can see certified workloads
