Category: Blogs

  • Perforce Melds Artifact Package Manager with Version Control Platform

    Perforce Melds Artifact Package Manager with Version Control Platform

    Perforce Software has added a universal package manager, dubbed Helix Artifacts, to its portfolio that enables users of its Helix Core version control platform to store and track source code.

    Gerhard Krüger, product manager for Helix Core digital asset management at Perforce Software, said the goal is to enable DevOps teams that employ Helix Core to access a package manager without having to exit Helix Core.

    That approach also provides a more secure and cost-effective way to store, consume and distribute artifacts that also serves to improve developer productivity, he added. The ability to manage artifacts on top of a version control platform also means DevOps teams will not need to set up additional storage infrastructure or configure separate security permissions just to distribute software packages, noted Krüger.

    Perforce

    Helix Artifacts is a self-hosted package manager that functions as a translator for packages such as NuGet, Maven or Docker that enables them to communicate directly with Helix Core as well as build systems and integrated developer environments (IDEs). Helix Artifacts is made available via a per-server subscription model that costs substantially less than rival approaches to managing artifacts, Perforce Software claims.

    Most DevOps teams are trying to strike a balance between employing best-of-breed tools to build applications and the need to reduce complexity and, ultimately, cost. As such, any time a tool becomes a feature of another platform that a DevOps team uses, there will be a review of the processes being employed. Many DevOps teams are trying to reduce the amount of time they spent maintaining tool integrations.

    There’s also now a lot more focus on software supply chain security. Each new tool generally creates yet another set of credentials that need to be protected as cybercriminals continue to aggressively attempt to inset malware into applications before they are deployed in a production environment. It’s not clear to what degree DevOps teams are looking to consolidate toolchains, but given those rising security concerns, it’s only a matter of time before security teams start to ask why the DevOps toolchain attack surface is so wide.

    In the meantime, the number of organizations that have widely embraced DevOps best practices across the enterprise continues to steadily grow. Over the past decade, most organizations have had at least one application development team embrace DevOps. However, as the pressure to build software to drive digital business transformation initiatives has steadily increased since the onslaught of the COVID-19 pandemic, the need to apply DevOps best practices to accelerate application development has become more pronounced. As a result, more organizations than ever are looking to standardize their application development efforts on a smaller number of platforms to reduce friction.

    It’s too early to say whether the rate at which applications are being developed and deployed since the start of the pandemic has actually increased. The one thing that is certain, however, is the bulk of organizations are now trying to accelerate like never before.

  • Why an Embedded Analytics Maturity Framework is Essential

    Why an Embedded Analytics Maturity Framework is Essential

    Contextual analytics, or embedding analytics directly into a business application’s transactional environment and core workflows, is the most sophisticated stage of business intelligence (BI) currently available to organizations today. It is one level ahead of the traditional integration of analytics, which is a standalone capability presented as a separate dashboard or reporting module.

    Today, there is an increasing shift among organizations toward embedding transactional analytics into their enterprise applications. Because contextual analytics is the most advanced option in the market, there is also an increasing need for assessing our analytics readiness first.

    The fundamental difference of contextual analytics lies in how it offers analytics to the user to explore data or derive insight within their transactional environment rather than accessed as an external tool. This approach requires a deeper evaluation of the product’s analytical maturity level using a formal framework. Having such a framework can act as a deployment guide for your developers for every stage of embedded BI implementation, including contextual analytics.

    But first, what makes contextual analytics so different that it necessitates a readiness evaluation?

    Contextual Analytics Vs. Embedded Analytics

    With contextual analytics, dashboards, reports and charts are no longer separated but are part of the main user experience. This integral change necessitates a closer look at your data and integration capabilities to align what it brings with all aspects of your software, including existing analytics.

    Embedding these elements directly into core software workflows isn’t a replacement for any existing analytics, but is instead another big step toward making data and analytics a more seamless part of your end users’ everyday work.

    It should be stressed that contextual analytics accommodates various levels of implementation and business requirements. Analytics can be embedded lightly, such as in the form of basic in-line charts and graphs users can see as they explore your software, or embedded deeper to offer AI-assisted insights and real-time alerts that trigger action from users while they work. It can be integrated with an experienced BI vendor partner or in-house if you possess the skill set internally.

    Avoidable Pitfalls of an Improvised Approach

    The need to assess your application’s analytical maturity and readiness for embedding analytics directly into the transactional workflow comes down to avoiding unnecessary BI roadblocks. 

    For many organizations, BI and analytical capabilities are traditionally lower in priority than other aspects of the software. Intending to add BI features later is well-meaning and understandable, but leaving developers to add in features intermittently and leaving it to your users to demand them when needed creates an issue of visibility. Vendors typically lose sight of what their application currently is capable of analytically, or what development needs to make the addition of a new feature not only technically achievable but worth the time and cost investment.

    If you take the time to reassess your application’s analytical capability, your developers and leaders can better understand that your product could be at an earlier stage of readiness than previously believed, and prepare accordingly before seeking out a contextual or other BI solution.

    For example, approaching contextual analytics ad-hoc could mean you find an unexpected older dashboard module, a cost that could have been accounted for in a formal maturity assessment. 

    What it comes down to is this: Implementing a basic dashboard module or data export feature, completely separate product features, is fundamentally different from fully embedded analytics in your users’ core workflow experience. Pursuing a formal evaluation to guide the introduction of contextual analytics—or even a form of embedded analytics at an earlier stage—means your users and product receive the best type of analytical capability your business is ready for today.

    The Five Stages of Embedded Analytics Maturity

    Based on our experience, there are five possible stages of product development, as illustrated in the embedded analytics maturity curve below. As contextual analytics is the final, most advanced stage of an embedded analytics integration available to product owners, the need for a formal assessment of maturity is most important, should it be the target state.

    Accelerating the implementation of contextual analytics comes down to your skillset, which will allow you to identify and evaluate your state of readiness accurately and determine a BI solution’s flexibility. If you do not have the internal expertise, implementing contextual analytics is easier with the help of specialized BI vendors that can help you in your assessment, and offer a contextual analytics platform built around openness. We recommend you look for vendors and partners that allow for:

    • Advanced APIs that lower total integration time and ensure the need to rearchitect the software is minimal to zero.
    • Customized experiences to make your desired contextual linkages, such as showing a user a relevant embedded chart when they click on a table of a client, possible.
    • An open platform that allows for options for on-premises, cloud, multiple operating systems that guarantee long-term security, scalability and flexibility with your analytics.
    • Rapid adaptation to your product development roadmaps with automated processes and administrative tools to lower total cost of ownership
    • White-labelling to make the rebranding and blending of the analytical solution and your native application components seamless.

    Ultimately, having an awareness of your product’s readiness and taking the time to examine your application’s current state means you avoid costly integration mistakes, save time and ensure developers implement the best solution according to your exact needs now.

  • A New Era of Observability, Monitoring and Analytics for DevOps

    A New Era of Observability, Monitoring and Analytics for DevOps

    [pdf-embedder url=”https://devopsy.kinsta.cloud/wp-content/uploads/2022/02/a-new-era-of-observability-monitoring-and-analytics-for-devops.pdf”]

  • 4 Tips To Plug The Cloud IT Skills Gap

    4 Tips To Plug The Cloud IT Skills Gap

    Technical talent is few and far between. The programming world faces a developer shortage, and with this shortage comes a lack of cloud know-how. By now, most organizations have become multi-cloud, yet 86% of IT professionals believe a lack of these skills will slow down cloud projects.

    As more teams transition from older architectures to cloud environments, the IT skills gap could pose a severe bottleneck to software development and deployment. Cloud servers require ongoing maintenance, and managing security and compliance is challenging, even for seasoned developers. Furthermore, it’s easy to overspend in the cloud—without keen insight into vendor nuances, it becomes challenging to select the most cost-effective package for the application at hand.

    I recently talked with Joe Spurrier, chief technology officer and co-founder, cloudtamer.io, to see how teams can improve their cloud strategies while navigating a short supply of IT cloud know-how. According to Spurrier, increasing automation, sharing reusable templates, centralizing best practices and maintaining agnosticism are strategies to amplify cloud results. Below, we’ll expand on these areas to see how they maximize cloud benefits while retaining a lean engineering footprint.

    Automation, Automation, Automation

    “Automation is key to furthering your adoption and use of the cloud,” said Spurrier. The drive to automate comes as no surprise to many DevOps and SRE professionals whose goal is to automate their job away. When automating the cloud, infrastructure-as-code (IaC) is a fundamental necessity. “If you’re getting into cloud, you should probably have some scripting skills,” said Spurrier.

    Automation can significantly aid scalability when setting up additional accounts since engineers must replicate similar operations, such as server provisioning, deployment patterns, monitoring and so on. Automation is also essential for shift-left testing and to increase observability into production environments. “It’s one thing to deploy an application via automation, but another to have tests in automation—that’s the next level,” said Spurrier.

    Now that so many tools are API-driven, orchestration becomes programmable. A cloud service provider’s CLIs or SDKs could also be leveraged to hook into these integrations to construct such automation.

    On the flip side, too much automation for high-level privileges could backfire. “Someone could break into a data center, steal a server, disconnect it, then run off,” Spurrier explained. Thus, automation will require a higher sense of security to ensure that every change is appropriately authorized and logged.

    Reusable Templating

    Along with automation, documenting operational processes to be shared amongst engineering teams is vital for maximizing efficiency in a lean talent landscape. The key here is to make the process self-documenting and reusable, stresses Spurrier. This will most likely involve someone on the team creating shared libraries and repositories for other team members to leverage.

    One such example is Amazon’s golden AMI pipeline. Golden AMIs are virtual machines that teams can “standardize through configuration, consistent security patching and hardening.” Golden AMIs can also enable a repeatable process for performing monitoring, logging and even distribution to business units.

    Reusable patterns are important for building CI/CD systems so that when you commit code, it is automatically deployed to preferred cloud providers. In general, Spurrier recommends building shared repositories that are easy to clone, with step-by-step instructions for usage. Sample applications that demonstrate components in different languages can also aid developer usability and save time.

    Adopt Centers of Cloud Excellence

    Another way to encourage better adoption is by creating a center of cloud excellence (CoCE). For an enterprise, having a cloud-centric project management group can be very helpful to organize knowledge and offer support. A CoCE could centralize operations, supply engineers with pre-configured containers and help distribute access to cloud accounts.

    A CoCE is a good way to start to unite disparate teams around shared best practices, said Spurrier. Depending on your organization’s needs and workloads, a CoCE will focus on varying skills, he added. In the beginning, a company may have just one center for cloud knowledge. However, as adoption grows, dedicated centers may likely emerge around specific cloud providers, too.

    Retain Agnosticism

    Contrary to popular belief, multi-cloud steups aren’t always about lift and shift. Business units often adopt a particular cloud to suit specific workload requirements. For example, researchers may choose GCP for its data science functions, or Microsoft shops may prefer Azure.

    In a multi-cloud world, management layers could help retain a modicum of vendor neutrality. For example, take Cloud Custodian, a tool developed at Capitol One and recently contributed to the CNCF. Using Cloud Custodian, engineers can run security checks across AWS, Azure and GCP and generate metrics for reporting. Such control and insights could empower teams to automate some of the multi-cloud management burdens.

    When working with multi-cloud, it’s also good to consider agnostic tooling that can work across different providers, like Terraform or Kubernetes, Spurrier said.

    Templating

    Cloud transformation is ongoing at most organizations. With this rise, more cloud-native processes and tools are emerging. Yet, with talent in short supply, DevOps isn’t always fully prepared. To review, we covered four ways businesses can circumnavigate this issue to get an edge:

    • Increased cloud automation is a necessary response to a slimmer labor pool. Though building automation requires upfront technical skill, it pays dividends in increased efficiencies.
    • Reusable libraries and templates can rapidly configure new projects and do so consistently across business units.
    • Consider maintaining a center of cloud excellence to centralize policies and offer support.
    • Opt for agnostic tools. This helps to retain vendor neutrality and apply consistent controls across clouds.

    Of these above strategies, Spurrier emphasized the importance of creating shared templates. When used right, a templating approach can be very effective, he says. “If you have a templating model, it should be easy for DevOps teams to migrate to new features. If you’re leveraging tools that set up templates, it’s easier to figure out how much infrastructure is going to cost.”

  • Sumo Logic Extends Observability Scope and Reach

    Sumo Logic Extends Observability Scope and Reach

    During the online Illuminate user conference, Sumo Logic revealed how it is integrating capabilities it gained with the June 2021 acquisition of Sensu, a provider of open source monitoring tools, with its continuous intelligence platform in addition to adding support for data collected via open source OpenTelemetry software.

    Sensu Go, a set of tools for implementing monitoring-as-code, is now a core part of the Continuous Intelligence Platform. The company is also now making available in beta Sumo Logic OpenTelemetry Distro and Ecosystem Support, a single agent through which all logs, metrics and traces can be collected from instrumented applications. Sumo Logic is also supports the AWS OpenTelemetry Distro, an offering from AWS that provides similar capabilities. Sumo Logic has also increased the capabilities of Sumo Logic Free to include monitoring-as-code tools created Sensu.

    Bruno Kurtic, vice president of product and strategy, said as responsibility for managing applications shifts left toward developers it’s critical to provide observability capabilities that can be programmatically infused into applications. As part of that effort, Sumo Logic is now also offering Sensu Plus, which provides access to an analytics engine for the data the platform collects.

    Sumo Logic is also adding machine learning algorithms to provide more context to the alerts the platform generated via an Alert Response feature that is part of the core platform.

    The company is also adding support for the operator software that Red Hat created to make it simple to deploy Sumo Logic Continuous Intelligence Platform alongside the Red Hat OpenShift platform for building and deploying applications on top of Kubernetes clusters. In addition, Sumo Logic is also providing integration with a total of 38 either new or updated observability applications that integrate with a wide range of third-party platforms.

    Finally, Sumo Logic is extending the security observability platform it provides based on its platform to add support for containers and serverless computing functions alongside virtual machines and integrations with third-party endpoint detection and response (EDR), network detection and response (NDR), threat intelligence and managed detection and response (MDR) platforms. The company has also added or updated 26 applications for specific third-party platforms.

    Kurtic said Sumo Logic makes it possible for developers and IT operations teams alike to observe an IT environment on an end-to-end basis via a single pane of glass. In some cases, the members of an IT operations team will require a user interface to manage that environment. Developers, meanwhile, might prefer an application programming interface (API) through which observability data is made accessible from within a continuous integration/continuous delivery (CI/CD) platform.

    Regardless of the type of user, however, IT teams should not have to hire their own data science team to analyze observability data. Instead, the observability platform should embed machine learning algorithms that surface all the benefits of data science without the need to hire additional headcount, he said.

    One way or another, DevOps teams will soon routinely benefit from the additional levels of context that observability platforms provide. The challenge will then be determining how best to fix a raft of issues that many DevOps teams today simply didn’t know existed.

  • CloudBees Acquires Neuralprints to Shift Compliance Left

    CloudBees Acquires Neuralprints to Shift Compliance Left

    At the online DevOps World 2021 conference today, CloudBees revealed it has acquired Neuralprints to provide the core technology for CloudBees Compliance, a real-time compliance and risk analysis platform that it will roll out in the first quarter of 2022.

    At the same time, CloudBees has enhanced the feature management capabilities of its namesake continuous integration/continuous delivery (CI/CD) platform to provide greater visibility into and control over feature flags that are now widely used to add new capabilities to applications.

    Prakash Sethuraman, chief information security officer (CISO) for CloudBees, said CloudBees Compliance will make it possible for DevOps teams to continuously enforce compliance policies as part of an effort to better secure their software supply chains. Those DevOps teams will be able to enforce compliance across code, binary artifacts, data, identity and infrastructure environments in a way that provides developers and IT operations teams with instant actionable feedback to enable issues to be addressed long before an application is deployed in a production environment.

    CloudBees Compliance is based on a mix of open source and proprietary technologies developed by Neuralprints and will be made available for on-premises IT environments as well as via a software-as-a-service (SaaS) application. The goal is to enable organizations to manage compliance as code as part of any effort to shift more responsibility for application security further left toward DevOps teams, said Sethuraman.

    CloudBees Compliance

    A survey of 500 C-level executives published today found nearly half (45%) admit that initiatives to secure their software supply chains are halfway or less-than-halfway complete. Nevertheless, 95% claimed their software supply chains are secure (95%), with more than half (55%) posting they are very secure.

    A full 93% said they are prepared to deal with an issue such as ransomware or a cyberattack on their supply chain. However, nearly two-thirds (64%) admitted they are not sure who they would turn to first if their supply chain was attacked; with 58% admitting that, if they experienced an attack, they have no idea what their company would do. An equal percentage (64%) said it would take more than four days to fix the problem if they did experience an issue.

    Almost all C-level executives (95%) said they think more about securing the supply chain now than they did just two years ago, and 92% said a security issue would impact their brand. A total of 83% said security issues cause their developers to drop everything to review code, with 82% noting that caused the organization to spend less time on innovation.

    On the plus side, 95% of executives said container images are checked for high or critical vulnerabilities, while an equal number said automation access keys are set to expire automatically. A total of 92% said their company only accepts commits signed with a developer GPG key, while 90% said dependencies to trusted registries are limited at their organization, while 89% said administrative access to CI/CD tools is restricted (89%).

    Of course, what C-level executives believe and what actually occurs inside an organization are not always one and the same. A series of high-profile software supply chain breaches resulted in a number of organizations reviewing their software supply chains. At the same time, the Biden administration has issued an executive order requiring all federal agencies to conduct similar reviews.

    One way or another, most organizations will soon find themselves embracing a wider range of DevSecOps best practices to ensure the integrity of software supply chains no matter how secure they may think their software development platforms are today.

  • Red Hat Extends Scope of Ansible Automation Ambitions

    Red Hat Extends Scope of Ansible Automation Ambitions

    During the online Ansiblefest, Red Hat announced the availability of a preview edition of Red Hat Ansible Automation Platform 2 that is intended to make it easier to automate IT processes at scale.

    Richard Henshall, senior manager for Ansible product management at Red Hat, said previously most IT teams have been automating individual processes, but as organizations become more adept at creating playbooks to automate processes, they now need to find ways to manage multiple automations that are often dependent on one another.

    Ansible Automation Platform 2 also enables IT teams to automate processes that span both monolithic as well as cloud-native applications based on containers using an automation controller, formerly known as Ansible Tower, that is more tightly integrated with Red Hat OpenShift, an application development and deployment platform based on Kubernetes, using Red Hat Operator tools. There is also an automation mesh capability that connects disparate automation components together and provides status checks.

    Ansible Automation Platform 2 also introduces automation execution environments within Ansible Engine that make it possible to create self-contained automation spaces that can be easily replicated and repeated across an organization.

    Red Hat also includes an automation content navigator to helps teams validate that automation content is working as it should across even the largest environments, along with updates to the Red Hat Insights analytics service that enable issues that might occur with automation controllers to be surfaced and eliminated by automatically applying policies.

    Henshall said going forward, IT teams should expect to see Red Hat focus more on enabling events to be the catalyst for triggering automation. Today, most automated processes begin with an IT administrator triggering the process. However, as digital business transformation initiatives mature, it’s become apparent there will be a need to trigger automation when specific events occur.

    Henshall said while there are still many organizations that are just starting to automate IT processes, there are also many that are entering the next phase of maturity. As such, they now require an automation platform that makes it simpler to manage automation at scale.

    In general, Ansible is designed to make it possible for developers and IT operations teams alike to declaratively create automation without much programming expertise required. However, creating a playbook that works reliably still requires a deep understanding of the processes that are being automated. Most IT teams would be well advised to closely monitor processes when they are first automated to make sure they are performing tasks as anticipated.

    Ultimately, it’s now a question of when rather than if most IT processes will be automated. DevOps teams, of course, have always been at the forefront of automation, but now it’s clear that as IT environments become more complex—with the rise of both the cloud and edge computing platforms—enterprise IT teams need to embrace automation more aggressively. The biggest barrier to automation is simply finding someone who has the passion to automate a process to lead the charge, said Henshall.

    Naturally, most of those efforts will initially focus on repetitive, tedious and manual IT tasks, but the potential to automate IT processes at levels of unprecedented scale has never been greater.

  • The New(ish) Complexity

    The API economy and microservices architectures, led by Agile and DevOps, have introduced a massive amount of hidden complexity. I call it hidden complexity because we have a tendency in IT to focus on the problems in front of us, resolve them, then focus on the new problem in front of us. This leaves technical debt in little piles behind us, like the bits that fall off the ends of a snowplow blade (or the asphalt that squishes out the end of the steamroller for our southern friends).

    I was thinking about this when I was looking into how a majority of you handle scalability. The layers of complexity for scalability are surprising. In the past, we invested upfront to be prepared to scale to the levels we need. Today we allow expenses to grow as users grow. That is a great model if users are tied to revenue. If there is any fungibility at all in the correlation of users to revenue (and there almost always is), this is a potential disaster waiting to happen. “Our traffic spiked 200%, but revenue only grew 20%,” is pretty much the last thing your business leaders want to hear. Because in the “Pay as you grow” world, a 200% spike in users means a significant spike in overhead. How much overhead varies pretty wildly, of course, so I’ll just say “Guaranteed and significant” and leave it at that.

    This is a known bit of complexity, but those of you I’ve spoken with have done little to hedge against it. That’s … interesting. How many other hidden land mines are out there, being ignored by us?

    What can you do? That greatly depends upon your business. with internal systems, you have a lot of say in usage. External systems are where this is potentially an issue. You can pay your provider to block DDoS, so at least you’re not paying for that bandwidth if that happens—and most of the people I spoke with really do have some form of DDoS protection that stops traffic before it becomes a fee-generating hit. But for actual growth, the best you can do is get with business leaders and determine what influences the correlation between users and revenue. What makes those people upping your traffic actually spend money while they’re upping your traffic? What can you do to convince more of them to spend money? What services are you not offering that might be useful to those customers and not significantly increase overhead. Basically, this is the modern equivalent of the conversion problem. They’re on your site, how do you convert them to paying users of your site.

    We really can’t get more detailed than that—you know your business, and a media site is a different model than a retail site, for example—so you’ll have to develop beyond that. But have a plan that does what you can to make sure that when expenses go up, revenue goes with it.

    And keep rocking it. We’re outside the historical IT realm here—because you’re all rocking it so well that we have new things to worry about. Give those customers rockstar apps to work with and figure out how to make them paying customers. Develop those bonds with business leaders; you do indeed need each other.

  • THE UPSKILLING IT 2022 SURVEY IS NOW OPEN

    THE UPSKILLING IT 2022 SURVEY IS NOW OPEN

    IT SKILLS IN FOCUS

    By Eveline Oehrlich, DevOps Institute

    According to McKinsey, nine out of 10 global executives and leaders are saying that their organizations are facing a skill gap or expect to develop additional skill gaps in the next three to five years. During the past few years, IT organizations, in particular, have already been facing skill gaps. The desire to accelerate technical innovations and digital transformation only makes it harder to identify and narrow current and future skill gaps. IDC predicts 75% of organizations will have a comprehensive digital experience implementation roadmap by 2023, up from 27% today. While 2023 is still a few years away, it is essential that IT organizations prepare for what skills are necessary, how to manage their talent supply and look at the underlying skills of people that must support this digital journey.

    DevOps Institute research team and sponsors, Palo Alto Network, Cycloid, and The Linux Foundation, are excited to announce the launch of the Upskilling IT 2022 Survey. The survey takes approximately 25 minutes to complete, and we’d love to hear from you. Your answers will allow us to better understand which IT skills are essential for the future, ensuring that organizations are able to accelerate their digital journey.

    The Upskilling IT 2022 Survey, by DevOps Institute with its yearly sponsors, is the only and longest running research of its kind. The results provide an unbiased view into what skills are essential across a variety of IT and other skill domains.

    Like the past three research reports, our goal following this year’s survey is to share a detailed analysis to help various leaders and roles, in order to help them determine what skills they should hire, retrain or upskill for, following the publication of the Upskilling IT 2022 Report in the first quarter of 2022.

    Don’t let IT Skill gaps be a competitive liability for today or in the future

    The survey is open for everyone, regardless of the size of your organization, or your organization’s industry. This year we have expanded the focus beyond DevOps and are homing in on cognitive and human skills.

    Some of the key topics we look to deep dive into this year include:

    1. Exploring where the biggest skill gaps currently exist and within which roles, such as leaders, developers or operations.
    2. How skill gaps are identified across the IT industry.
    3. How upskilling is done, funded and executed.

    While each person has their own unique experience, expertise, examples of execution or outcomes and various tolerances for exploration, for the fourth year, we are setting out to explore what the must-have skills are within different skill domains. This year we are focusing on the skills needed within modern IT organizations today and in the future.

    There are a variety of roles that are involved in recruiting, hiring or working within IT organizations. We are setting out to highlight and understand which must-have, nice-to-have and optional skills are essential within key skill domains. The skill domains include Automation, Human skills, Technical skills, Functional skills and knowledge, Process skills and framework knowledge, Business skills and leadership skills. We are targeting the community of IT leaders, developers, practitioners, team leaders, consultants, human resources and other individuals who are familiar with modern IT best practices, such as DevOps. We are targeting all industry verticals and all company sizes. Our survey questions are developed with input from a variety of team members and experts, and our goal is to achieve a sample size of 4,000 individual responses across North America, Europe, Asia Pacific and Latin America.

    Help us shape the future of IT and DevOps and make your voice heard by completing the survey now.

    The survey will remain open until January 31, 2022. We look forward to hearing from you.

    Take the survey now:  https://www.surveymonkey.com/r/Upskilling2022Blog