devopsy.kinsta.cloud

Category: Blogs

China’s Open Source Activity Surged in 2020

Activity among China-based open source project contributors and creators surged in 2020, as Alibaba, Huawei, Tencent and other leading Chinese tech companies are playing an increasingly important role in the open source development community worldwide.

According to the recently released Open Source Contributor Index (OSCI) ranking, as of March 2021, Alibaba, Huawei, and Tencent collectively ranked in the top 20 worldwide for the first time. Rankings are based on the total number of contributors and contributions on GitHub. Microsoft, Google and Red Hat ranked first, second and third, respectively.

Alibaba, as well as China-based Pingcap, came within striking distance of reaching the top 20 worldwide open source ranking for 2020 measured in activity; the total number of forks, commits, stars, pull requests, issue comments and other metrics, according to the GitHub 2020 Digital Insight Report released in April.

Authored by X-lab in conjunction with East China Normal University, Kaiyuanshe, Shanghai Open Source Information Technology Association and other unnamed “scientific research institutions and open source community institutes,” the X-lab report revealed Pingcap’s eponymous Pingcap (a distributed relational database) and Alibaba’s AntDesign (a Microsoft React framework) activity metrics of 210 and 193, respectively, in 2020. Meanwhile, jwasham (an open source study plan detailing how to become a software engineer) ranked 20th worldwide with an activity metric of 234.

Open Elastic’s Kibana, recently forked by Amazon Web Services (AWS) and Kubernetes ranked first and second worldwide with activity metrics of 698 and 602, respectively.

Torsten Volk, an analyst for Enterprise Management Associates (EMA), says the increased popularity of and activity in China-based open source projects are proof that the concept behind open source software actually works.

“This is the classic ‘one plus one adds up to more than only two’ theory, and that applies to most companies anywhere in the world. And if it was possibly to gain advantages by only using open source code but not contributing, companies anywhere else in the world would have done so right from the start,” says Volk. “Remember that the core idea behind open source software is not to give out your secret sauce for other companies to enjoy for free, but to spend the least possible amount of funding on building commodity code.”

What, if anything, China-backed open source projects means for the community worldwide — as well as China’s influence in the industry in general – remain to be seen. Tencent, which entered the top 20 in March ranked by contributors in the OSCI study, for example, has become a leading supplier of components for machine learning (ML) databases in, for example, Kubernetes and cloud-native environments.

“This is great for everyone, and there is no benefit for anyone to purposefully not contribute to a project they benefit from. The benefit comes from your own contributions, in terms of reputation and credibility gain, across your industry. This motivates others to also contribute, as there is little to no benefit in keeping your own code secret while self-serving from the GitHub buffet,” says Volk. “As in the case of Kubernetes, your own company’s differentiation needs to come from the manner your proprietary apps [integrate] on top of this platform, or from the way you are able to integrate Kubernetes clusters with machine learning databases and other elements higher up the stack. And that’s why open source works.”

May 5, 2021
How to Spot SRE Adoption Barriers
It’s no secret that site reliability engineering (SRE) adoption is growing. The operating model, it seems, is pivotal for digital transformations across the enterprise. According to the Upskilling 2021: Enterprise DevOps Skills Report, 22% of respondents (up 7% from last year) cited SRE as the approach they need to continue automation in 2021.

Common Adoption Barriers

However, for some companies, adopting SRE principles and practices isn’t always easy. Ahead of the upcoming SKILup Day conference focused on SRE (Register for SKILup Day: SRE here), I asked several DevOps Institute Ambassadors and SRE subject matter experts to provide insights into the barriers of SRE adoption. Here’s what they shared:

Marc Hornbeek, CEO and Principal Consultant at Engineering DevOps Consulting and author of the book, “Engineering DevOps”

“The primary barrier for SRE adoption is executive vision and team alignment around a goal to transform to SRE practices. SRE affects the entire organization’s practices, roles and investment priorities. Without an executive sponsor, SRE transformations are not going to go far.”

Stephen Walters, Solution Architect at xMatters, Inc.

