-
Notifications
You must be signed in to change notification settings - Fork 6
Document BYOC #119
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
Document BYOC #119
Conversation
f8f81da
to
96083f4
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See detailed comments.
Also, we should replace all references to "AI assistant" with "AI agent" - e.g. in https://docs.defang.io/docs/intro
| Feature | Development | Staging | Production | | ||
|-|-|-|-| | ||
| Build Resources | Builds will be run with 2x vCPUs | Builds will be run with 2x vCPUs | Builds will be run with 4x vCPUs | | ||
| Databases | Defang will provision resources optimized for burstable memory | | Defang will provision resources optimized for production | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we say something about behavior on 'compose down'?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. I think we should create a Databases
concept topic where we can discuss the subtlety more carefully 👍
docs/use-cases/use-cases.md
Outdated
## Data Stores | ||
|
||
Defang is not a good fit for data stores like databases, caches, and message queues. These types of services are designed to be long-lived and to store data. Defang is primarily designed for stateless workloads, and it's not a good fit for stateful workloads: if a container is replaced, all the data in it is lost. You could probably coerce a data store to work in a stateless environment with certain replication strategies, but it's not a good fit. | ||
Defang is not a good fit for data stores like databases, caches, and message queues. These types of services are designed to be long-lived and to store data. Defang is primarily designed for stateless workloads, and it's not a good fit for stateful workloads: if a container is replaced, all the data in it is lost. You could probably coerce a data store to work in a stateless environment with certain replication strategies, but it's not a good fit. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not accurate. We should mention the issue with stateful services and then point to Defang's support for managed storage options - https://docs.defang.io/docs/concepts/managed-storage
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Prakash-Sundaresan I think you're right. This is no longer accurate because we support managed storage. I do think we should have a place where we caution people against trying to run unsupported data stores until we support volume mounts, though. Like, at the moment people shouldn't be using Defang to run Mongo, or ElasticSearch or anything like that.
…fang-docs into jordan/launch-prep
b202a79
to
3f16324
Compare
Changes in this PR