Voice of the DBA

Tag: DevOps

  • Big Companies are Improving with DevOps

    One of the comments I’ve often heard from people that work in IT and haven’t adopted DevOps is that the principles and changes required won’t work at their organization. Quite a few people think that only small, new companies, like Flickr and Spotify can use the ideas. Plenty of others look at only high-tech, progressive companies like Amazon and Facebook able to change.

    That’s not true.

    In fact, there are four Fortune 500 companies using DevOps, including a large (though young) bank, Capital One, and another, older one, WestPac. I’m not sure anyone would consider American Airlines or Hertz to be small, agile companies, though certainly they are in highly competitive industries and need every advantage over their competitors that they can get. I suspect that is the driving reason for many of these companies to adopt fast, quick software development. They can’t afford to have an idea take months to implement.

    Those companies aren’t like yours? What about Maersk or Nationwide? Ticketmaster? Maybe Norstrom (and a few more)? I actually had the chance to speak with a number of Nordstrom employees that had taken a POC concept for the mobile group and proved that DevOps has value. From there, almost the entire IT department, hundreds of employees in groups from internal IT to mainframe to web, all have adopted various types of DevOps processes, starting with value stream analysis. Over a few yeasr, they have dramatically transformed their delivery of software. When someone in the business proposes an idea or need, it used to take over 6 months for something to get deployed. That’s down to a couple of weeks, and it’s released in a true, get-something-useful-to-the-customer fashion. This isn’t alpha or beta software, but a basic item that can be used and is then grown and changed according to customer feedback on a daily or weekly basis.

    The transition to DevOps really requires some belief and understanding of the ways in which you can deliver better software, faster. This requires some slow growth, which seems crazy, but the the cultural changes take time, and even the technology tools you choose, require some patience, trust, and experimentation from your technology staff. While it might take months or even a year to get a DevOps process working well and one you’re comfortable with, the gains grow and grow over time.

    Even if you don’t believe in DevOps now, why wouldn’t you try to get someone in management to set up a proof-of-concept and build something. It’s a small investment, that could have huge payback with limited risk.  You’ll learn a lot and can then decide if it helps you delivery value to your customers in a better way. And if you do adopt DevOps, don’t forget to include the database in your process.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Building a Database DevOps Process at the Data Platform Summit 2017

    I’m heading to India this August for the Data Platform Summit 2017. I am honored to have been selected to deliver a pre-conference seminar called “Building a Database DevOps Process”, where I’ll walk through the way in which you can include your database alongside application code and deploy it smoothly to various other environments, such as test, QA, UAT, Beta, Staging, Pre-prod, etc.

    DPS2017_Logo_Website

    If you are going to be in Bangalore during the middle of August, register for the DPS and come see my, or another, pre con as well. There are some great ones.

    This will be my first trip to India and I’m looking forward to it. Actually my whole family is looking forward, as I’ll be taking a week or so vacation before the conference to travel with them before I spend a week at work. I should be acclimated to the time change by the time the conference starts, which is good. I’ve got customer training also scheduled, so a busy August for me.

    Now to get a Visa and inoculations. Hope to see you there.

  • Why DevOps? Employee Satisfaction

    DevOps is being embraced by more and more companies, but still a minority of organizations that perform software development. There are plenty of software developers, project managers, and operational staff that are comfortable with their own process, even as they may struggle to produce software for their customers. I think DevOps is a better way to build software, and today I want to look at a benefit beyond faster releases. Today, let’s talk employee satisfaction.

    The State of DevOps report shows that companies who have implemented a DevOps process have more engaged and happier employees. According to the eNPS (e Net Promoter Score), the employees are more likely to continue to work there, and recommend the company to their friends. That endorsement of the organization comes with two benefits. Employees are more productive, and they bring other good employees to work. After all, how many employees recommend someone they don’t want to work with or don’t think can do the job?

    More deployments, easier deployments, the ability to get your code used by customers while you still remember how it works. These are the keys to helping employees enjoy their jobs. When employees are more engaged, and when they are satisfied with their jobs, they work in a more focused manner, trying to ensure their work produces results that help others in the company. In other words, more valuable code.

    DevOps isn’t new; it’s a name given to a number of productive, effective practices that the best software developers have been following for years. The idea of DevOps is being more and more widely embraced, resulting in better software, along with happier employees.

    Steve Jones

    The Voice of the DBA Podcast

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

  • DevOps Isn’t Perfect

    I saw a post recently from Grant Fritchey, Help Me, Help You, Deliver DevOps. In it, Grant shows that DevOps isn’t making developers do everything, it isn’t just giving developers more responsibility, and it isn’t developers handling some of the operational staff responsibilities. It’s about getting development and operations to work together. Hence, DevOps, not DEVops, or Dev    ops.

    In the post, Grant also links to some fundamental failures from companies that supposedly have adopted DevOps processes. Companies like Gitlab and Amazon. There are plenty more examples, which certainly make some people question whether DevOps is better than other methods of building and deploying software.  How are the VSTS issues different from the Knight Capital debacle?

    In some sense, they aren’t. In many cases, we’ve had a software issue that affected customers. People were upset, services weren’t delivered, and it’s entirely possible that revenue was lost. However, one of the things that I think differentiates DevOps is that developers and operational staff can troubleshoot and determine a root cause much quicker. Since the entire commit, build, test, release pipeline is instrumented and documented, your staff can quickly determine what new items might have caused an issue. If it’s not a new item, they can also quickly determine if that’s the case.

    However, once you’ve placed your system in production, DevOps doesn’t ensure that your HA (High Availability) or DR (Disaster Recovery) preparations are adequate. Those are still the responsibility of your Ops staff, but by using DevOps, and storing configuration as code and provisioning your systems in all environments the same, hopefully you’ve taken advantage of this to actually ensure you have tested some HA or DR features in an environment outside of production.

    However, DevOps isn’t prescriptive advice. DevOps isn’t a particular process or a tool that you use or install. DevOps is about learning and improving over time. For different companies, this means you’ll be at a different stage in your DevOps maturity than other companies. Some have complete deployment processes, but limited instrumentation and monitoring in production. Some have tons of data and deploy code perfectly, but no HA. Some have great HA, but poor deployment processes.

    DevOps is about constant improvement and advancement to make your software development (Dev) and deployment (Dev and Ops) and monitoring/management (Ops) better over time. This might not prevent human error, or even code bugs, but DevOps should mean you make fewer mistakes, less often, and learn from them to avoid repeating those issues.

    Steve Jones

    The Voice of the DBA Podcast

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