“Culture, and in particular, cultural change, is the greatest barrier to SRE adoption. As much as everything about the human race, the things that got us to being the creatures we are today, is about evolution, which is change, and we are not particularly good at it. Or, more specifically, the bigger the change, the more resistant we are to it. It has always been a great oxymoron in IT philosophy that in order to “transform,” you must change, but that transformation is occurring because we are not good at change. So it was with agile in the early days. Organizations wishing to transform to agile (small, iterative change) would do so under a transformation project, which would typically be waterfall (big bang). Big change, big cultural resistance. The key is to implement transformation in smaller, agile chunks. They are more easily accepted and testable, and also easier to roll back or adapt if they do not work or are not acceptable. All of the benefits of agile development apply to agile transformation.

The second greatest barrier is, then, “buy-in,” where the simple answer is, unfortunately, show the end user “what is in it for them.” This will typically override the enterprise-scale view of “what is in it for us?” but, over time, with any cultural transformation, this is one of the things that should change, iteratively, and also be a focus for developing a more holistic and empathetic culture.”

Shivagami Gugan, Chief Technology Officer at CX Tech Unicorn

“Any organization, irrespective of whichever level of maturity they currently exist on today, can adopt SRE and improve their business outcomes. However, the key underlying principles of SRE and its applicability should be understood properly. There is a lot of hype around transformation and the first barrier is about understanding what SRE means within your organizational context. I find most of the time, people try to imitate what highly mature companies like Google or Spotify or some other cloud-born company does, and this usually results in failures. SRE is the purest form of the implementation of DevOps. SRE is about removing the silos in a product life cycle to achieve business outcomes in a safer, faster, cheaper and better manner. If this is understood clearly, the first barrier gets removed.

The second barrier is this complicated vision of boiling the ocean – doing 100% Agile, 100% DevOps or 100% SRE. This doesn’t work, especially when you have heritage systems of records, on-premises services and heritage infrastructure and a whole lot of baggage built over several years (sometimes decades) which is the usual case for most companies. So be very clear in choosing target areas.

The third barrier is when you think SREs specialize in building operational reliability, but do not have anything to do with the development or the deployment phases of the life cycle. Reliability is everyone’s problem – the technical product manager, the developer, the tester, the support engineer; not just the SREs. The reality of the SRE role is to ensure services availability and reliability by supporting the other teams that own these services. SREs are enablers, they are collaborators, and their goal is to ensure that the services are overall resilient, reliable and that incremental value is delivered in a continual manner. When an organization understands that implementing SRE is an underpinning cultural change that affects all parts of the organization, then it becomes easier to remove the main barriers.”

Lisa Chan, Head of Software Engineering & DevOps at PETRONAS

“Not all organizations have the luxury of having an Ops team composed of skilled developers, which is a key success factor for the adoption of the SRE working model. In my case, I’m in an IT organization of 1,800 folks that has supported an oil and gas company since its inception 40 years ago. We serve a captive market of an integrated energy business with more than 100 companies under its portfolio. As a result, there is a legacy landscape of more than 2000+ applications. The IT organization still maintains the common “Dev is Dev, and Ops is Ops” anti-pattern. Even though we are in transition towards a working model that is more collaborative, it is unrealistic to expect our 300 Ops personnel to reskill themselves to be developers, because many of them have traditional skill sets along the typical Ops silos; e.g., networking, database admins, server admins, data center management, call center agents, etc.”

BMK Lakshminarayanan, Value Stream Architect at Bank of New Zealand

“Building the SRE practices and skills within enterprises are always challenging, as some are still embroiled with old ways of thinking. The thinking, associated techniques, available tools and limited skills are constraining SRE adoption in most enterprises.

Renaming the system admins to SREs neither helps nor makes SRE experts. Investing in expensive tools doesn’t help, either. Any adoption and transformation is a gradual process. A typical medium to large enterprise has a few hundred systems, applications and services with various operating systems to support, database platforms to manage and hundreds of application databases to monitor or administrate. To this complexity, add all the dependencies of other services and components, as well. Hence, redefining the SLOs, SLAs and SLIs for these services, automating everyday maintenance tasks, understanding the toil, building resilience and fault-tolerant characteristics within these systems and applications are uphill tasks for most enterprises.”

Identifying Other Common Adoption Barriers

