Monday, June 26, 2017

re: hyperproductive development and debugging microservices

Story time.
At one company I've worked with, two guys knew the code completely cold. The other 5 devs only worked on bits and pieces, so it was difficult for them to have substantial discussions let alone valuable changes to the codebase. Visibility was further limited by there being no "end to end, production-like" stack. Each dev would run one component, developing and testing it always in isolation from the other components.
When I Am King(tm), all devs (and qa) will work on independent, production-like environments. They can beat the shit out of the entire system and get high-quality feedback on changes before it lands in production, where visibility is more awkward, and there are consequences.
For those people working with services, I mean microservices: check out Linkerd from the Cloud Native Computing Foundation (they host Kubernetes, Prometheus, and other valuable software). Linkerd allows services to be assembled from other services, with additional requirements. For example in production let's say service A calls service B. In environment "Staging", it would be configured to use (production) service A, but instead of A calling B, it would call the new version, B'. This allows "services" to be stitched up together easily. Another advantage is that B can be wrapped by another service C, allowing C to emit before/after messages and enabling further tracing. This allows service components to be safely debugged, even in production! This "remapping" feature can even be done on a per-request basis, allowing you to route and test services on the fly! Check it out.

No comments:

Post a Comment