4 ms·

I noticed that in the "Impact on other services" bit, that CloudWatch and Console were affected, becasue they were dependent on DyanmoDB. Now, I don't pretend t

I noticed that in the "Impact on other services" bit, that CloudWatch and Console were affected, becasue they were dependent on DyanmoDB. Now, I don't pretend to know DyanmoDB to well, but it seems to me that having your monitoring application dependent on one of the things you would be monitoring is a strange circular dependency. Would it have been wiser for Amazon to implement a completely separate instance of DynamoDB for service offerings that depended on it? Or is this just simply cost ineffective? Help me understand, thanks. =)

eli 11y ago
And then what? Set up another set of monitoring tools to watch this new DynamoDB instance that's only used for monitoring and console?
zwily 11y ago
It sounds like most of the remediation is "we'll make sure this service keeps working even if Dynamo is down". It's telling that so many services are relying heavily on Dynamo now. If anything, this event just makes me like it more. (I have several things built on it).
_alex_ 11y ago
CloudWatch is a monitoring service that AWS offers publicly. It is different from the monitoring service that AWS services use internally. source: was on an AWS service team for several years
- berkay 11y ago
  It's still a problem even if it's not the internal monitoring system. Customers use CloudWatch to detect problems with DynamoDB and get notified. This dependency means customers may not get notified if CloudWatch does not work as expected due to a DynamoDB problem.
  - sharpy 11y ago
    There are different forces at play. On one hand, one can design a service with minimum dependencies to survive other services' outages, but that means duplication of effort and increased cost, as well as slower delivery of features. Or one can focus on adding value. It seems though, from the update, that CloudWatch is going to have some sort of caching for most recent data.
- ckozlowski 11y ago
  I follow. In this case though, I was thinking of the customer's monitoring tools. Their first action would be to try a diagnose themselves. But good to know! Thanks!

eli 11y ago

And then what? Set up another set of monitoring tools to watch this new DynamoDB instance that's only used for monitoring and console?

zwily 11y ago

It sounds like most of the remediation is "we'll make sure this service keeps working even if Dynamo is down". It's telling that so many services are relying heavily on Dynamo now. If anything, this event just makes me like it more. (I have several things built on it).

_alex_ 11y ago

CloudWatch is a monitoring service that AWS offers publicly. It is different from the monitoring service that AWS services use internally. source: was on an AWS service team for several years

berkay 11y ago
It's still a problem even if it's not the internal monitoring system. Customers use CloudWatch to detect problems with DynamoDB and get notified. This dependency means customers may not get notified if CloudWatch does not work as expected due to a DynamoDB problem.
- sharpy 11y ago
  There are different forces at play. On one hand, one can design a service with minimum dependencies to survive other services' outages, but that means duplication of effort and increased cost, as well as slower delivery of features. Or one can focus on adding value. It seems though, from the update, that CloudWatch is going to have some sort of caching for most recent data.
ckozlowski 11y ago
I follow. In this case though, I was thinking of the customer's monitoring tools. Their first action would be to try a diagnose themselves. But good to know! Thanks!