Many other common barriers for enterprises are:
- Availability of up-to-date system and application information in a centralized platform
- Observable nature of legacy systems
- Understanding the dependencies and service levels (Promise Theory)
- Availability of the right tools for the right job
- Skills – old ways do not open new doors.
- Time – time and space for people to upskill, train and experiment.
Want to learn more about SRE and how to overcome these adoption barriers? Join us for SKILup Day: Site Reliability Engineering on May 20. Register here: https://devopsinstitute.com/sre-2021/.
May 5, 2021
Lock Down

May 5, 2021
How to Bring DevOps and Security Teams Closer Together

More often than not, there seems to be friction between DevOps and security teams. Despite having the same end goals of creating the most secure code and preventing any potential security pitfalls, these groups of professionals often lack the unity needed to accomplish these end goals effectively and efficiently.

In the interview below, Naomi Buckwalter, director of information security and IT at Beam Technologies, addresses this issue and outlines key ways development and security teams can come together to better accomplish their shared missions. She stresses the importance of security professionals reaching out a hand to their DevOps counterparts to teach them how to be security-forward when writing code. However, she highlights how not every security expert has a developer background, so it really takes these two groups of skilled tech specialists working in unison to fill those knowledge gaps for each other.

Naomi brings over 20 years of IT and security experience to her upcoming session “Six Things Developers Want From InfoSec,” at DevOps Connect 2021, during the RSA Conference. She will expand on some of the key topics discussed in this interview during her talk on May 19 at 4 p.m. EDT.

To see the full agenda and secure your free spot at the virtual event, visit the DevOps Connect website.

May 4, 2021
5 Steps to an Open Source DevOps Strategy

Open source technology thrives during times of mass disruption, and this pandemic has been no different. Across the board, companies are accelerating their digital transformation and DevOps strategies, looking to open source technology as a way to streamline operations. While deploying open source software (OSS) in DevOps can help organizations lower costs and avoid vendor lock-in, the tools are often not backed by an ecosystem that makes them transferable across the enterprise, leading to interoperability issues across the board and creating a haphazard workflow.

Before embarking on an open source migration, companies need to plan out their strategy. Following these five steps will help companies create an organized plan and a seamless open source stack so that they can capitalize on the lower costs and tap into the benefits of the open source community.

Determine if you Can Self-Support Your Strategy

A recent Gartner study determined that at least 75% of open source policies don’t yield effective results. This stat is largely due to companies believing that they can self-support their open source stack. However, as technology becomes increasingly complicated, companies should take a step back and evaluate if they actually have the right resources and skill sets to get the job done. Enterprise architects with open source expertise are a niche group that’s in high demand, so don’t worry if you don’t have the resources – there are plenty of trusted vendors out there who have a proven track record of delivering results.

Consolidate

Fewer vendors equal fewer problems. When evaluating potential partners, keep in mind that working with a few key partners (versus several) will be beneficial in the long run by ensuring that applications will work together seamlessly, while also avoiding vendor finger-pointing if they don’t. Assess potential partners to see which packages, application stacks and infrastructure they support, and what level of freedom you have to switch out various components. Avoiding vendor lock-in is key, as switching vendors will be a costly undertaking if you ultimately decide to go in another direction.

Invest in Security

Security is a major concern in enterprise open source software, and it’s critical to make sure you have the ability to act quickly on potential issues and vulnerabilities. Consider partnering with a vendor who specializes in OSS security, and can keep clients informed of the latest security updates and bug fixes to ensure that your program isn’t vulnerable to security threats. Having a security specialist on standby is a must-have for organizations so that when security is breached, it can be remediated immediately.

Pick the Right Tools

Not all tools are alike. There are plenty of options out there that can help elevate your open source strategy, but consider how each will affect your overall program. At each phase of your pipeline, test the open source tools selected to ensure that they can integrate together within the broader toolchain and every layer of your software stack, including databases, platforms and monitoring solutions. If you have questions about their connectivity, either consult with an expert who understands how the software will truly behave in various environments or engage with free apps that help developers determine if their tools are compatible across the broader stack. Doing so will help enterprises choose the right open source technology early on, saving both time and money.

Adapt

Open source implementation in DevOps is more than a one and done approach; it requires adapting and tweaking in order to stay relevant, keep a competitive advantage and optimize new technology. Ensure that your open source strategy can be improved to include new offerings and services that the company will implement down the road and that your vendors—or internal team—can modify the framework fairly easily when necessary.

