Voice of the DBA

Tag: DevOps

  • Going Cloud Native

    I am constantly surprised at the migration of workloads to the cloud. It seems that many of the customers and clients that I speak with are moving some of their assets to the cloud. Some are moving the majority of their systems, and they are pushing to do this sooner than later, including database assets.

    I ran across an article that noted that while many companies love the on-demand provisioning of cloud resources, they don’t always get improvement in their software performance. In fact, quite a few might experience worse performance, though often not horribly worse. Instead, what they often get is a bit more unpredictable performance, and sometimes a bigger bill, which makes perfect sense. After all, the cloud is really just someone else’s computer, and the one you’re using might have other people doing the same thing.

    To truly embrace the cloud and get the power of the cloud, you do need to consider being cloud-native, which is often a change in how your software is architected. It is also a change in your entire software lifecycle, meaning not just buying DevOps tools or renaming a team, but also embracing the entire way that DevOps works. Not just fast releases, but experimentation, learning, adapting,  testing, and changing how you build and release software. This is also changing how you manage the teams that build software.

    If you think this is just for the Netflixes and Spotifys of the world, that’s not true. Stripe and Capital One are financial companies completely in the cloud. There are plenty of other examples as well, and the successful ones, in all industries, are embracing a new way of building and operating software. Docusign has had a lot of success, and quite a bit with a lift-and-shift to IaaS resources as they continue to build and rebuild their software to embrace the cloud and adopt more PaaS services. They didn’t move systems and expect everything to just get better. They started a journey that they continue to travel every week. The move is a journey, not a quick move, another item that the article points out and many managers forget.

    That being said, not everyone is moving their systems to the cloud. Even organizations that adopt some cloud services, implementing Salesforce as a CRM, might continue to run plenty of systems on-premises. Lots of companies use the cloud for IaaS, but with the architectures and software that used to run in their own data centers. They just moved their  VMs.

    The cloud can be successful in many ways, but you need to understand how you adopt the technology, what capabilities can help, and how limitations can hinder your software. There is no magic bullet, but there are a lot of opportunities if your organization takes advantage of them.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

  • Choosing State Over Migrations

    I ran across an article about state v migration based development for Snowflake. While I think that this article is a bit slanted because the author is building a tool, it does present some good reasons why people worry about migration-based approaches. This article also references a work from Alex Yates on the two approaches.

    Everything we do in relational databases, and in some other platforms like Snowflake, is a migration script. If you run SQL Compare and get the differences, you are generating a migration script. It might contain lots of changes, but it’s still a migration script. I wish I could write CREATE OR ALTER TABLE scripts, but that’s not a part of the SQL specification (yet).

    The concerns in the article are valid, though some are a bit outdated. I know that I am biased a bit as my employer, Redgate Software, sells tools in this area. However, over the years, we’ve supported and worked on both approaches. We do a lot of research, and I get to provide feedback on the good and bad of how we approach the problem. Ultimately, I think the world is very chaotic and we should be as flexible as possible with developers.

    I find that most developers like the state approach. Even if they want to write code themselves, having an easy way to capture the state of objects and keep track of them is useful. When we see a table difference, we want to see a view of the old table and new table in a CREATE TABLE statement: the state approach.

    For deployments, we always need migration scripts, but we want to build them as appropriate for the situation. Cherry-picking out specific changes is often what we need when urgent hot fixes need to be deployed, or a piece of work isn’t tested. In those cases, we might need to deploy some changes and not others, which often require us to put a subset of changes into a migration script(s). That’s a hassle, and these situations are often where we find humans making mistakes.

    Ultimately I prefer state sometimes and migrations others. If I had to pick only one, it would be migrations, but I’d ensure I had a state view of the schema using a tool like SQL Compare. I want to be able to see history and capture changes. in a human-readable format.

    One approach isn’t better, and both have advantages and disadvantages. We are often under pressure to be more like DevOps software developers, adaptive and agile. We can use either state or migrations to do this. The important thing is that your whole team understands the approach we are using and the potential limitations. They also need to work together to smooth out your database deployments.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

  • Improving DevOps Automation

    We use a lot of automation at Redgate. As a company that builds software, we want to ensure that all the changes from our teams get integrated and tested in a timely manner. We have multiple teams on some products, and while we do have regular meetings between them, it can be easy for a developer to miss some update on a change others are making and break something with their own work. Worse, they could cause a regression or security issue, which we work hard to avoid.

    Recently I saw a post from one of our lead software engineers about the build process. While we have lots of pipelines, the general process hasn’t changed in many years. In some sense that’s good, because we focus on building better software, not the process. We don’t change just for the sake of change, or because a new team or division lead likes one tool over another. I’ve seen customers where they move from Jenkins to Azure DevOps because someone in charge “likes one better.” Not a good use of time.

    However, you do need to evaluate whether your process is meeting your needs. In our case, we surveyed lots of developers to get their thoughts on pain points and issues. The build and release process was consistently listed as a pain point, with releases often requiring a dev to manage it from their workstation, preventing them from spending time building software for customers.

    That might be the big lesson I saw in the write-up. We realized that a non-negligible amount of time was being spent by developers on the process of moving bits rather than building the software. This led us to re-examine how things are done. In particular, we looked at the agent OS (Linux v Windows) and containers. Both of these are more viable technologies now than in years past, and they can reduce costs while smoothing the process. As a result, we are developing a general contract that helps us decide how to change our process. This is similar to an API, that doesn’t specify the tool to use, but rather the inputs, outputs, and what the effect should be. From this, we’ll start to help teams move forward is changing their process as we have time.

    The big takeaway right now is that this is pushing us to use containers, which simplify the steps and allow us to easily move from Azure to AWS to on-premises, or really any environment. We can switch builds across different platforms and more easily scale up or down as needed. It will take some time, and some of our software will be more challenging in containers. However, we are also seeing benefits from customers, and at some point, I expect we’ll provide containers for certain functions that make it easier for the end-users of our software to also deploy and upgrade their tools.

    DevOps is an ongoing process. Not a set of tools that you change just because, or a way of building software that matches what another organization does. Instead, it’s learning, experimenting, and evaluating how you can be more effective. Then adopting what you’ve learned and repeating the process. Keep improving, and you’ll find that you can produce software quicker and at a higher level of quality while improving the skills of your engineers.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

  • Enterprise Software

    “I’ll go in the store; it’s built for that.”

    That is a quote from Jessica Kerr, who is a developer. She has a great blog on software development, called The Enterprise Eats Software. It starts with a poor experience for an online order for Lowe’s. Interestingly enough, as I read this, I was starting a home renovation project, but I didn’t have a bad experience, I had a great one. Read Jessica’s blog, and see what you think.

    For my short story, we had contracted for a bathroom project, but we forgot to get some of the fixtures. The contractor came a day early to talk about things, and we realized we needed a shower diverter valve and trim kit. We looked for the trim, which is what was important to my wife, and found a valve to fit it. While the contractor called two local supply houses, I looked at Amazon. The suppliers didn’t have the valve, but Amazon did, noting delivery in two days. I ordered it around 10:30 am that day. It arrived around 11:00 am the next day, a day early and before the existing shower had been demoed.

    That was fantastic. It made me think why would I want to use any service that wasn’t that amazing and quick. I got an email at my desk with a picture, telling me the package had been delivered and showed me where it was. I walked it upstairs thinking that calling multiple suppliers and then driving around town would have been a pain,  not to mention a time sink.

    I don’t often find a lot of large companies do a good job with their software integrating into real world operations. A few do, and apart from Amazon, I’ll say build.com was incredible for us to get a tub and Wayfair got us a vanity very quickly (too quickly, actually). Both have built great systems that not only took the order but updated us and handled the complexities of shipping large items. Not to mention they both had an incredible selection available to peruse easily and quickly. Just finding a place to look at something like a tub in person is incredibly difficult.

    Apart from the retail challenges, just the general experience from many enterprises leaves something to be desired. They just aren’t good at being agile, flexible, and maybe more importantly, constantly improving. They get caught up in some of the hassles, like bureaucracy, power struggles, too many rules, etc. They don’t know how to operate in a flexible, agile, constant change environment.

    I’m reading Project to Product, which in many ways sees a lot of the same problems. Software is disconnected from the goals of the business, and too often there are individuals and processes that get in the way of becoming more effective across teams and partners. BMW is one of the success stories here, and I still think they’re behind Tesla in their industry. They might catch up, and if they do, it’s because they are learning to be a better software company, not a better manufacturer.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.