Puppet announced Puppet Comply, a new product built to work with Puppet Enterprise aimed at assessing, remediating, and enforcing infrastructure configuration compliance policies at scale across traditional and cloud environments.
In today's world of software development, it's all about DevOps. One of the hottest buzzwords of the decade, DevOps is rapidly gaining popularity among organizations of all sizes. According to Puppet's 2018 State of DevOps Report, more than half of organizations have a dedicated DevOps team to help them better implement agile strategies, accelerate release cycles and ensure continuous development.
However, databases have a habit of holding DevOps back. Known for being archaic and stagnant, they often seem like the antithesis of DevOps, which is everything but. To obtain the type of flexibility developers want in their release cycles, they need to move with as few moving parts as possible.
When buying a database, most assume that they are owning one single piece of software. Most times, however, only after they have authorized the final payment, do they realize two databases were purchased – sometimes even three. Most databases require third party plugins to enable basic features like a GUI, text search, or even aggregations. In some cases, even before you attach a third-party plugin, there are already foreign components inside the database that were integrated. Of the more than 400 databases out there, most will look to third-parties to fill gaps until their product has fully matured.
When utilizing multiple databases, all these moving parts can wreak havoc on the development cycle. More testing will be required, tech support will constantly be on the fritz and there will be a never-ending tennis match of companies pointing the finger at each other when it comes to fixing plugin glitches.
In the face of growing vendors, offerings and solutions, finding a single database that best works with your DevOps strategies can be difficult. While there isn't a one-size-fits-all solution, those looking to upgrade their database for agile production should evaluate the following-characteristics:
At what rate do you need to release application updates? While it could be only a matter of days, weeks or years, it's important to ensure the database is equipped with the right technology and features to enable users to release their next version consistently. When using several different software providers, it is harder to ensure that consistency; however, when dealing with only one software provider, it takes less time to have your database ready to go live.
Once live, databases should require very little maintenance and "babysitting." A good unattended database is one where you can use it for years, and be able to measure the total amount of downtime in hours. Over those years, you will inevitably use new versions of both your application and your database. These upgrades shouldn't require you to touch the database at all.
Thanks to DevOps, development teams are able to push out more updates that can in turn attract new users and ensure current users will come back for more. However, more users, and ultimately data, means you'll need to scale out often. Uniform components can react to such changes in a less disruptive way, letting you expand without slowing down.
New code changes the type of data you are working with as well as how you work with it. As the scale and type of data today's applications are working with continue to evolve at an eye-popping pace, users need a database that won't move in two opposite directions when faced with the task of processing new information.