search

AdrianHu99 / NOTES

0 stars 0 forks source link

Operationalizing Microservices #60

Open AdrianHu99 opened 5 years ago

AdrianHu99 commented 5 years ago

https://www.infoq.com/minibooks/operationalizing-microservices/

AdrianHu99 commented 5 years ago

it’s quite possible to have a microservice you haven’t touched in several years, and no one doing the troubleshooting has any idea how it works. When that happens, you’re really relying on two things:

  1. does the monitoring tell you there’s a problem?
  2. does the documentation give you what you need?
AdrianHu99 commented 5 years ago

From the book ACCELERATES:

They break software delivery performance into four metrics:

  1. Lead Time: time it takes to go from a customer making a request to the request being satisfied.
  2. Deployment Frequency: frequency as a proxy for batch size since it is easy to measure and typically has low variability. In other words: smaller batches correlates with higher deploy frequency.
  3. Mean Time to Restore (MTTR): given software failures are expected, it makes more sense to measure how quickly teams recover from failure.
  4. Change Fail Percentage: a proxy measure for quality throughout the process
AdrianHu99 commented 5 years ago

you can’t experiment when you’re only doing 12 releases a year. The feedback cycle isn’t fast enough. Because so many changes are deployed together, you can’t tell the impact of one thing or another.

AdrianHu99 commented 5 years ago

Everything’s over network traffic now and things are unreliable. All your transactions being distributed means that things can partially fail or partially succeed. You’re hoping for eventual consistency, but quite often you end up with just inconsistency that you have to fix up somehow

AdrianHu99 commented 5 years ago

As soon as you are coupled to another team, you slow down