devopsy.kinsta.cloud

Category: Enterprise DevOps

  • Continuous Testing Practices (Part 1)

    Continuous Testing Practices (Part 1)

    In my prior blog, Continuous Testing – The Quest for Quality at Speed, I described five tenets and some of the practices for continuous testing (CT) to help those understand what continuous testing is. In my consulting work, I find it necessary to use 15 categories of practices to assess an organizations’ continuous testing capabilities. Given the large number of practices, I am publishing the complete list in three parts.

    This article is part one, which covers the following categories of continuous testing practices:

    • Continuous testing tenets
    • Leadership
    • Culture
    • Test strategy and plans
    • Test management

    Continuous Testing Tenets

    • The continuous testing principle “shift left” is practiced, in which tests are conducted as early in the pipeline as possible.
    • The continuous testing principle “fail early” is practiced, in which tests are arranged so that the most likely problems are found in the early stages of the pipeline.
    • The continuous testing principle “fail often” is practiced, in which tests are run frequently and with many different conditions such as different variations of operating systems, production topologies, browsers and production versions of services.
    • The continuous testing principle “test fast” is practiced, in which tests are run in quick cycles to get to a verdict as quickly as possible.
    • The continuous testing principle “be relevant” is practiced in which tests are focused on the most important tests and results for each purpose and stakeholder.

    Leadership

    • Leaders establish a definition and vision for software quality.
    • Leaders establish a definition for test coverage.
    • Leaders clarify how everyone’s roles fit with the CT strategy.
    • Leaders establish incentives for CT performance.
    • Leaders proactively sponsor quality assurance testing as a strategic element of their budgets and operations rather than viewing testing as a cost to avoid. This includes budgeting time and money for DevOps test training, test resources, test frameworks, test tools, test management and establishing policies for assessments.
    • Operational and capital expense budgets are planned together with all stakeholders to ensure all stakeholders agree there is enough opex and capex budget for the organization to accomplish quality goals for the budget period being planned.
    • Cost accounting practices ensure the capex and opex expenditures are tracked and made visible to stakeholders.
    • Schedules for CT improvement projects are identified and tracked.
    • Skills development programs provide individuals and teams opportunities to learn CT practices.
    • The performance of continuous quality assurance programs are monitored and made visible to stakeholders.
    • Leaders participate in creating and maintaining guidelines for codifying and tagging business risk priorities.

    Culture

    • Quality is everyone’s concern. Responsibility for attaining high quality software products is shared by everyone on a cross-functional team.
    • Cross-functional team members collaborate for testing. This reduces confrontation and friction between people who find failures and those who fix the code.
    • Dev teams embrace the creation of good tests and analysis of test results.
    • Ops team members contribute to test planning, test creation, test execution and test results analysis.
    • Policies for test creation and test coverage are agreed upon by the cross-functional team including Dev, QA, security and Ops team members.
    • A test architect is a role within the organization. The role has expertise in CT practices and helps cross-functional teams understand and apply them.

    Test Strategy and Plans

    • Test strategies and plans are created for each product or service and reviewed by cross-functional teams including development, QA, Ops and security teams.
    • Test strategies and plans identify the type of tests, and the extent of testing activities, for each stage in the value stream.
    • Test requirements and tasks are included in agile planning procedures for each theme, epic and user story.
    • Test strategies and plans define a test coverage standard, test case standards, and input/output criterion for each pipeline gate.
    • Test plans identify the test cases and all the supporting requirements to implement and execute the test cases as required satisfying the test strategy and test management goals.
    • Test strategies and plans identify the approach for system and acceptance testing.
    • Test strategies and plans identify any tests that are to be conducted in production.
    • Test strategies and plans identify any tests that are to be conducted for security testing.
    • Test strategies and plans identify a target for test automation and manual testing for each type of testing. For example, 100% of all tests in the integration stage and 85% of test in the pre-production stage is a typical goal.
    • The test strategy requires that changes to a database or changes to an application that uses a database have tests defined for the database and the application use of the database.

    Test Management

    • All aspects of test management, such as test planning, test guidelines, test code version management and version management of test results are handled by tools that are well-integrated into the continuous delivery pipeline and any test framework being used for test automation.
    • Schedules for all test tasks are identified and tracked.
    • New features have a scheduled task to ensure test goals are met for each new feature.
    • Each test case has associated attributes that can be used to find tests according to the attributes. For example, an attribute could be type of test and the feature purpose of the test.
    • Test environments and resources needed to satisfy requirements to run each test are identified and available programmatically for scheduling purposes.

    What This Means

    Continuous testing practices are critical to success with DevOps. Many organizations underestimate both the importance and the practices needed to engineer continuous testing. This article is the first in a three-part series that provides a comprehensive list of practices that can be used to understand and assess an organization’s continuous testing capabilities. To learn more about my blueprint for continuous testing, refer to my book Engineering DevOps.

  • Some Technical Debt is Self-Resolving

    Some Technical Debt is Self-Resolving

    But don’t count on it.

    Fellow DevOps.com contributor Bill Doerrfeld recently wrote, “Enterprises Face Growing Technical Debt,” a great article about trends in technical debt, and it got me thinking about some of the things that have been going on in the industry over the last few years.

    As I’ve mentioned before, the changes underlying our systems combined with the need to keep systems that existed before those changes alive are making for quite the debt ratio, and that debt is coming due, probably sooner than you think.

    We’ve got enhanced ways of tracking how much time technical debt is consuming built right into our CI/CD tools, but there are inherent weaknesses in those tools. The ability to track time spent on issue X, and to categorize issue X as debt, requires a solid categorization process and relies on staff to keep close track of their time. Right or wrong, the industry has currently (maybe permanently) moved away from tracking time in small increments and, instead, most organizations track results. But unless you know the percentage of time spent keeping a system that is outside your main-line development toolsets alive, you can’t determine how bad technical debt really is.

    There are some bright spots though, and while I (and others, to be sure) have been sounding the alarm about technical debt since DevOps teams were all allowed to pick their own toolchains (glad that’s mostly over with), we need to be aware that counter-forces will help alleviate technical debt issues, also.

    First is the trend of making things simpler. Let’s face it, on the DevOps side, Python became popular at an insane pace. There is a very good reason for that. Shell scripts written by master scripters to achieve a goal are impossible for even good IT folks to follow. What you can’t follow will take much longer to fix–because you have to break it apart, figure out the parts, parse through massively complex pattern matching, etc. Python simplified all of that. If you write a Python script to do the same thing as a bash script, a far higher percentage of IT will be able to glance at it and go, “I know what this does.” This trend exists across IT (bug dashboards are another good example at a much higher level), and as easier-to-understand tools are increasingly part of the mix, the old and arcane will be less of a debt.

    Second is that, while I have raised warnings about things like the growth in API usage and CI/CD toolset complexity, the fact of the matter is that both of these things reduce the amount of code that we, internally, are maintaining. Steps automated, be they by calling someone else’s API, or calling your CI/CD vendor to handle build or deploy steps, are less steps for us to worry about (as long as they work, of course–have trusted partners).

    But we still need to be aware of technical debt, because all of the things we’ve mentioned in the past—the increasing complexity of our environments, staff turnover, team-specific tools and languages—are driving up debt.

    Check with your CI/CD vendor to see what their offering for tracking debt looks like. Other measures that don’t require tracking actual time spent on individual activities include keeping a tally of the number of bugs. And a surefire way to get a great feel for where your weaknesses are is looking for the software no one wants to work on, or the software that someone warns the new people not to touch. That’s where your debt load is the heaviest. IT is full of tinkerers;”If it ain’t broke, don’t fix it …” only applies in IT if “…because no one here knows exactly how it works,” also applies.

    Ask your teams to list which tools in their area (be it silos or DevOps teams) need to be updated and/or replaced, and then to rank them. Then take that data to team leads, and ask them to decide where your limited hours and money should go. Provide data on relative debt that you gathered above, so a comparison of team rankings to debt cost can be made.

    And then, set aside time to alleviate debt. It doesn’t have to be massive, just keep moving forward on it. You set aside time for all sorts of things, even a few man-hours a week on debt will multiply. It will start slow, but once you are spending less time each week fixing “product X,” some of that time can be added to technical debt resolution, increasing what can be done. Look for low-hanging fruit; a small app or script that eats up an outsized amount of time, or a system that is insanely expensive to keep, while the market has moved past what it actually is used for in your department, etc.

    Then enjoy the fruits of your labor, and put those astounding skills and that extra time to use rocking even more new apps for your users.

  • Learning ‘The Third Way’ of DevOps – Continuous Improvement

    Learning ‘The Third Way’ of DevOps – Continuous Improvement

    I refer to the third way of DevOps–continuous experimentation and learning, as simply continuous improvement. In some sense, there is no way to learn the third way of DevOps because it is, by definition, a moving target. It does make sense to discuss what is needed to create a continuous learning organization for DevOps continuous improvement that builds on mastery of the first way and second way of DevOps.

    As indicated in my blog Learning ‘The Second Way’ of DevOps – Continuous Feedback and my prior blog Learning ‘The First Way’ of DevOps – Continuous Flow, it is clear many organizations are struggling to realize well-engineered DevOps, even the first way of DevOps, continuous flow.

    The first way of DevOps, continuous flow, is the foundation for DevOps. Once mastered, an organization will naturally want to master the second way of DevOps to achieve the higher level of benefits that continuous feedback offers, when engineered well. Once the second way of DevOps is achieved, then an organization will naturally want to master the third way of DevOps, to sustain and grow their DevOps capabilities.

    DevOps is an evolving body of knowledge. There is no one-stop shop that covers all roles and the complete range of skills required for DevOps. A DevOps-competent workforce requires an ongoing commitment to DevOps skills development and mastery. Enterprises must approach DevOps training strategically to leverage training resources to their best advantage.

    Learning Continuous Improvement

    There are no training resources dedicated solely to the third way of DevOps—continuous improvement. Many of the same resources as the first way of DevOps and the second way of DevOps do have some relevant information, though. Analysis of DevOps results, third-party research sources, industry sources such as publications, articles, conferences and tool vendors roadmaps for DevOps and related frameworks including site reliability engineering (SRE) and AIOps are good sources of information that stimulate self-directed teams to seek the training information that is most relevant to the organization’s DevOps improvements.

    Why Is Learning Continuous Improvement Important to Engineering DevOps?

    The third way of DevOps—continuous improvement—requires an organizational commitment to continuous learning and mastery at the most advanced level. Typical skills needed include implementation and operation of advanced practices for microservices design and operations, advanced continuous testing, multi-pipelines, value stream management, SRE, observability, DevSecOps and AIOps. Retention and development of highly skilled and hard to find experienced DevOps professionals and SREs makes it important to develop skills in-house.

    How Is Learning Continuous Improvement Accomplished?

    The following are recommended engineering practices for learning continuous improvement:

    • A continuous learning culture encourages individuals to continuously gain knowledge and exchange experiences and ideas for DevOps and SRE.
    • Mentoring is an explicit program.
    • Retrospectives are structured to thoroughly analyze significant, unexpected events and determine solutions that will prevent the events in the future.
    • An active online library of DevOps and SRE training resources is maintained that tracks the latest and most innovative approaches to DevOps and SRE.
    • DevOps and SRE teams evolve their skills and advance their careers by engaging with industry thought leaders to continuously update training content.
    • Partner with trusted education and training partners ensure the highest-quality learning content and tools are made available to DevOps and SRE teams.
    • A portion of DevOps and SRE teams time is allocated for training and education.
    • Cross-team sharing of recommended engineering practices is proactively pursued using the concepts of Yokoten—proactive sharing of practices between teams.

    What Is Needed to Implement Learning Continuous Improvement?

    The following are recommended engineering practices for implementing a learning program for continuous improvement.

    • Assign roles and responsibilities to experts for defining a training program for DevOps continuous feedback (e.g., DevOps sensei, training PM, evangelist).
    • Conduct a continuous feedback DevOps skills gap assessment.
    • Define a training strategy that best address the gaps and fits the needs and priorities of the organization.
    • Define a training budget that includes expenses and time allocations per role and skill.
    • Determine which skills and roles can be covered by inexpensive self-study resources.
    • Determine which skills and roles warrant more costly commercial training.
    • Identify training goals for each role.
    • Ensure recruiting job profiles match skill requirements for DevOps skills that are most relevant to the organization’s strategic goals.
    • Create a continuous learning culture that encourages individuals to continuously gain knowledge and exchange experiences and ideas for DevOps and SRE.
    • Build an active online library of DevOps and SRE training resources that tracks the latest and most innovative approaches to DevOps and SRE.
    • Engage with industry thought leaders to continuously update con tent for DevOps and SRE teams to evolve their skills and advance their careers.
    • Partner with trusted education and training partners to ensure the highest-quality learning content and tools are made available to DevOps and SRE teams.
    • Put in place means to make training resources visible and available.
    • Set training goals for teams and individuals.
    • Put in place incentives and recognition programs for training.
    • Track training progress.

    Some of the best sources of DevOps training resources are listed below:
    1. The DevOps Institute
    2. Partners of The DevOps Institute, such as Learning Tree International and Xellentro.
    3. Udemy.com
    4. Recorded talks and publications of IT Revolution
    5. Books such as my own Engineering DevOps, by Marc Hornbeek.

    What This Means

    The third way of DevOps—continuous improvement—requires an organizational commitment to continuous learning and mastery at the most advanced level. Typical skills needed include implementation and operation of advanced practices for microservices design and operations, advanced continuous testing, multi-pipelines, value stream management, SRE, observability, DevSecOps and AIOps. Analysis of DevOps results, third-party research sources, industry sources such as publications, articles, conferences, and tool vendors roadmaps for DevOps and related frameworks including site reliability engineering (SRE) and AIOps are good sources of information that stimulate self-directed teams to seek the training information that is most relevant to the organization’s DevOps improvements.

    Organizations must approach DevOps training strategically and continuously to leverage training resources to best advantage. To learn more about my blueprint for learning all things DevOps, refer to my book Engineering DevOps.

  • Yes, You Do Need SCA

    Yes, You Do Need SCA

    We often go to restaurants and treat ourselves to unfamiliar and exotic foods made with ingredients we’re only vaguely aware of. A chef and their team (or a manager and their crew) are our vouchsafe that what’s in there isn’t deadly. Most of the time, that works out just fine; but, very rarely, we end up paying the price. The same is true for food brought home from the supermarket, though for lesser illnesses it is harder to track because they’re not clustered like restaurant customers. While it is indeed exceedingly rare for the results to be fatal, the CDC estimates that around 3,000 people die of food-borne illnesses in the U.S. each year, and millions more are made ill. The U.S. has incredibly safe foods, and yet, we still have these illnesses. Simple things like leaving ingredients out too long, or consuming food sourced from a contaminated production facility can cause problems, even in an otherwise safe environment.

    Our code is similar—how it is created and consumed—and increasingly falls in this category. We rely upon a ton of sources for the systems that run our networks, and, quite often, there is no one to tell us how safe our sourcing is, or if changes are happening beneath that escape our notice.

    This is why we absolutely must have software composition analysis (SCA). If no one else is going to stand up and verify the safety of all that code we are pulling in, then we need to at least be aware of what is there. We need to understand the inter-relationships of pieces of underlying software, both the known and the unknown. Some libraries are so ubiquitous that you are using them and likely don’t even know it. But that’s not good management; knowing what you have and taking care of it are increasingly becoming a core part of IT. Knowing what alternatives are available in case something goes wrong with your preferred (or automatic) inclusion is imperative for continuity, making SCA a critical part of continuity planning along with the fact that it’s just good business practice.

    The good news is, if you are using any of the major code scanning tools from the DevSecOps space, you either already have SCA available to you, or you can buy it as an add-on from the same vendor. Hit their website and find out.

    Your systems are out there, every day, serving the needs of your users. Protect those users from unforeseen circumstances like vendor issues, open source changes, security vulnerabilities and nested dependencies. While the vast majority of open source is safe and secure, we use so much of it—and the tools we use link in so much of it—that it’s almost certain there is a bomb hidden somewhere in your code. Think of it like the food-borne illness example above: Would you eat at a restaurant that said “Yeah, 90% of our food is safe, but we’re not sure about the other 10% …”?

    You’re building astounding things, and keeping the world moving. Don’t stop, but don’t let your guard down, either. Know what is running in those apps, what its vulnerabilities (both security and downtime) are and what you can do to mitigate those weaknesses–so you can keep making astounding things rather than spend your time fixing what is already there.

  • Learning ‘The Second Way’ of DevOps – Continuous Feedback

    Learning ‘The Second Way’ of DevOps – Continuous Feedback

    As indicated in my prior blog Learning the ‘First Way’ of DevOps–Continuous Flow, many organizations are struggling to realize well-engineered DevOps, even the ‘first way’ of DevOps – continuous flow.

    The first way of DevOps, continuous flow, is the foundation for DevOps. Once mastered, an organization will naturally want to master the second way of DevOps to achieve greater benefits that continuous feedback offers when engineered well. DevOps is an evolving body of knowledge. There is no one-stop shop that covers all roles and the complete range of skills required for DevOps. A DevOps-competent workforce requires an ongoing commitment to DevOps skills development and mastery. Enterprises must approach DevOps training strategically to leverage training resources to their best advantage.

    Learning Continuous Feedback

    There are no training resources dedicated solely to the second way of DevOps—continuous feedback. Many of the same resources used to learn the first way of DevOps have some relevant information, though. DevOps monitoring, release automation and security tools publications, articles and tool vendors are a good source. A DevOps expert who is experienced with mature DevOps can select the training information that is relevant to the specific continuous feedback tools and feedback metrics used by the enterprise.

    Why This is Important to Engineering DevOps

    Continuous feedback requires a mature understanding of DevOps concepts and practices. Specific skills are needed for implementation and operation of advanced monitoring tools and practices for application performance, database performance, advanced continuous testing, advanced release management, infrastructure performance and continuous security.

    How Is Learning Continuous Feedback Accomplished?

    The following are recommended engineering practices for learning Continuous Feedback.

    Roles and responsibilities are assigned to experts for defining a training program for DevOps continuous feedback (e.g., DevOps sensei, training PM, evangelist). Continuous feedback DevOps skills gap assessments are conducted periodically. Dev and Ops training strategies are designed to address gaps and priorities of the organization for DevOps continuous feedback. A training budget that includes allocations of expenses and time allocations per role exists to support continuous feedback. Continuous Feedback goals and SLAs are defined for each role.

    Recruiting job profiles match skill requirements for DevOps skills relevant for continuous feedback. Training resources are available and visible to those that need continuous feedback training. Training goals set for teams and individuals include goals for continuous feedback. Incentives and recognition programs support Continuous Feedback training. Continuous feedback training progress is tracked and visible.

    What Is Needed to Implement Learning?

    The following are recommended engineering practices for implementing a learning program for continuous feedback.

    Assign roles and responsibilities to experts for defining a training program for DevOps continuous feedback (e.g., e.g., DevOps sensei, training PM, evangelist). Conduct a continuous feedback DevOps skills gap assessment. Define a training strategy that best addresses the gaps and fits the needs and priorities of the organization. Define a training budget that includes expenses and time allocations per role and skill.

    Determine which skills and roles can be covered by inexpensive self-study resources. Determine which skills and roles warrant more costly commercial training Identify training goals for each role. Ensure recruiting job profiles match skill requirements for DevOps skills that are most relevant to the organization’s strategic goals.

    Put in place the means to make training resources visible and available. Set training goals for teams and individuals. Put in place incentives and recognition programs for training. Track training progress.

    Some of the best sources of DevOps training resources are listed below:

    1. The DevOps Institute
    2. Partners of The DevOps Institute, such as Learning Tree International and Xellentro
    3. Udemy.com
    4. Recorded talks and publications of IT Revolution.
    5. Books such as my own “Engineering DevOps,” by Marc Hornbeek.

    What This Means

    To accomplish the benefits of the second way of DevOps—continuous feedback requires a commitment to continuous learning and mastering skills beyond what is needed for the first way of DevOps–continuous flow. Specific skills are needed for implementation and operation of advanced monitoring tools and practices for application performance, database performance, advanced continuous testing, advanced release management, infrastructure performance and continuous security. Organizations need a trained workforce to succeed with DevOps. Organizations must approach DevOps training strategically and continuously to leverage training resources to their best advantage. To learn more about my blueprint for learning all things DevOps, refer to my book Engineering DevOps.

  • Make a Plan for Test Automation

    Make a Plan for Test Automation

    The amount of testing that we could be doing is massive. Most of us don’t look at testing across the spectrum and all-inclusively, but let’s do that for a second.

    We have functional testing at the code level, which is reasonably well automated already, if your shop is using such automation. Then we have integration testing, which is a superset collection of API testing, code integration testing, usability and regression testing. Integration testing is automated, and sometimes that’s done well, but this massive space is still growing. Next up would be security testing, which covers much of the same code that other testing is interested in from a strictly security focused perspective. Then, there is actual usability testing, which is more important for some areas than others—embedded needs far less usability testing than web apps, for example—and has different levels of automation at this point in time.

    Really, when you think about it, the complexity of this environment is massive. We not only need to test an array of different functionalities from an array of different perspectives, but we have to do it on an array of platforms. Testing on Windows is different than testing on Linux; testing in the cloud can use different tools than testing in-house; clients can be on any given platform, depending on the application and target market … we really do have a beast, here.

    And testers have always been behind, or have not covered things well. This is not a ding on testers, this is the result of the complexity at hand and the fact that, in many instances, one line of code can go wrong in a bunch of different ways.

    Enter automation, which is growing rapidly in the world of continuous integration (CI). Automated testing tools range from broad to very focused, and all help facilitate testing. The DevOps increase in development means more testing, and testing was already behind. This has been discussed pretty thoroughly in the past, but it finally feels like we’re getting to a point where we have viable solutions to the problem. If testers become test developers that review results of automated tests, and through CI those automated tests are increasingly worked into the process of development, we’ll see testers getting better coverage and quality seeing a continued increase.

    But that does mean you should keep your eyes on the market as it continues to grow, and pick tools that offer the most functionality that is most useful to your test team. And get them up and running. More testing means more work setting up tests. Even no-code test solutions for UI require someone to record the actions that are necessary to complete the test, and that takes someone’s time. But the return is long-term testing that doesn’t require a person until a red flag is raised by automation.

    I’m all for it. Both testing and security have the most to gain from automation, because they’ve been the most behind historically, and corner-cutting has cost organizations dearly. So, let’s get with it; check out some new test tools (there are plenty listware articles giving you a place to start), and let’s make great software better!

  • HashiCorp Increases Terraform’s Enterprise Appeal

    HashiCorp Increases Terraform’s Enterprise Appeal

    During the online HashiConf Europe conference today, HashiCorp debuted the general availability of a 1.0 release of HashiCorp Terraform along with updates to HashiCorp Terraform Cloud service.

    Meghan Liese, senior director of product marketing for HashiCorp, said in both cases HashiCorp is moving to enable organizations to better secure and govern IT infrastructure-as-code provisioned using open source Terraform tools.

    Version 1.0 of HashiCorp Terraform provides access to a stable application programming interface (API) that will foster interoperability and simplify future upgrades.

    The Terraform Cloud service, which eliminates the need for IT teams to set up and manage a Terraform platform, adds workflows enhancements to the Terraform Cloud that include the ability to publish curated modules to a private registry, enhancements that make it easier to visualize elements of a workspace and a preview of an ability to check with third-party tools related to a Terraform run.

    Overall, the goal is to make it simpler for organizations to compose, collaborate and reuse infrastructure-as-code using modules and the public and private registry options, said Liese. The public registry already has more than 5,000 modules. Terraform Cloud now offers a native workflow to publish modules from the public registry directly into an organization’s private registry.

    Terraform, of course, has been widely employed since it first debuted in 2014. There have been 15 major updates prior to the release of Terraform 1.0, which is intended to provide a foundation that ensures backward compatibility between releases going forward.

    In some instances, Terraform can be too much of good thing. It has considerably accelerated the rate at which IT infrastructure can be provisioned within the context of a DevOps workflow. The challenge, though, is developers often lack the security expertise required to prevent infrastructure from being misconfigured at a time when cybercriminals have become more adept at scanning for those vulnerabilities. To enable IT teams to prevent those misconfigurations, HashiCorp makes available both an enterprise edition of Terraform as well as its Terraform Cloud service. Terraform Enterprise is used by more than 1,200 enterprises, while Terraform Cloud has more than 120,000 users that execute more than 30,000 runs per day.

    It’s not clear if security concerns might one day lead to a backlash against the concept of shifting more responsibility left toward developers to improve productivity. In some cases, developers are simply deploying more insecure applications faster. HashiCorp is making a case for Terraform platforms that allow centralized IT teams to exercise more control over how infrastructure is provisioned as code. The need for that approach is becoming more pronounced, as organizations not only employ Terraform to provision cloud infrastructure but also on-premises IT environments.

    Regardless of how infrastructure is provisioned by developers, security of infrastructure, both inside and outside of the cloud, remains a priority as more workloads than ever are deployed. In effect, the attack surface that needs to be defended has dramatically expanded. Of course, the best security issue of all is the one that never happened because infrastructure is being provisioned right the first time and every time thereafter.

  • Why AIOps Is Critical for Pandemic Business Recovery

    Why AIOps Is Critical for Pandemic Business Recovery

    As businesses worked to stay afloat over the last year, innovation in many areas fell behind. Business leaders struggled to understand the short-term and long-term impact the COVID-19 pandemic would have on their business, while employees worried about losing their jobs and customers scrambled to rearrange budgets. As we near the end and can finally see light at the end of the tunnel, business leaders are looking for ways to get back on track.

    Artificial intelligence for IT operations (AIOps) is the solution many businesses need to free up resources and return their focus to innovation. The data speaks for itself—the AIOps market was valued at $13.51 billion in 2020 and is expected to grow by more than 200% to $40.51 billion over the next five years. AIOps presents several benefits to enterprises, like automating mundane tasks, providing actionable reporting and improving risk management.

    But before IT leaders jump headfirst into adopting AIOps, there’s still one common misconception they must address: AIOps isn’t a solution, it’s a long-term strategy. AIOps simply cannot be viewed as a band-aid on the road to recovery. To truly maximize the benefits and bring innovation back to the center of business focus post-pandemic, teams must view AIOps as a long-term strategic investment.

    For IT teams looking to adopt an AIOps strategy, consider these three takeaways to jumpstart the journey and maintain it in the long term.

    Find a Partner to Offer Market Insight

    On the road to recovery, IT leaders may not have the time or bandwidth to truly invest what it takes to implement a robust AIOps investment strategy—let alone where to start. But working with a trusted, experienced partner who does have the time and resources to map out a plan and who keeps a close eye on market trends can help ease any struggles that IT leaders may face.

    A strategic partner can also help teams identify what tools IT teams already have in place that will support an AIOps strategy and which will stand in the way of it. Through a comprehensive tools rationalization process, IT teams have a better grasp of what tools they have in place, which are performing overlapping capabilities (in other words, increasing unnecessary costs) and what tools they still need to support their AIOps journey.

    The right partner can plot a path forward for IT leaders and give them peace of mind knowing they have an expert in their back pocket at all times.

    Identify Use Cases

    Use cases for AIOps may have changed over the course of the last year depending on a company’s place in the market, product focus and future growth plans. But as companies bring innovation back to the forefront, they must reevaluate their use cases for AIOps. If you’re an IT leader looking to invest in AIOps, ask yourself ‘Why?’ and determine precisely how AIOps can support that end goal. Your trusted partner can help by giving a different perspective that IT leaders may not have, simply because they are in the weeds day in and day out.

    Build a Plan and Execute

    With the right tools in place and a partner by your side, it’s time to lay out your complete AIOps investment plan with actionable steps in place. Consider the use cases you determined and your short- and long-term goals for AIOps as a starting point. Remember—this isn’t a plan with a definitive endpoint, but rather a strategy with definitive milestones that can help keep the business up and running and customers happy while maximizing internal processes.

    As IT leaders look ahead, they can regain confidence and feel empowered to bring innovation back to the business. No longer should they feel like they’re drowning in incidents and constantly putting out fires. With a long-term AIOps plan in place, IT teams are equipped to thrive post-pandemic and come out on the other side stronger than ever.

  • A Funny Thing Happened On the Way to API Management

    A Funny Thing Happened On the Way to API Management

    As API use has exploded across IT departments large and small, the need to manage APIs as independent entities—both APIs themselves and calls to them—rapidly became apparent. We have been through this cycle several times before–ORBs, DCOM, object repositories … the list goes on.

    There are several competing goals when introducing some management structure into formerly as-needed remote calls occurs. We want to publish and advertise connections in the hopes we can avoid (or at least minimize) reinventing the wheel, while we also want to make access easier for app developers that are trying to use our APIs. Meanwhile, we want a centralized location where ops can monitor API usage, security can review APIs for compliance and “approved” APIs can be advertised or even hosted. Finally, we want to give internal developers access to approved external APIs that have been deemed appropriate and safe for the organization to use.

    As with previous iterations of this process, these goals, taken together, prove to be huge. There is a lot there to try and cover in an ever-changing API landscape. It is worse in this iteration, simply because of the proliferation of external APIs. Prior to REST, each iteration had more APIs, both internal and external, than the one before, and REST is keeping with that pattern, though now that we can look back, the external bit is a hyperbolic curve, not a line.

    So, it is interesting and cool to see the market fragmenting a bit. The entire package is a huge order that a few companies have taken on; I’ll leave it to you to decide if they’ve handled it well enough for your org. Others have taken one of two approaches—centralizing API access to external services that have been vetted and interfaced with by the vendor or enabling internal API developers and users.

    Now, we have a couple of manageable chunks to look into. I would even go so far as to say most vendors come from one or the other of these worldviews, and you should compare their “tilt” to your organization’s needs before purchasing an API management product. I would much prefer if we separated these markets into ‘API management’–those doing (or trying to do) it all, ‘API integration’–those simplifying and enabling access to approved APIs like Salesforce or ADP and ‘API enablement–those making writing, publishing, securing and advertising internal APIs easier. But I don’t get to make these calls, so we’ll have to watch it unfold.

    If your need is to streamline and protect your organization’s access to external platforms, and you use many popular services, start with API integration. If you need to get a handle on APIs that you are creating and using internally, start with API enablement. If you need both, and a centralized store of approved APIs regardless of source, look to API management. APIs have become central to our development efforts, and there will only be more of them in the future, so it is worth deciding where your org could use help and set out to research your options.

    Of course, you’re rocking it. DevOPs isn’t letting DEVops poke too many holes in the firewall; DEVops is cranking out solutions and devOPs is keeping them alive. This is just another tool to keep things on an even keel as more and more of the organization’s development is API-based.

  • Learning ‘The First Way’ of DevOps – Continuous Flow

    Learning ‘The First Way’ of DevOps – Continuous Flow

    Many organizations are struggling to realize well-engineered DevOps, even ‘the first way’ of DevOps – continuous flow.

    DevOps is an evolving body of knowledge. There is no one-stop shop that covers all roles and the complete range of skills required for DevOps. A DevOps-competent workforce requires an ongoing commitment to DevOps skills development and mastery. Enterprises must approach DevOps training strategically to leverage training resources to their best advantage.

    Learning Continuous Flow

    The first way of DevOps, continuous flow, is the foundation for DevOps.

    Why Is Learning Continuous Flow Important to Engineering DevOps?

    A knowledgeable, skilled workforce is needed to meet strategic objectives. Without a solid understanding of DevOps concepts and terminology, communication between people and teams is inefficient and a source of bottlenecks and misunderstandings. Developing hands-on skills for the tools and workflows is needed to understand and implement DevOps pipelines. There is an industry-wide shortage of skilled DevOps candidates. New skills foster innovation. Knowledge workers reduce production costs and reduce mistakes. Having skilled coworkers makes for a satisfying working environment. Employee retention is better. Competitive advantages are derived from knowledge.

    How Is Learning Continuous Flow Accomplished?

    The following are recommended engineering practices for learning continuous flow.

    People are encouraged to be continuous learners with an ongoing commitment to DevOps skills development. DevOps training is approached strategically to ensure DevOps training is well aligned to business goals. DevOps skills gap assessments are conducted and used to define and refine the training strategy. Leaders and cross-functional teams are encouraged to take DevOps fundamentals training. Leaders define a training strategy that best fits the needs and priorities of the organization to meet critical skills gaps.

    The training strategy considers which skills and roles can be covered by inexpensive self-study resources. Determine which skills and roles warrant more costly training. DevOps training has a distinct budget. Compliance to DevOps training programs are tracked. DevOps leadership training is offered to management and staff that have a role relevant to DevOps. DevOps tools training includes the recommended engineering practices for using each DevOps tool in the Service Catalog. Staff are encouraged and supported to take DevOps certifications that are relevant to their assigned roles.

    A DevOps training program is defined and includes a recommended curriculum for each role including leaders, developers, QA, Ops, and infrastructure and security staff that are operating in a DevOps environment. Recommended DevOps training resources are cataloged, and the catalog is visible for all stakeholders. Merit and recognition programs encourage employees to master DevOps skills.

    All staff is allocated time for DevOps training. DevOps mentoring programs supplement formal training. Job swapping and immersive training is encouraged and planned. People are encouraged to attend external conferences and meetups and share what they learn with other team members.

    What Is Needed to Implement Learning for Continuous Flow?

    The following are recommended engineering practices for implementing a learning program for continuous flow.
    Assign roles and responsibilities for DevOps training leadership (e.g., DevOps Sensei, Training PM, evangelist). Conduct a DevOps skills gap assessment. Define a training strategy that best addresses the gaps and fits the needs and priorities of the organization. Define a training budget that includes expenses and time allocations per role and skill.

    Determine which skills and roles can be covered by inexpensive self-study resources. Determine which skills and roles warrant more costly commercial training. Identify training goals for each role. Ensure job recruiting profiles match skill requirements for DevOps skills that are most relevant to the organization strategic goals. Put in place the means to make training resources visible and available. Set training goals for teams and individuals. Put in place incentives and recognition programs for completion of training.

    Some of the best sources of DevOps training resources are listed below:

    1. The DevOps Institute
    2. Partners of The DevOps Institute, such as Learning Tree International and Xellentro
    3. Udemy
    4. Recorded talks and publications available through IT Revolution
    5. Books such as my own Engineering DevOps, by Marc Hornbeek.

    What this Means

    Organizations need a trained workforce to succeed with DevOps—even ‘The First Way’ of DevOps—continuous flow. Organizations need to approach DevOps training strategically to leverage DevOps training resources to their best advantage. To learn more about my blueprint for learning all things DevOps, refer to my book Engineering DevOps.