With microservices, the production version of their service would conceivably be stable. It moves the contract from the repo to the state of production services.
181 karma · joined December 12, 2013
With microservices, the production version of their service would conceivably be stable. It moves the contract from the repo to the state of production services.
When colleagues, whose compensation is as wildly out of proportion to their needs as mine is, complain that they're entitled to more, it's at best a negotiating stance and at worst a black hole of insatiable greed.
Obviously this is some game theory mojo, and we'll never get everyone on board with it, but imagine for a second a world where everyone isn't vying for "more", but for "enough".
In the zero sum game we have here, compensation becomes a moral issue.
Inviting Disaster: Lessons From the Edge of Technology: https://www.amazon.com/gp/product/0066620821
These ebikes are a clever hack. In China they skirt motorcycle laws. In the US they can make use of bike paths. You can make good time and your commute is generally the same duration regardless of traffic. At least, that's true in Silicon Valley.
Last I checked (a few years ago) pedaling the ebikes is like pedaling a tank. Batteries and motors a heavy bike make. So you're using the motor and there's not a lot of cardio happening.
I ride my bike because I want to live longer/better. I don't think you get that with these, but there's definitely a niche for them.
This is years old. Am I missing why this is newly relevant?
I implemented something similar with puppet/mcollective/SQS years back. Poor man's service discovery. Here are some other options that, if you can handle the complexity of running Zookeper (or similar), are probably a bit cleaner:
http://jasonwilder.com/blog/2014/02/04/service-discovery-in-...
Taking opportunity to clarify what we're talking about is just good communication.
> Crucially however, a second software bug in the management software did not propagate the canary step’s conclusion back to the push process
I'm sure the devil is in the details, but generally speaking, these are 2 instances of critical code that gets exercised infrequently, which is a good place for bugs to hide.
The thing that fixed the last problem doesn't always fix the current problem.
http://www.davidbyrne.com/archive/art/books/bicycle_diaries/
While I agree with the gist here (heed warning signs, proactively preempt failure), there are literally hundreds of "fishy" things, many/most of them low impact, that I could investigate on a given day, and my time is bounded.
At the semi-formal dance of distributed systems, meandering investigation should be chaperoned by ruthless prioritization.