While open source technology continues to drive innovation in the DevOps industry, including it in a company’s DevOps strategy requires thoughtful planning. When done right, an open source policy will save a company time, money and people power, allowing them to collaborate seamlessly with the greatest minds in the industry.

May 4, 2021
Low-Code/No-Code and Simple APIs

In recent years, implementing AI and IoT technologies has been top priority for many organizations as their leading-edge capabilities have become a requisite for digital transformation – but the speed of their adoption is greatly influenced by the flexibility of supporting software. Enter low-code, no-code programming and truly open APIs.

Low-code/no-code platforms are a promising alternative to traditional software platforms for non-technical business users; a more democratic approach to software development, built on either no or minimal code. The approach begins by minimizing external expenses and time required by outside developers or programmers as business analysts and line managers can now structure new process flows and functionalities.

This is coming into sharp focus, as the increasing need to get new applications to market quickly is coupled with a growing demand for digital transformation from the C-suite. But to access the benefits, organizations must ensure that their underlying software can integrate well with external systems—introducing application programming interfaces (APIs).

Low-Code/No-Code – The New Focus

Analyst predictions have revealed an industrywide trend geared towards these platforms, as 60% of CIOs are set to employ low-code/no-code tools by 2025, with plans to bolster their output capacity. Other analysts expect to see 65% of all application development taking place in low-code/no-code environments by 2024. But, it is the openness of APIs that will determine the success of this software.

APIs have reached new heights since the early days of component-based architecture, but today’s APIs are still inspired by Roy Fielding’s Representational State Transfer (RESTful) API.

APIs – Providing Essential Internal and External Openness

Some vendors will talk about how they have open APIs, but these are often limited and designed for specific, pre-determined integration scenarios. The application, in the meantime, internally communicates in a proprietary fashion that cannot be leveraged by external systems. To maximize the agility delivered by low-code/no-code tools, the entire application should be built on open APIs.

Enterprise applications can go a step further by relying on the ISO/ICE–approved OASIS Open Data Protocol (OData), making things even more interoperable with more choice, flexibility and capabilities for customers. When the application is built on the same set of RESTful APIs it exposes to other systems, it is even easier to access the precise spot in a value flow with which organizations need to integrate.

With the support of open APIs, there is an opportunity for companies to leverage low-code/ no-code tools and achieve crucial business returns in three ways:

1. Undisrupted Connectivity

A robust architecture built on RESTful Data APIs, documented according to the Open API Initiative specifications, gives organizations the ability to extend enterprise software on the outside to create task specific apps or connect to other systems.
This may simply be used for automating steps around onboarding a new employee; for instance, filling in a desk number in an office floor plan, initiating payroll activities and creating an Outlook account. It could also populate a serialized part structure from a machinery manufacturing process into the software that will be used to annually service that piece of equipment. Any data, action or event should be accessible in a clear and thorough API library.

With enough of these RESTful APIs, any number of low-code/no-code tools can be used to create targeted apps that interact with enterprise software and other systems running in a business. Commercial software offerings can be used to build an experience and drive processes in enterprise software.

2. Digital Transformation Accelerated and Uninterrupted

The main benefit of using RESTful APIs is that an organization’s external and internal systems can automate processes, expand access to data, and create extensions to their enterprise software on the outside. Regardless of whether an internal process automation (IPA) tool or external low-code/no-code process orchestration software is used, their ERP system should offer transparent access to the part of the system supporting any given integration or process automation.

Here’s where a low-code/no-code approach helps to develop new solutions and industry specific functionalities that can be built faster, cheaper and with higher quality. Integrating a low-code domain-specific language (DSL) into solutions not only helps create value faster, but also insulates organizations from future technology changes. The DSL describes the intent of what a component in the application (for example, an API) should do, rather than how it is technically done.

3. Increased Software Governance

Low-code/no-code tools are also more commonly used to tailor how enterprise software works internally, giving organizations more control over their software. Software providers might currently offer the ability to extend the data model or to tailor the user interface and user navigation flow through a process to an organization’s specific needs, using no-code tooling. But this is not enough.

Low-Code/No-Code: Go the Extra Mile

