Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: dynamodb support #985

Closed
rippling-jon opened this issue Apr 16, 2024 · 2 comments
Closed

proposal: dynamodb support #985

rippling-jon opened this issue Apr 16, 2024 · 2 comments

Comments

@rippling-jon
Copy link

rippling-jon commented Apr 16, 2024

What version of micromdm are you using?

1.12.1

What micromdm command did you run?

N/A

What did you expect to see?

N/A

What did you see instead?

N/A

Hello! my use case is deploying microMDM in a multi-process environment. I know microMDM currently has a single process architecture and I would love to chat more about the benefits of being able to horizontally scale microMDM for better availability and throughput.

One aspect of being able to deploy microMDM in a multi-process environment is support for a shared database. I see that some work is underway to support postgres. If I were to contribute to fully support DynamoDB as a database option for microMDM in lieu of BoltDB, would that be something that could get merged in?

I would like to raise DynamoDB as an option because it is also a schemaless key-value database, is fully managed, has a good availability story, and has integration with other features that would be helpful in a multi-process environment, like DynamoDB change stream.

I would also want to get some guidance on how we would want the operator to configure which database to use. i would imagine we could add some flags to micromdm serve like:

  • -dynamodb by default set to false to let micromdm know to use dynamodb and not bolt / postgres
  • -dynamodb-config-table=ConfigTable to configure the dynamodb table name for the Config database
  • -dynamodb-device-table=DeviceTable to configure the dynamodb table name for the Device database
  • ..etc for other tables

Since DynamoDB depends on AWS credentials, we would then look for credentials in the usual places as described in aws-sdk-go docs, and also the AWS_REGION environment variable.

@jessepeterson
Copy link
Member

Hello! Please take a look at https://micromdm.io/blog/introducing-nanomdm/

I'll respond more directly to your questions a bit later. Thanks!

@jessepeterson
Copy link
Member

Hello again!

As I mentioned above the future path for this development is going to be NanoMDM. It is already intended for horizontal deployment and has built-in MySQL and PostgreSQL backends. Any feature like this for MicroMDM v1 isn't likely to be merged simply because the project and developers don't have time to support it and continuing to invest in the existing code base doesn't represent the direction we'd like to go. In fact as noted in the above blog post we had to close #558 because of these reasons.

You are encouraged to migrate to NanoMDM. If you have an installed base, integrations, and/or enrolled devices already you should know there are also migration tools available to assist migration.

But perhaps most of all you should know this work was already started for NanoMDM by @jrennichjc under his Dynamo branch of NanoMDM. There was even a conference talk at MacDevOps::YVR about it.

Now the question might be: would we consider adding this to NanoMDM? And the answer is: maybe, but it'd be a tall order. It would take a significant commitment of support, probably backed by an organization. For example there is a contribution of MongoDB in micromdm/nanomdm#57 (and NanoDEP, for that matter) that has not been merged — mostly due to supportability concerns (but also growing library/dependency concerns).

Hope that helps. Please join the Slack #nanomdm channel so we can discuss further if you'd like! (Or perhaps open a NanoMDM discussion thread in GitHub). Cheers!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants