Screaming in the Cloud Episode 23: Most Likely to be Misunderstood: The Myth of Cloud Agnosticism
It is easy to pick apart the general premise of Cloud agnosticism being a myth. What about reasonable use cases? Well, generally, when you have a workload that you want to put on multiple Cloud providers, it is a bad idea. It’s difficult to build and maintain. Providers change, some more than others. The ability to work with them becomes more complex. Yet, Cloud providers rarely disappoint you enough to make you hurry and go to another provider.
Today, we’re talking to Jay Gordon, Cloud developer advocate for MongoDB, about databases, distribution of databases, and multi-Cloud strategies. MongoDB is a good option for people who want to build applications quicker and faster but not do a lot of infrastructural work.
Some of the highlights of the show include:
- Easier to consider distributed data to be something reliable and available, than not being reliable and available
- People spend time buying an option that doesn’t work, at the cost of feature velocity
- If Cloud provider goes down, is it the end of the world?
- Cloud offers greater flexibility; but no matter what, there should be a secondary option when a critical path comes to a breaking point
- Hand-off from one provider to another is more likely to cause an outage than a multi-region single provider failure
- Exclusion of Cloud Agnostic Tooling: The more we create tools that do the same thing regardless of provider, there will be more agnosticism from implementers
- Workload-dependent where data gravity dictates choices; bandwidth isn’t free
- Certain services are only available on one Cloud due to licensing; but tools can help with migration
- Major service providers handle persistent parts of architecture, and other companies offer database services and tools for those providers
- Cost may/may not be a factor why businesses stay with 1 instead of multi-Cloud
- How much RPO and RTO play into a multi-Cloud decision
- Selecting a database/data store when building; consider security encryption
Links:
.