staging-devopsy.kinsta.cloud

Tag: devops maturity model

  • How a Mature DevOps Practice Can Strengthen Competitive Advantage

    How a Mature DevOps Practice Can Strengthen Competitive Advantage

    Saman Pourkermani, practice lead, operations effectiveness, Inspirant Group, co-authored this article.

    Software development and delivery has become an integral part of every aspect of a business and is no longer simply a support function. Nowadays, most of us, including those in business operations, know the anxieties of having to wait for specific environment release dates to deploy code for urgent fixes or updates to Dev, QA, UAT or production, which slows down productivity. Or worse, an environment has gone down with no backup environment. We all know systems have to be in place to ensure quality and security, but what makes some companies more successful than others when it comes to their DevOps operations?

    Any organization that builds and delivers software applications and digital services can benefit fromDevOps. The main difference is the maturity of their DevOps culture and practices. Companies with mature DevOps practices and cultural philosophies are not only able to build and deliver applications faster than those with traditional DevOps practices, but also learn and innovate faster.  Mature DevOps capabilities, tooling, and cultural philosophies enable faster innovation by automating and streamlining development, testing, deployment, and infrastructure management processes. The ability to outpace others from both a delivery and learning standpoint is a huge competitive advantage.

    Most organizations understand this and as a result, have been heavily investing in maturing their DevOps capabilities and practices. However, most struggle to make meaningful progress to catch up to leading companies.

    Why is That?

    The most obvious reasons are resource constraints–budgetary, human and/or systems. Many companies have fixed budgets and must balance the tradeoffs between setting up an expensive infrastructure (equipped with yearly upgrades) with other business needs for short-term/long-term benefit gains. 

    We believe a company’s DevOps maturity is directly associated with and significantly impacted by how well and disciplined they are at making business prioritization and tradeoff decisions, picking what they will focus/work on and what they will not – ideally leaning out how much work they commit to completing.

    It goes without saying that most companies that want to but don’t yet have mature DevOps practices have more work than they can handle, from setting up and documenting CI/CD processes to creating business continuity and disaster recovery plans to ensuring they have the right people for execution. These critical elements take time, effort, expertise, and budget to put together. While everyone wishes their teams could get it all done in a timely manner, the reality is that everyone has a finite amount of budget and capacity.

    Quite often, progress on DevOps capabilities and automation gets sidelined in favor of ongoing customer delivery work. The trick is to establish a mechanism for balancing teams’ capacity allocation so that it includes a healthy mix of work focused on becoming more effective and efficient at delivery (e.g., maturing DevOps capabilities, improving architecture and design, etc.) and work to fulfill customer needs. In this way, a percentage of a team’s capacity can always be devoted to advancing DevOps delivery capabilities while the rest can be used to address customer requests.

    How Can This be Accomplished? 

    Start With Culture. Culture is a critical factor when it comes to having a mature DevOps practice. Team members must fulfill their individual roles but also operate as a cohesive unit. The mindset of each team member must be focused on the greater good of the whole – not individuals. Has the team established a way of working together that fosters accountability along with encompassing growth and innovation?

    Focus on Process. Progress cannot be made without identifying a clear, sensible process. For example, having a well-documented and executed CI/CD process is paramount to DevOps maturity to address all developer pain points and ensure a smooth deployment process. The key is having a documented process that establishes the team’s way of working and addresses the following: Are the right team members engaged? Are there special circumstances that need to be accounted for during the development/configuration/deployment processes? Does everyone have the same understanding of the process at each stage?

    Automation and Tools. Have your processes been automated in a way that allows the DevOps practices to happen in the same way each time, without manual intervention? Do you have and know how to use the fundamental tools that all successful DevOps practices need (e.g., build and test code continuously, source control (e.g., GitLab), environment configuration management, performance measurement (e.g., load balancing))? Are deployment pain points adequately identified and addressed to prevent coding/release bottlenecks?

    Business Prioritization and Trade-off Decisions. We believe this is the most important aspect of becoming a mature DevOps practice because it allows for progress over time. Balancing the teams’ capacity to include advancing DevOps delivery capabilities is critical for establishing and sustaining a competitive advantage. Optimizing your DevOps capabilities allows you to free up and capitalize on the time, talent and performance of your team members for learning and innovation.

    As Jack Welch once stated, “The only sustainable competitive advantage is to learn faster than your competition and to be able to act on what you have learned.” When a software organization becomes too rigid without an adaptive DevOps edge, it will be left in the dust. 

  • The Transience or Permanence of Provisioning

    The Transience or Permanence of Provisioning

    I realize the title of this article may conjure up ideas about the impacts of entanglement from quantum computing, but no, we are not there yet. Instead, I am referring to the benefits an organization can achieve from determining which environments in its software development life cycle (SDLC) should remain permanent and which are better candidates to be transient to understand the discreet costs of innovation (ideally if virtualized).

    First, to keep an even playing field, make sure your DevOps services are using the “build once, deploy many” philosophy. Under this thinking there is a single build constructed that is deployed unilaterally into each class of SDLC environment (not a unique build for each class). Uniformity under test eliminates variability of results. Uniformity of the basic process of deployment, builds consistency and predictability also will reduce errors and the time it takes to resolve them.

    Second, the actual computing capacity you deliver any environment on may be virtualized, whether you provide your own bare metal assets (private cloud foundation) or if you use a public cloud entirely is less the issue. Understanding whether a class of environment is transient or permanent only affects how you plan for the costs and policies of operating it, and it leads back to the discreet cost of innovation as a result.

    The Cost of Creation

    When this topic is usually considered the first and immediate point of view is usually R&D, or the development class environment. And yes, the ability to provision a DEV class environment and then tear it down when the effort has completed is the normal use-case to justify virtual infrastructure at all (public, private or hybrid cloud usage). The obvious benefits include having no “throttle” on how many concurrent efforts might be spun up.

    Transient DEV environments also build in a concept of failure, or elongated “playing,” not intended to produce a specific result but intended to dabble with innovation to see what “might” be possible. All of this without the capital investment it would take to build and maintain an R&D lab to accommodate it, or set aside fixed computing capacity for it. DEV efforts with intent (i.e., part of a formal project) can be tracked for costs discreetly with that planned innovation. DEV efforts without intent (i.e., more like what used to occur in R&D labs) can be associated to the overhead costs of all innovation.

    The Cost of Evaluation

    But beyond DEV, the next major class of environment to consider is the integration (INT) class. If your company has more than one application, has apps that work together or has applications with upstream or downstream dependencies, you likely need an INT class environment. The major responsibility of this class environment is to provide “something to point to.” Your app (undergoing change) has an environment where it can point to all the other applications to test how the interconnections work. Logically, this class of environment is a better candidate for permanence. This is because you can rarely predict which apps may need this service at which time across the entire portfolio. Many apps undergoing change may be using this at one time to insure they all work with each other (i.e., assessing their interoperability with future versions, early, or prior to production).

    Another reason for maintaining a permanent INT class environment may involve your interaction as a vendor to other companies who “point” their apps at yours as a service provider. Even organizations who have little interaction between their own apps, may well be a significant provider to a wide swath of customer applications. If your customers need a place to point to, the INT class environment is typically the one you want. So in this instance permanence is the logical need.

    Next up, becomes the performance test (PT) class of environments. Emulating production, or being able to project differences between the platform you use, and what production provides is key to success. However, this class of environment is a perfect candidate for transience (especially if your development and production environments are already virtual). Why maintain expensive hardware on the floor, only to conduct periodic testing, which requires massive reconfiguration and preplanning. Dump it. Instead, use a virtualized platform where provisioning is near instant and can exactly mimic both development and production – remember: build once, deploy many.

    Another significant class of environment in the SDLC to examine is the User Acceptance Testing (UAT). Logically, this class environment may get a lot of usage, but ideally only after the app has passed testing in development, INT and PT. Because of this, the UAT should be transient as well. A good candidate to tear down when not in use. You may wish to plan for a setup and tear down of this class to mimic what happens in formal development efforts.

    Finally, the quality assurance (QA) or preproduction (PreProd) class environments, if in use, are designed to emulate the current state of production completely, allowing the app-under-change to run against a more sophisticated type of INT class environment (with possibly copied production data, etc.). This happens more often when the earlier INT class environment contains a great number of other applications under change. This one provide a “cleaner” place to point to, only production operating apps. The QA environment may also be used as an after action, when an error is discovered in production for debugging or more extensive monitoring. Obviously, if your organization finds a need for this class of environment, it will carry the permanence characteristic.

    The Cost of Operations

    Production is by nature permanent. Virtualizing production offers the ability to scale on demand. But a scalable production solution benefits from more mature DevOps services (whether you own the data center or not). Consider for a moment, the number of errors attributed to code post a DevOps embrace. The number of errors goes down, the time to resolve them goes down, the size of the effort gets smaller for less risk, and higher speed. This combination means production is going to suffer far less from aberrant code running amok (asking for tons of memory, CPU or disk due to error). Those kinds of problems get detected earlier (because of DevOps) in the SDLC process and hardly ever reach production after DevOps is engaged.

    With a mature use of DevOps, it means that any kind of scalable solution of capacity-on-demand will get engaged for only two reasons: a dramatic increase from customer demand (the ideal solution) or a denial of service attack attempting to drive your costs higher without real customer use. The monitoring solution you employ will help decipher the difference. If your application has logging features built into it (i.e., you produce a log detailing what customer is performing what key feature in your app and when) you should be able to avoid the latter scenario with an automated monitoring detection effort.

    New Abilities to Measure the Cost of Innovation

    Understanding the cost delta of transient and permanent environments is worth examining. It will help you understand better the cost of innovation on an annualized basis. And it may also reveal how much real effort goes into testing of each kind of class. If user adoption is suffering for example, and you determine that UAT class environments are largely unused or torn down, you know better where to address the problems earlier in the cycle. The same can be said for PT as well, how much test, for what kind of scaled performance in production.

    If your organization maintains INT or QA class environments you may want to allocate their costs to SDLC overhead as they tend to be permanent, and value shared. The development, PT, and UAT environments, if transient, represent the variable cost of a particular innovation effort and can be tracked with good discretion. When considering the timing, value, and benefits of virtualization, you may wish to factor in where you are on the DevOps continuum. If you have had DevOps running for a while, the timing for virtualization and scalable capacity on demand may be better, than if you are just starting out.

    Keep in mind that most organizations who have transitioned away from waterfall and into agile, will lose a good deal of the former financial controls that worked in waterfall, and do not work as well in agile. DevOps delivery is also capable of moving change at orders of magnitude higher speeds than former manual methods. This combination makes trying to cost innovation discreetly more difficult. Being able to associated transient environment costs with formal development efforts (ones with intent) may restore some of that financial discretion. It may also help identify the true overhead costs of innovation located in the operation of environments classed better as permanent.

    To continue the conversation, feel free to contact me.