Enterprise software platforms should offer intuitive low-code/no-code tools that will not only automate process steps or actions, but add machine learning capabilities for intelligent process automation. This democratizes the creation of intelligent systems by putting it within reach of business analysts and line managers—a simple what-you-see-is-what-you-get.

Logical, Automated Processes

With the IPA capability embedded into software, any additional input needed from users can be captured automatically. These capabilities can then be further enhanced with intelligent parts, such as AI and machine learning models, to make choices inside the automation about what to do next (branching decisions), or predicting values to be filled in.

As the need to digitally transform continues to surge, enterprise solutions based on open APIs, strengthened by low-code/no-code programming, will become fundamental business tools—speeding up deployment times and delivering business value when it matters most.

May 4, 2021
Blips and Downtime: Incident Management 101
Nothing gets the blood pumping like seeing an IT incident alert flash across the screen. Is the network traffic anomaly a potential intrusion? Are we about to have an outage? Is it just a random blip on the radar? The implications of these different potential incidents vary wildly, and each requires a different set of response tactics.

Responding to incidents both large and small is essential for every team. Especially in a remote-first world, it is more important than ever to ensure that all developers are in the same war room to tackle the problem as efficiently and effectively as possible. It’s also critical to have a single view that aggregates data from all of the systems and services used to monitor and respond to incidents. But not every team has invested in a fully fledged incident management strategy.

In fact, it’s not uncommon for incident management to be completely ad hoc. Teams wait for something to happen and then take a “dive and catch” approach to incidents. Some teams have some processes in place, but those plans may be missing key components. In both cases, teams struggle with slower time to resolution and often waste resources in the process of responding to incidents. Critical stakeholders often suffer from a lack of clarity in communication around an incident.

Depending on the type of incident, the consequences can be challenging to overcome. Running afoul of a compliance law, like GDPR, can result in business-ending financial penalties. Incidents that impact uptime can keep an organization from meeting SLA terms and potentially losing customers and revenue. Regardless of the size of your company or customer base, formulating an effective incident response begins with people.

People are the Cornerstone of Incident Response

Companies should assess their business needs and the risk profile of their applications and services. With those barometers in place, leaders can then determine the appropriate staff levels to ensure 24/7/365 incident management coverage. The size and breadth of the team will depend on the size of the company and the structure of response plans, but the team should attempt to cover a few areas.

Ideally, a team has at least three responders.
1. Incident owner. This is the team’s quarterback. They coordinate everything, make sure the team follows runbooks, involves the correct people and removes roadblocks.
2. Incident investigator. The investigator has their hands on the keyboard. They run the investigation, pull and analyze logs, review metrics and generally try to determine how to best mitigate the issue.
3. Incident communicator. Smaller teams may not have the personnel to have a designated communicator in every incident. On those teams, the incident owner will often assume this role, as well. Communicators focus almost exclusively on two tasks: documenting the incident via an “incident timeline” and communicating with stakeholders when appropriate. It’s critical that a complete timeline is built during the incident. It’s nearly impossible to put together a properly documented incident timeline after the fact. Critical details will get lost or forgotten, and your retrospectives and RCAs will be low quality.
Runbooks offer Muscle Memory During Incident Management

The incident response team, no matter how experienced, will need a set of runbooks—a compilation of processes and steps to take when incidents arise. Runbooks will help guide teams as they perform everything from analyzing and mitigating common problems, to post-action investigations. They represent the process portion of incident responses, and act as a guidebook for the team when the pressure is high.

Typically, an alert system will ping the on-call engineer about a metric that doesn’t look right. The runbook will help that on-call person determine if the alert should be categorized as an incident or not. When that person determines the alert indeed represents an incident, they must estimate the severity of the incident. Different teams may use different definitions for severity, but here is an example:

Severity one – Production down or highly degraded.
Severity two – Serious bug impacting customers or system stability.
Severity three – Important bug. Requires tracking until mitigation, but likely not a 24/7 workstream.

Runbooks can also guide teams through analysis of the situation. After a root cause is determined, the book will remind teams to perform an immediate post-action investigation to see if specific processes worked well, if gaps exist, and if communications were sent out to customers or other stakeholders.

Tools are Important; Tying Them all Together is Crucial

