Jon Sapyta
My feedback
5 results found
-
57 votesJon Sapyta
supported this idea
·
-
101 votesJon Sapyta
supported this idea
·
An error occurred while saving the comment -
138 votesJon Sapyta
supported this idea
·
-
140 votes
An error occurred while saving the comment Jon Sapyta
commented
We've found when there is a sudden burst of activity that takes Atlas to 100%, the autoscaling fails because it relies on there being excess capacity to do the autoscaling, so scaling fails. Then you need to call Mongo support and have an engineer intervene. Exactly the situation that scaling is meant to prevent. They need to change this architecture, and also make scaling more configurable so you can take into account what you know about your workload.
Jon Sapyta
supported this idea
·
-
19 votes
An error occurred while saving the comment Jon Sapyta
commented
It would be great to have an OOTB connector for ServiceNow, so each customer doesn't have to role their own custom solution.
Jon Sapyta
supported this idea
·
We also have this issue, where if the primary gets loaded, scaling doesn't have capacity to scale, and it just gets stuck, and you have to call support while your application is effectively down or struggling. We've just scaled up our instances to overcome this, but it's a massive waste of resource to keep them scaled up so much because scaling can't respond under load and isn't configurable. We've started to look at other DB solutions with more effective scaling.
It's unbelievable that 'dark mode' for the UI is being worked on, while critical issues with scaling that cause outages are not.