Voice of the DBA

Tag: DevOps

  • Delaying Patches is Problematic

    I was listening to a DevOps podcast from Josh Corman, of Rugged Software. Rugged Software aims to improve security by asking developers and sysadmins to adhere to their manifesto, which recognizes both the importance of software in the modern world, as well as the problems associated by not properly securing and patching software. These are duties that both developers and administrators should perform in their respective roles.

    The goal of the Rugged Software is to promote best practices and constant vigilence to create and deploy secure code, and ensure that software installations remain that way. This isn’t a security state, but rather a process. A way to approach software development, deployment, administration, and maintenance to improve the security of our computer systems. This maps nicely to a DevOps approach to software development, with a focus on security. The ideas here include not just patching, but fixing underlying issues, learning from mistakes and from other organizations, improving the skills of their developers and administrators. This is a holistic approach to ensuring security.

    This not only includes the software we write, but also the software products, platforms, libraries, etc. that we use. For many of us, this means the Windows host OS, the networking software and connections, http servers, vendor .NET libraries, and more. This also includes database software of all sorts, whether you use an RDBMS like SQL Server, perhaps a search service like ElasticSearch, a caching database like Redis, or some other NoSQL data store.

    The idea is that we not only code securely, but also make sure we patch our software. That’s a problem in many cases. In fact, MongoDB has had a security issue for the past few years that was well publicized but still affects many installations. Far too few people have patched their MongoDB databases, and it’s a problem. Data is exposed to anyone on the Internet, and it’s likely someone is taking advantage of this to access the bits. In fact, many hackers exploit flaws in software for which patches are often available. The updates just haven’t been deployed.

    Patching software is a challenge, and it seems that there is no shortage of ways in which companies deploy updates. Microsoft is pushing automatic patches. Some applications make these optional. Some apply changes in the background, some require downloads. If you use a service, then patches are seamless, but the changes may break functionality or force a new workflow on the user.

    Ultimately I think that we, as an industry, need to mature with the ways in which we patch software. Customers and clients should demand better, and the impact of applying patches should go down. Quality should go up, and while that has happened with some companies, I think we need better patterns and practices that are taught and adopted by more developers. Perhaps more people sharing their techniques, templates, and practices will help others become better at building and managing our software updates.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 5.5MB) podcast or subscribe to the feed at iTunes and Libsyn.

  • Interviewed on Channel 9

    Had a quick interview at Microsoft on Channel 9 last month, and it’s now live. Enjoy.

    https://channel9.msdn.com/Blogs/vsppstories/Including-the-database-in-your-DevOps-pipeline/player

  • Held Hostage by the Database

    Your database platform will constrain and limit the flexibility you have in evolving your software. It doesn’t matter which platform you choose, which type of database, or even the format for your data. At some point, you will be dealing with legacy data in some legacy schema or structure, and your development, and certainly deployment, will be slowed or impacted. Face it, the need to maintain state for your data is an impediment in a relational system. In a NoSQL or other store, the need to maintain code in your application that can interpret your data might be the issue over time.

    That’s not to imply this need to maintain state has to slow your development. On the contrary, there are many companies that find themselves moving quickly, able to make database changes on a weekly, or even daily, basis. There are multiple tricks and techniques for managing change, but ultimately the real secret is having a process that computers can follow and your developers adhere to.

    In other words, having some automation.

    Certainly you need to program the automation, or use tools like those from my employer, Redgate Software, but it doesn’t matter which what process you use. The process does need to be flexible because it will change over time. I can almost guarantee that the way in which you need to deploy code to the database in your environment will change over time. It has to as the needs and requirements of your business change.

    This means the way in which your developers need to build, test, and package changes will need to grow and evolve as well. While every developer and sysadmin needs to work within the process, the process does also need to be flexible as needs change. That isn’t to imply that your process should change every week, or for every deployment, but it will need to do so periodically, and hopefully, rarely.

    There are techniques to make deploying database changes easier on the developer and system administrator, but there are no magic techniques. All the tools I’ve encountered, including those from Redgate, do the same types of things you’d do manually. They just save you time and stress by helping you get set up and easily maintain your deployment tasks over time.

    Whether you use tools or not, please don’t allow the database to hold back your software development. Learn new ways to alter your database. Learn the ways to make changes to large tables. Learn how to avoid downtime. Just learn to design database changes in a better way and then automate the deployment of those changes.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 3.6MB) podcast or subscribe to the feed at iTunes and Libsyn.

  • DevOps at Microsoft

    I’ve been watching Microsoft for quite a few years, with my career being tightly intertwined with the company for 25 years.  I’m amazed by the way the company has changed in the last five years. It’s probably been longer than that, but from the outside, the last 5 years have been surprising. Certainly the way Microsoft produces software is a process worth studying by almost any organization with developers. There are some scale advantages Microsoft has, and their mission is to reach and touch people at a level far beyond what many of us deal with, but there are lessons to be learned.

    There’s a great piece that shows some of the ways in which Microsoft is practicing DevOps in their own software development. I like that the focus isn’t just that developers do more, but that operations staff are involved in working closely with the development teams. In fact, there’s a quote I like that notes in addition to technology changes and habits, ” we found that the organizational changes and cultural shifts required to embrace these practices have been just as significant.”

    As I talk about smoothing the database development pipeline and creating efficiency in the process, I want people to be aware that cultural change is required. My employer, Redgate Software, can sell you tools that solve the technology challenges, but if you don’t change the way you build software in your culture, with your staff, the tools don’t help. At best they make a few tasks easier for developers, but you will still have issues releasing your software consistently on your schedule, whatever that may be.

    There is also the emphasis on developers deciding when to release. In Microsoft’s domain, this probably works, but not likely for many line of business applications in organizations. However, the focus should be getting changes to customers quickly after development. The sooner they see features, the sooner they can provide feedback on whether the software works as expected or changes are needed. This quick feedback also means that developers have the architecture and flow of the code in their recent memory. Always a recipe for smoother continued development and quicker bug fixes.

    Testing isn’t emphasized much, though I think as developers become more accountable, and they can get changes to customers quicker, they’ll start to want automated testing that allows them to check for regressions, as well as ensure requirements are being met. Microsoft has the advantage that many of their internal teams can actually use the end product, something that isn’t always easy for those of us in other industries.

    DevOps works. The principles are sound, and it doesn’t matter if you’ve followed the principles for decades (maybe under another name) or just started a new process by asking for more coordination and collaboration from your teams. Learn to build a coherent system with your developers and operations staff, throughout your software development process, and your whole organization will benefit.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 4.6MB) podcast or subscribe to the feed at iTunes and Libsyn .