Voice of the DBA

Tag: DevOps

  • All In to the Cloud

    I was listening to the fall 2020 GroupBy conference recently and heard Gethyn Ellis note that he wasn’t aware of any companies that were over some age (a decade?), and that had made a 100% move to the cloud. The comment caught my eye, not because I haven’t felt the same way, but because I’d just heard from a company that surprised me.

    During the DevOps Enterprise Summit recently, one of the keynotes was from Capital One. They are a 26 year old company that is focused on financial services, and they said that this year they are 100% in the cloud. They recently shut down their last data center. For a highly regulated company, and one that’s not a startup, that is impressive.

    Almost all customers that I talk with are looking at the cloud in some sense. They might not be looking to move their biggest or most important applications, or even a majority, but they are often looking to hedge their bets, while they continue depreciating or using their on-premises assets for some period of time.

    Not so with Capital One. They have heavily embraced DevOps, flexibility and rapid change in a way that had them open their 8th data center in 2014, only to pivot and look to eliminate that part of their infrastructure. They believe there is sufficient capability, reliability, and perhaps most importantly, security, in the cloud providers. They’ve embraced cloud-first, after an initial lift-and-shift approach for their thousands of systems.

    I don’t know that most companies need to move in this direction, but this does show it is possible, and no matter what your concerns are, there are models of enterprises that have found ways to take advantage of the cloud and that you can look to emulate..

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Azure DevOps–Using Variable Groups

    I was in a webinar recently and saw a note about variable groups. That looked interesting, as I’ve started to find that I may have lots of variables in some pipelines, and I thought this would keep me organized. However, these are better than that.

    When I go to the variable screen for a pipeline, I see this my variables, but on the left side, I see “Variable groups”. If I click this, I see some info.:

    2020-10-21 14_54_57-Release SimpleTalkDB - Pipelines

    The top link takes me to a doc page, where I see this sentence: “Use a variable group to store values that you want to control and make available across multiple pipelines.”

    Now that is interesting. I have been thinking about different pipelines, so having variables that work across them is good.

    To create a variable group, I need to go to the Library, which is another menu item under the Pipelines area. I get a list of groups, of which I have none right now.

    2020-10-21 14_58_23-Library - Pipelines

    When I click the blue button, I get a form with the group properties, and then a variables section below.

    2020-10-21 14_59_06-Library - Pipelines

    I add a couple variables and add some group info. In this case, I want some secret values that are useful across different pipelines.

    2020-10-21 15_01_38-Library - Pipelines

    You do need to click Save at the end of this.

    In my pipeline, I see I have some variables. On the left, again, is a Variable groups item.

    2020-10-21 15_02_52-Release SimpleTalkDB - Pipelines

    When I click that, I don’t see any, but I haven’t linked any. Here I need to link my group.

    2020-10-21 15_03_26-Release SimpleTalkDB - Pipelines

    When I click this, I get a blade on the right. I can then see my group(s), and I can set a scope. I do need to click the group and then I can click link at the bottom.

    2020-10-21 15_04_23-Window

    Now I see the variables available in my pipeline.

    2020-10-21 15_05_06-Release SimpleTalkDB - Pipelines

    That’s pretty cool, especially as I am starting to see separate pipelines for different downstream environments becoming more popular.

  • What’s the Lunch Factor?

    A few weeks ago I wrote about the bus factor. This is the number of people that could cripple your organization if they got hit by a bus. Maybe a better way of looking at this is the lottery factor. If these people won a lottery and quit, would they cause problems? There were some interesting answers in the discussion.

    There is another factor that I heard about in a presentation that I found interesting: the Lunch Factor. This is the number of people that have to get involved for you to deploy changes to production. Today, I wonder what your lunch factor is? Leave a note in the discussion.

    This may be one set of people in your organization for things like patches, which are supposedly tested and approved by the various vendors you use. For software that you develop internally, likely there is a slightly different group of people, with some overlap. Usually the Operations staff is the same in both situations.

    In a true DevOps organization, the idea is that developers can actually release code to production. Maybe not every developer, or not every developer can release every type of change, but the idea is that developers can, and do, release code. They’re also responsible for this code. In my discussion with Donovan Brown and Abel Wang of Microsoft recently, this is how they view the world.

    They also would likely have most code released triggered and controlled by feature flags, which might ensure that customers can’t see the code right away, or that the code doesn’t break existing customer work. This also ensures that you can turn the feature off if there are problems. I’m a big fan of feature flags (or feature toggles) and think they are way too underutilized by many organizations.

    Allowing developers to release code is difficult for many managers, and even for Operations staff. There is always the worry that developers don’t have the expertise or accountability to make these decisions, and many orgs don’t have the capability built in to allow this, much less give the authority to a wide group of people.

    Microsoft does, as do lots of organizations trying to embrace DevOps and produce higher quality, more adaptable software. Many of these companies are bound by Sarbannes-Oxley and other regulatory rules, and they make it work. They grow, change, adapt, and most importantly, constantly improve their systems and process to allow this. For them, the lunch factor is 1, or maybe 0 if you consider that no one needs to get taken to lunch. What’s your factor? What staff, managers, even change control boards have to get involved? Let us know today and then think if you could reduce that number.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Pulling Together

    When the COVID-19 Pandemic grew rapidly in early 2020, medical supplies were in short supply. Different areas and organizations struggled with different types of issues, and one of the higher profile issues was with ventilators. In March, the projections were dire and quite a few hospitals were worried about the supplies of these devices. This was especially disconcerting given how many people were being placed on them and how long it takes to produce them.

    I met someone at that time that said getting a car company to produce these wasn’t possible. The factories were specialized and converting machinery and people wasn’t something that could be done in months. This was someone that claimed to have over 30 years of manufacturing experience.

    I had no basis to argue, though my instinct was that we have mobilized large industrial efforts in the past. When I read this article recently, it made me think about that conversation. Microsoft worked with a number of manufacturers to produce ventilators quickly, up to 400 a day in the UK. The story is interesting, and it shows that engineers at companies like Ford, McLaren, Unilever, Rolls-Royce, and more can not only work together, but also focus their efforts in a crisis. With the help of technology and data, they transformed a manufacturing process from the ground up to meet the needs of the UK.

    If you watch the video of the effort, it is amazing to see just how knowledge and data are brought together to ensure these devices can be built quickly, and at a very high level of quality. Certainly some PR is involved here, but the keys to success in producing something are the knowledge and skills being applied to a task. Products like dashboards and the Hololens help to move knowledge around where it is needed. In building software, tools like Live Share help to move knowledge from one person to another.

    The coordination of people working together, driving to a common goal, is critical as well. DevOps asks us to practice this, choosing to be a team, with the goal of increasing quality while we focus on delivering software to customers. This is a great story, but one that highlights things that many of us could strive for in our daily work.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.