For many developers, Docker is a frequent friend. Some even turn to Docker to run their database systems – applications are safe in containers, containers usually are lightweight, and generally, containers allow Devs to bundle all the software they use into “boxes” called Docker containers. But how are they compared to other alternatives?
Running Databases in Containers
Running software in containers is generally mainstream, but what about databases or database servers (for example, SQL Server, MySQL, Oracle, PostgreSQL, MariaDB)? Have you ever heard of a dev running his databases in containers? Most likely not, because doing so requires extra resources and dedication toward the craft of containers. To run your databases in a containerized environment and utilize database monitoring properly, here’s what you must know:
- Containers let you approach your databases as an on-demand utility (each application can have its own database.)
- Containers let you have less “mess” on your machines – you always know what’s where.
- Multiple containers can run on the same OS.
Running databases in containers is not very easy, though: if we think of containers as a lightweight alternative to VMs, we will quickly realize that containers, in this case, would let us “engulf” our applications in containers that each might run different operating systems. In the case of databases, that most likely would look like each DBMS is “encapsulated” into its own container image. Don’t forget that when dealing with Docker, we’d usually need .yml files that would define the services our containers run, etc. Everything looks pretty complex, doesn’t it? How do we decide whether we need that in regards to databases? It might help to look at alternatives before answering this question.
Alternatives to Containerization with Databases
The most frequent alternative to containerization is simply running a database on a standalone server. This process is quite a lot easier than running databases on containers, and it can easily be accomplished both locally and in a live environment.
On a local server, you need to spin up WAMP or its alternative if you’re using Linux, and when you’re in a live environment, buy access to shared hosting, a VPS, or a dedicated server if you’re building services requiring more hardware resources, and you should be good to go. In many cases, databases will even come pre-installed to the services you use.
What’s Better?
If you ask a developer or even a database administrator which option is better – should you run your databases on Docker or a more “natural” environment involving servers – you will probably hear an answer like “Don’t bother with Docker.” Want to know why? Running databases in a containerized environment (using Docker) isn’t a very smart choice due to complexity – Docker might bring less clutter.
Still, it will certainly bring more headaches just by the way it’s structured. Running your databases on Linux is the traditional and straightforward way to get on the web. When monitoring is concerned, everything can be set up in a more “traditional” fashion when containers don’t get in the way. Look at dbWatch: define your connection details, and you’re done! Isn’t that awesome?
After your database instances (of whatever database management system flavor you’re using) are imported into dbWatch, they then could be monitored. In a span of minutes, a bunch of expert-made database jobs could be run:
With a wide variety of database jobs, dbWatch proves to be a perfect choice for many business owners and database administrators – just a couple of clicks, and your database issues will be solved.
There’s no need to reinvent the wheel and run databases in a containerized environment using Docker: in fact, not many people run their databases on Docker at all – there’s a good reason for that: doing so is pretty complex, even to advanced database administrators. In many cases, database administrators are not sysadmins, so the traditional way is preferred here. Did we talk about junior developers and DBAs? Docker is not a good choice for them either: in fact, it might steer them away from development altogether, not even talking about choices
Summary of Running Databases: Docker vs. Alternatives
As far as containers are concerned, they certainly have their own upsides, but running databases inside of them isn’t one of them.
Running your databases in a traditional, non-containerized way lets you develop and roll out features faster, and you will be able to solve issues faster as well: for example, post a problem you’re having with your databases on Stack Overflow.
Chances are, you will instantly be bombarded with questions like “Why are you using Docker?” “Isn’t the traditional way – a good way for you?” etc., so go with the traditional path instead. Whatever path you choose, remember that there are a bunch of database monitoring tools – and dbWatch is one of them.
Try out dbWatch for yourself with a free 90-day trial.
