Software-Defined Infrastructure

SDI performs the task of setting up individual hosts, clusters of hosts, and even global-scale service platforms with only a set of scripts. The technology enabling most of this power came with advances in cloud computing, but the market is now so dynamic that tools and techniques exist for using SDI in cloud, on-premise, or hybrid deployment situations. These deployments can include components of every capacity and at every price point. In many cases, several types of storage are available, ranging from the very fast and expensive to the slow and inexpensive. Resources can be made available instantly for a few tenths of a second or might be reserved or purchased in anticipation of years of continuous operation.

DevOps and Serverless Architecture

System administrators are enabling DevOps to do much of the work done previously within the sysadmin domain. The combination of modern DevOps tools with SDI is a particularly potent way to expedite delivery value to stakeholders.

Teams can apply modern DevOps tools that largely automate this setup of services that support the needs of several stakeholders simultaneously. Security, privacy, audit, high availability, disaster recovery, and other features can be systematically built into platforms as they are created. Serverless architectures allow systems to exist in nascent forms that consume virtually no resources until service is required. Developers tracking these technologies will be able to deliver capabilities previously unachievable or impractical.

Storage Tiers

Does the application store offer easily segmentable tiers of data storage with varying requirements (i.e., fast for the newest and inexpensive for the archive)? If your data is sizable and your data management tools can direct the appropriate data to the right storage, you can save your organizations large sums over time by finding a tool that supports this and by helping configure the tool properly. Data stores that support this functionality save time and money compared to having to build such capabilities into application code.

Architectural Simplicity

The more components there are to a system, the more things can go wrong. Polyglot persistence has the advantage of providing the best tool for each part of the job, but also the disadvantage of being a complex architecture. Each component of that architecture requires administrator skills, hardware resources, and maintenance. In addition, combining results from different storage engines needs to be done in application code, instead of concentrating data management in the database. Multi-model databases have the ability to simplify the architecture while still providing the broad range of capabilities required by modern systems.

Considering a Multi-Model DBMS

System operators pride themselves on deploying and maintaining robust systems. If an application calls for multiple models of data, we now have a decision to make. If we choose to deploy a polyglot storage system, we will need to give the deployment and maintenance aspects special consideration. We should at least consider a multi-model DBMS for the reasons just described.

Let’s think about the process required to install and scale up or scale down your application. Could we hand the process to an experienced system administrator, and would they be able to complete the process without help from us or our team?