einnocent (19) [Avatar] Offline
#1
This section leaves a bit to be desired since, in my experience, this is one of the biggest issues in working with a microservices architecture. When breaking out the monolith, at first you just spool up each new application. This becomes more and more cumbersome as there are more apps with more code and DB migrations and data to keep updated. As the plethora of services becomes less and less runnable locally, the developer turns to service-level integration tests, curl commands against the local service, and letting QA deal with it in integration. Not an optimal state of affairs. And while the message mocking framework as described isn't a terrible idea, it's not terribly helpful if one isn't relying entirely on a message system for inter-service communication.

So could you perhaps describe some other solutions? How do the big players make this work? How do orgs do local mock services when they roll with REST? It is as obvious as creating a service with a bunch of mock endpoints, or is there more subtlety than that? Will local development with microservices be destined to be a set of compromises?
Richard Rodger (27) [Avatar] Offline
#2
You're right there's quite a bit more that should be covered on this topic. And you're right that it gets messy. The topic is covered indirectly form other angles in later chapters, but not cohesively.

I will make a note of this as a potential blog post - that will give me space to discuss in the depth it deserves.
einnocent (19) [Avatar] Offline
#3
Thanks for your attention to this. Would you mind posting a link to the post here to whenever you get around to writing it, please? Otherwise it won't pop up on my radar.
Richard Rodger (27) [Avatar] Offline
#4
Of course smilie