People and processes are important for responsive incident management. Without the right tools, even seasoned incident-management veterans may struggle with the complexity and pressure of an incident. Tooling can prevent a lot of mistakes and omissions when the heat is on.

There are numerous platforms that address different components of incident management response. Depending on the size of the organization, teams will need some or all of the following:
- On-call rotation management
- Observability and alerting
- Ticketing system
- Communication system
One of the biggest challenges in incident management is having the ability to tie together the data and actions defined by this broad toolset. If you’re working a severity level one incident, teams will likely rotate people into and out of the incident based on their geographic location and timezone. How does the next person in the rotation come up to speed on what’s been done so far? How do we document a detailed timeline that can be used for an RCA investigation later? How can we provide an up-to-the-minute view of the status of an incident for key stakeholders? Ideally, teams will have a single place where all of this data is collected and managed and where the data can be filtered and exported at the end of the incident.

Effective Incident Management: People, Processes and Tools

Is that traffic spike a sign of impending doom, or just another meaningless bump? Without the proper people, processes and tooling, answering that question becomes very difficult. Unfortunately, the wrong answer can lead to disastrous consequences. Only with the right set of tools and processes can companies develop an incident response system that provides maximum stability and keeps customers happy.
May 4, 2021
DevOps Practices Gap Assessment

Using DevOps to continuously deliver software has proven value for organizations that are on a path towards digital transformation and continuous improvement. To get the maximum value from DevOps, it is important to use recommended best practices, inclusive of people, processes and technologies. A gap assessment is a great way to efficiently evaluate an organization’s practices for DevOps, and determine a strategy for improvement. Gap analysis provides valuable inputs for formulating a strategy and roadmap to improve a topic including DevOps.

My SlideShare, Gap Survey, Assessment and Analysis For DevOps, explains how my Nine Pillars Gap Assessment Tool greatly speeds up the gap survey, gap assessment and gap analysis process for DevOps.

It is important to clarify a few definitions for this blog, because I have found that different people and organizations use these terms differently. In this blog, and in my consulting work, I use the following definitions.

• Gap survey is a discovery tool used to collect information about the current state of practices for a topic.
• Gap assessment is a process to determine differences (gaps) between current practices and recommended practices for a topic. Gap assessment is also used to refer to the entire collection of activities in this list.
• Gap assessment workshop is a meeting in which the gap assessment is validated prior to gap analysis.
• Gap analysis is the process of determining priorities for reducing gaps found during a gap assessment.
• Gap assessment tool is software that helps perform gap surveys, gap assessments and gap analysis.

For those that want to dig deeper on this topic, additional definitions and contextual information related to the way I do gap assessments are clarified in my book Engineering DevOps.

I define a seven-step process for gap assessments. The steps are as follows:

1. Pick a topic to analyze. The same processes and tools can be applied equally well to almost any topic.
2. Determine recommended practices for the topic. Something that is worth doing a gap assessment for, such as DevOps, will normally be fairly complex with dozens, if not hundreds of practices. Categorize the practices into groupings (I call the groups “pillars”) to make the list of practices more understandable and meaningful. To do this will require some research and work. For example, I have a database of practices and pillars for DevOps, continuous testing, DevSecOps and SRE and some other topics such as DevOps.
3. Enter the practices from step two into a gap assessment tool. The tool can be a simple survey tool you create, a commercial survey tool or something custom-made.
4. Determine who needs to be included in the gap survey.
5. Collect data using the gap survey.
6. Perform a gap assessment.
7. Perform a gap analysis.

For the remainder of this blog, I explain the above seven steps for DevOps.

Step one: Pick a Topic to Analyze
In this blog, the topic is DevOps.

Step two: Determine Recommended Practices for DevOps
For an example DevOps assessment, I used the practices under the nine practices categories described in a blog that I co-authored called Nine Pillars of DevOps Best Practices. The nine practice category pillars are:

• Leadership
• Collaborative culture
• Design for DevOps
• Continuous integration
• Continuous testing
• Continuous monitoring
• Elastic infrastructure
• Continuous delivery
• Continuous security

Step three: Enter the Practices from Step Two into a Gap Assessment Tool
A gap assessment tool, pre-loaded with a sample of DevOps practices, in a file called DevOps Assessment, can be downloaded for free from one of the resource pages found on my website Engineering DevOps. You can edit the practices categories and add/delete practices from each category if you prefer to make changes.

