RCA Revisited: The Valid Reasons for Root Cause Analysis
In a previous post about the shift away from Root Cause Analysis (RCA) due to the increase in microservices implementations. It’s much more than just a microservices deployment that will change the way that we operate our application infrastructure. In the article, I actually referred to a distributed application design using AWS infrastructure.
The reason that we are revisiting this article’s concept is that it triggered some very interesting activity on Twitter and through conversations with many folks in the IT community. It felt like a little clarification was in order.
RCA Matters, but in a Different Way
Abstractions create very interesting ways by which we can care less about what is underneath them. They become a logical boundary to something below or above. We are able to consume those resources using APIs without having to worry about how content is created/stored/managed behind that abstraction. This brings up some interesting challenges at the same time as it creates simplicity.
If something fails within the database platform which is hosted in a Database-as-a-Service environment, what is our recourse? We still have do some RCA in the event of loss of service:
Read the entire article here, RCA Revisited: The Valid Reasons for Root Cause Analysis
via the fine folks at VMTurbo!