How Roost is helping cloud native service development without the need for Mock services, and how to achieve production like accuracy from the first line of the code.
Typically an application has multiple discrete services. These services may be dependent on some internal or external services, because of that there will be some challenges, some of those challenges are:
my service keeps on changing with time
over the time, the format in which data is shared might just keep on changing from service to service. I would need to be in sync with those changes. The change might break the services, which are dependent on it.
Creating a different service versions for this change may be a solution; it's very difficult to maintain these versions. Or create one more endpoint for that particular change.
Performance/Integration Testing of my change
If make a change in my service, and then if I need to do performance testing of my change, which depends on some other service. To do it without hitting a real service in production, I may have to create a mock service.
Latency
As microservices are developed in isolation, this means I might have to wait for the dependent service to be ready before starting my work.
So versioning is challenging to maintain and endpoints add lot of work. Mocking creates a fake version of a service, besides that keeping my mock in sync is not an easy task.
So how Roost is solving these problems:
Roost provides a peer to peer collaboration feature, where services can be shared in a secure, and a realtime way with other Roosters or Roost instances
With this, we can do realtime integration, end to end testing; will eliminate the need of Mocking, versioning, or separate end-points.
Top comments (1)
So the solution to mocking is to set up a complete system and run it end-to-end?
I thought the solution to setting up a complete system and running it end-to-end was mocking. :)
Perhaps a reasoned discussion of where each strategy can be beneficial would be useful?