Slogging

Now matter which way you tackle contract evolution, you need to have a system in place to notify your service consumers. I envision a system based on “service blogs”, or “slogs”. A slog conveys information about the state of a service. As a consumer, I want to subscribe to a slog for each service I use. My aggregator becomes a “dependency dashboard” that tells me about upcoming service news. One thing I’d catch this way is upcoming service revisions. Optimally, the revision notification would include a pointer to a test environment and a time frame for testing. I would run my system against the new endpoint in order to test the functionality. If it works, great, I’m done. If it doesn’t, I need to figure out what I have to change to make things work again and I need to start a conversation with the service team to coordinate changes on my end and/or their end, as well as plans for when/how I migrate. As long as I’m on this topic, I should include the need to see basic ops stats bubbling up this way to so that I have a good sense that the services I’m using are meeting their SLAs. This whole part of the picture, which involves inter-team communication, seems pretty much ignored today. Mindreef is the only company I know that’s addressing it, and they’re in the early stages.