I got this question in another community I'm part of and think I wrote a pretty decent answer I wanted to share here:
It's a great question to start asking within your organization and it begins with "why would I containerize anything?" - docker has become synonymous (for better or worse) with Containerization. Databases in containers have their advantages and disadvantages, one of the best things about databases in containers is that you stop thinking about the database as the application itself and start thinking of it more as an appliance. Failure recovery, portability, ease of configuration, all of the value that you receive from a container are applicable to a database, but the important wrinkle to consider boils down to - Databases care a lot more about their running state (in memory workload, their persisted data, and their awareness of other members in the database cluster or deployment.
When you mix the 2 it starts to really feel a lot like oil and water, and that's where something like an orchestration platform comes in. How can we unlock what the database is really good at, and what the containers are really good at and make them work together harmoniously?Â
If you haven't answered this question, then containers are likely "too early" for your database deployment. If you have answered this question then you will likely start down the path of cloud native and mass containerization and portability.
That's a long winded answer to say, databases in containers are not an unlocker of performance, an unlocker of portability or an unlocker of convenience, but when leveraged together you can begin doing things that are not possible in VM or bare metal deployments.this is a great Panel discussion that we had at Percona Live Online earlier in the year where some of the biggest names in the business give their opinion on this exact topic!Â
Â
Recommended Comments
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.