AdminAndrew Davidson
(VP, Cloud Products, MongoDB)
My feedback
184 results found
-
24 votes
An error occurred while saving the comment -
12 votes
An error occurred while saving the comment Hi Kaz,
Out of curiosity, did you experience an accidental pause of a production system? One thing we do for termination is require the user to type in the cluster name--that could be something we'd do here but hadn't seen it as quite necessary since Pause is a reversible operation and so we instead protect it with an informational modal and large red button. Knowing that this has not been enough is a valuable data point.
-Andrew
-
23 votes
An error occurred while saving the comment Hi Matthew,
It would be helpful to understand what it is about your application that would benefit from. this. Noting that cross-AZ network hops are generally sub-2ms, single-AZ network affinity is usually reserved for the kinds of applications with more niche latency requirements (where latency trumps availability) like ad serving and high frequency trading.
It would help to understand how you would take advantage of this, what it would mean for your applications, etc. Would you have other application tier instances running in the other AZ in the event of failure of the "preferred" AZ? Maintenance is another consideration--one key benefit of not thinking at the AZ level is you avoid pets and force yourself to be resilient for failures and maintenance.
Thanks
-Andrew -
1 vote
An error occurred while saving the comment Hi Ben,
You can open a help request any time using the lower-right in-UI chat bubble. This service is included for all Atlas customers.
-Andrew
-
11 votes
An error occurred while saving the comment Hi Louis,
Many customers use different Projects for different Teams, but I hear you loud and clear and there are many cases where that's not ideal. Importantly, while the invoice UI shows a handy rollup of usage by Project, if you prefer to do your own rollup along other dimensions like Cluster, you can use the billing API endpoint to pull the raw data: https://docs.atlas.mongodb.com/reference/api/invoices/
Also note that you can download a CSV from the billing UI to do your own rollups without using the API if that's easier.
Longer term we are exploring ways to provide more fine grained visibility, including likely introducing tags that could then be used in a billing context. We actually already have "labels" (key/value pairs) that can be programmatically added to clusters managed via the API but this is not currently part of our UI experience and does not tie into billing -- just mentioning in case it may be useful to you: https://docs.atlas.mongodb.com/reference/api/clusters/
Cheers
-Andrew -
6 votes
An error occurred while saving the comment Hi Louis, You can programmatically pull the activity feed via this API endpoint:
https://docs.atlas.mongodb.com/reference/api/events/ For completeness, note that the not every field in the UI version is accessible via that API endpoint, but the core fields are.Cheers
-Andrew -
1 vote
An error occurred while saving the comment Thanks for the suggestion, Tommaso, we're definitely exploring ways of making MongoDB Atlas easier to plug into external services.
Cheers
-Andrew -
11 votes
An error occurred while saving the comment Hi Eli,
We've gone back and forth on this one: One advantage of our cluster naming has been that the name shows up in the connection string (hostnames) of the cluster, which has convenience benefits. However this makes it more difficult to enable a naming change. If the name were purely a control plane metadata tag, then making the name change would make perfect sense. Still, we will explore options over time.
Can you shed some light on the value/use case of this for you? We know many customers start out with "-dev" or "-test" in cluster names and those may eventually become prod envs--that's a use case that's top of mind for us. Are there others?
Thanks
-Andrew -
6 votes
An error occurred while saving the comment Jaco, would you mind exploring whether you can optimize your cost/performance by spreading the aggregation workload across replicas? That might be a better path forward here.
-Andrew
An error occurred while saving the comment Hi Jaco,
One thing I do want to confirm -- are you leveraging secondaries to round out your aggregation read load, or might you be pushing aggregations exclusively to your primary?
Cheers
-Andrew -
1 vote
An error occurred while saving the comment For what it's worth there is an Org-level setting that you can enable to require all users in your org use MFA. While this doesn't directly address your objective of knowing who doesn't have MFA set, it may help give you peace of mind.
-Andrew
-
2 votes
An error occurred while saving the comment Hi Picon,
While we are likely to introduce the ability to target database users to subsets of Clusters within a Project in the future, we are unlikely to do so for network access management. On the backand, Projects use a Project-dedicated shared VPC for M10+ clusters (per region on AWS and Azurfe, and globally on GCP).
We recommend using different Projects for different environments (Prod vs Non-Prod for example): note that you can restore backups across Projects.
-Andrew
-
2 votes
An error occurred while saving the comment Hi Dan
This is a great idea. While we do not have near-term plans to do something like this, we're definitely thinking about how to provide better end to end CI/CD experiences, and I expect a product manager will likely want to speak to you in the future.
-Andrew
-
80 votes
An error occurred while saving the comment Hi Kremena,
We are working on a long-term (multiple quarter undertaking) revamp to our role based access control system to make it more flexible and less course-grained. While this will not be available for some time, I want you to know that we hear you loud and clear and we are committed to closing this gap.
By the way, as an aside: for customers on an annual subscription we will soon introduce a capability that allows different Atlas Orgs to share a single Paying Org's billing subscription. This would allow you to move Projects to Linked Orgs to ensure that particular Project users can only see usage associated with the Org they're moved to. (Also note that Projects can be moved between Orgs in a purely logical operation). We expect this cross-org billing capability to be launched within a month. It would be good to know if this will help for your use case.
-Andrew
-
7 votes
An error occurred while saving the comment Hi Sergei,
It looks like your last sentence was cut off: can you provide more detail? It's super helpful to understand how you would use this information and why it's important to you so we can think about the problem space holistically.
Thanks
-Andrew -
1 vote
An error occurred while saving the comment Hi Dumitu did you mean to reference or attach some images?
-
25 votes
An error occurred while saving the comment Hi Kasi,
To be transparent with you, we built MongoDB Atlas so that you would not need to worry about lower-level implementation details like maintenance of instance replacements, operating system patches, and software patches.
We've also built many key capabilities into MongoDB and the drivers to ensure that maintenance represents as little a disruption as possible (ranging from auto-failover, to retryable reads and writes, to our Test Failover button for chaos testing).
If maintenance represents a problem for your applications, please open up a proactive support case so that our team can help get to the bottom of what's going on in your application code. We will continue to make investments to reduce the impact of maintenance over time and have introduced maintenance windows as a pressure valve for customers that want to control the timing of rolling maintenance.
-Andrew
-
3 votes
An error occurred while saving the comment Hi Krishna,
The reason there's no Live Migration for Atlas Global clusters today is that we've assumed no one would have created a Global Cluster with a consistent architecture to the model Atlas uses on their own before moving to Atlas:
Can you shed some light on what you're looking to do? We'd be happy to be in touch with you directly to explore options and provide assistance.
-Andrew
-
12 votes
An error occurred while saving the comment Hi Ohad,
I understand that this can be burdensome. However, MongoDB Atlas, being at the data plane, is at the heart of the security concern. It's important to find a balance between appropriate defaults that democratize optimal security practices for most users, with optional advanced security options that only some users need to worry about. Daily login is definitely one that can be debated, but we've made an intentional decision to protect users from a less safe default.
-Andrew
-
4 votes
An error occurred while saving the comment Hi Kasi,
You might be better suited using one of our alert integrations (we support Pagerduty, Slack, and many others).
-Andrew
-
15 votes
An error occurred while saving the comment Have you explored whether you could achieve these same objectives using one of our other named Alert destinations, other than email?
Hi Sylvain,
You may want to take advantage of new functionality that we just launched for annual subscription customers: Cross-Org Billing. See https://docs.atlas.mongodb.com/billing/#cross-organization-billing for more information.
With this capability you can move some Projects to other Organizations (this can be done without downtime via a purely logical backend move), giving you a loose-coupling with authorization-level isolation, but a shared billing subscription.
Cheers
-Andrew