Shaving the Square Peg - Database Automation in DevOps

All of these technology patterns have become mainstays of the modern application landscape. As distributed, self-healing, and automated architectures have come to dominate greenfield deployment models, a new breed of database architectures has risen to complement these highly scalable systems.

Making the most of Microservices, Containers, Infrastructure as Code, and Continuous Integration/Deployment

All of these technology patterns have become mainstays of the modern application landscape. As distributed, self-healing, and automated architectures have come to dominate greenfield deployment models, a new breed of database architectures has risen to complement these highly scalable systems. Unfortunately, NoSQL isn’t always an option for many enterprise IT departments, specifically to the exclusion of traditional SQL systems. Each tool has its well-deserved place in the data-persistence landscape.

More and more organizations are embracing the reality of polyglot persistence, which is simply a fancy way of saying that a DevOps group manages more than a few different flavors of database systems as part of the overall technology stack. Oftentimes, you will see primary customer record applications backed by traditional SQL systems, such as MySQL, MS SQL Server, Oracle, etc., while content and analytics systems are based on top of MongoDB, Cassandra, Hadoop, and the like. In many cases, you’ll see a best-of-breed approach where several of these will be used to back discreet services in the overall architecture. This poses several problems for DevOps practitioners, among which are:

  1. Expertise diffusion
  2. Manual intervention exceptions
  3. Automation challenges

To read more of this article, please sign up to join the SolidFire learning center.

Sign up
request a demo
contact sales