Step four: Determine Who Needs to be Included in the Gap Survey
For the gap analysis to be comprehensive, people in roles that are affected by DevOps practices need to be surveyed, or at least represented, to ensure their perspectives are included. The following are example roles that typically are included.

• Business leaders – because they influence culture and budgets for DevOps.
• Developers – because they need to design in accordance with DevOps practices.
• Project owners – because they influence product work priorities.
• QA testers – because they need to test in accordance with DevOps practices.
• Ops – because DevOps practices affect operations.
• Security – because DevOps affects security practices.

The survey can be conducted for an individual application, a group of applications, or all the applications in the enterprise. However, it is important that the gap assessment and gap analysis be performed on the organization segment that is being targeted for improvement.

Step five: Collect Data Using the Gap Survey
A gap survey should allow each surveyed person to enter an importance level score, a practice level score and comments for each practice. All this information is essential for the gap assessment and gap analysis. In the gap survey included within my gap assessment tool, survey respondents are asked to score the importance of each practice as one of 0=not relevant, 1=not important, 2=nice to Have, 3=important, 4=very important or 5=critical. Practice level choices are 0=not sure, 1=rarely, if ever, 2= sometimes, 3=most of the time, 4=always or 5=We are really good at this. Comments that are relevant to qualify or explain the scores entered for each practice should also be entered, especially if there is any doubt or ambiguity.

Step six: Perform a Gap Assessment
The gap assessment process requires all the practices scores collected from the surveys to be collected and assembled to calculate an aggregate set of scores. Gap scores are calculated using a formula that weights each practice level score with the corresponding importance level score. A visual representation helps to identify practices areas and individual practices that have the highest, most important gaps.

No matter how professionally written the practices and score definitions are, it is not unusual for some people to misunderstand and to enter scores that they would not have otherwise. For this reason, it is important to ensure that the data collected is validated before conducting the gap analysis. The preferred approach is to conduct a gap assessment workshop with key representatives from each role that participated in the survey. During the workshop, the scores for each practice that have a high deviation between survey responses are discussed and, if necessary, adjusted.

Step seven: Perform a Gap Analysis
The gap analysis process involves extracting the high gap practices and tagging and ranking each of them against solution categories determined by a consultant or topic expert.

The results of the gap analysis indicate where solution strategies and implementation roadmaps need to be focused to reduce the most important gaps.

What This Means

While it is true you can easily stand up DevOps tools quite quickly, this alone will not realize the benefits of following effective and safe DevOps practices. Those who are serious about DevOps will do well to learn from others, and be serious about using recommended DevOps practices. This blog explained a gap assessment approach, which uses my nine pillars of best practices for DevOps. My free DevOps gap assessment tool facilitates getting a gap analysis for DevOps and priorities to improve DevOps practices for an organization.

May 4, 2021
Live Fireside Chat with Christopher Krebs: How to Combat Disinformation

We live in a digital world where most information is now found online. This makes it increasingly difficult to verify the veracity of information. Threat actors have been taking advantage of the digital landscape to spread disinformation, propaganda and conspiracy theories to manipulate the public and sow doubt, discord and chaos. How can we distinguish between fact and opinion, truth and supposition? How can we spot fake news and tackle disinformation?

Former Director of the Department of Homeland’s Cybersecurity and Infrastructure Security Agency (CISA) and Co-Founder of Krebs Stamos Group, Christopher Krebs, will be speaking about disinformation at this year’s DevOps Connect: DevSecOps on May 19 at 12:00 p.m. EDT. During his keynote session, Krebs will explain what disinformation is, how to recognize fake news and the challenges disinformation poses to cybersecurity teams. He will reveal effective ways to combat disinformation, and how public and private partnerships can help. Krebs will also be answering questions from the audience during the live Q&A session.

Krebs is a founding partner of the Krebs Stamos Group, and previously served as the first director of the federal CISA for two years. Before that, he served in various roles at the Department of Homeland Security (DHS), responsible for a range of cybersecurity, critical infrastructure and national resilience issues. He has also directed U.S. cybersecurity policy for Microsoft and advised industry and government clients on complex cybersecurity and business risk matters while serving in positions with Obsidian Analysis and Dutko Consulting.

DevOps Connect: DevSecOps has been part of the RSA Conference for six years in a row. This year, the main focus of the event is on “Securing the Cloud Native World.” Krebs has joined a stellar lineup of DevOps, cybersecurity and IT thought leaders as the DevOps Connect 2021 featured keynote speaker. Attend his live session, “Disinformation: As Dangerous as Cyber and Physical Threats,” and check out all the other breakout sessions to learn more about cloud security, DevSecOps, cybersecurity threats—such as disinformation—and more.

For more information and to register for free, visit the DevOps Connect 2021 website. Save your spot today and learn how to better secure, monitor and maintain the security of your systems.

May 3, 2021
Why Real-Time Asset Intelligence is a Must

Complexity breaks correlation. Intelligence brings cohesion. This simple principle is what makes real-time asset intelligence a must-have for AIOps that is meant to diffuse complexity. To further create a context for the user, it is critical to understand service dependencies and correlate alerts across the stack to resolve incidents.

Why not just CMDB?

CMDB systems have been useful to break down configuration items into logical layers. But that is not enough, because they can become outdated very soon.

That is when connectivity among assets and their dependencies matter to remain relevant in real-time. This opens new possibilities for an enterprise to tap into. IT monitoring, change management, asset management and dependency mapping for troubleshooting are some areas that have a direct positive impact when enterprises have access to real-time asset intelligence linked to CMDB.

If your CMDB is not accurate with data management systems, it is time you start exploring asset intelligence and asset discovery tools.

Why is Asset Intelligence Critical to AIOps?

Asset intelligence is a critical part of AIOps. Unless you have a log and know about the assets that you have and how they are connected to each other, you cannot correlate to each other very easily. And that’s why real-time asset intelligence is required.

Third-party asset and dependency intelligence is an obvious next step, but those come with more challenges and complexities. Depending on a third party for asset and dependency intelligence would require a continuous feed of data on a regular basis. This process gets expensive and obsolete quickly.

Real-Time Asset Intelligence opens other Possibilities

With automation and discovery tools, CMDB can be kept up to date, in real-time. Real-time asset intelligence with automation enabled by AIOps opens many possibilities, and it contributes many benefits to an enterprise. These include:

IT Monitoring

For alerts and notifications, just a monitoring tool is not enough. The information sent by such a monitoring tool is not up to date. People rely on manual feeds, which are expensive and are not synchronized. Asset intelligence brings forth deep information that builds context which would otherwise be missing. Asset intelligence can point to issues corresponding to servers, topologies, networks, storage, apps or services.

Risk & Compliance Management

An organization must audit IT assets periodically to eliminate risks from the end of life/end of support cycle, vulnerabilities and ensure compliance with regulations and local governing laws. IT asset information is also maintained in many different places and in various forms, in spreadsheets, databases, ERP or CRM, or other systems, which makes it difficult to gather this information. All these challenges can easily increase compliance and vulnerability risks for any organization. AIOps tools automate the process of data collection, analysis and reporting, significantly reducing the operations costs while improving the accuracy and timeliness of the insights.

Change Management

No one has a clue if anything changed in the IT infrastructure. And, even if something does change, no one will know unless updates are alerted and stakeholders notified. With asset intelligence, you will not only know about the change, but before making the change, the solution will also tell you if a change is – or needs to be – made to a business service, as well as that change’s impact on other dependent business services. This helps you evaluate the impact and take measures to contain the blast radius before making any changes.

Asset Management

Asset intelligence provides a 360-degree view of asset inventory, dependencies, life cycle, performance, utilization and compliance. It provides thorough insight into, ‘What do we have versus what is out of date?’ You get to compare those states and inform compliance.

Dependency Mapping

AIOps-enabled asset intelligence also allows for dependency mapping, which is especially useful for troubleshooting work. With machine learning and artificial intelligence, complex environments can be quickly and more easily deciphered, and troubleshooters would know where issues lie. Asset intelligence tells the troubleshooter the most complex part of the problem and what should be addressed or what needs more attention. It maps dependencies that are affected by alert correlation, triaging, planning, and ticket resolution.

May 3, 2021