Category: Features

  • DevOps Practices Gap Assessment

    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.

  • Live Fireside Chat with Christopher Krebs: How to Combat Disinformation

    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.

  • ‘Old Man Yells At Cloud’

    ‘Old Man Yells At Cloud’

    These days, software programmers are increasingly estranged from hardware. Most millennials and Generation Z developers have never had to mount physical servers. They have never been lulled by the gentle hum of a server room chugging along in synchronous harmony. Today, you don’t even necessarily have to build your own PC or worry too much about disk space.

    Instead, cloud-native software developers conveniently offload the server burden to cloud service providers (CSPs). Hosting in a cloud, like AWS or Azure, for example, makes a lot of sense — it allows programmers to hone in on their own specializations. Elastic computing models are cost-effective for startups, and CSPs typically offer a vertical stack with helpful integrated platform-as-a-service (PaaS) and software-as-a-service (SaaS) offerings. However, what are we sacrificing?

    Well, first, research shows the cloud model becomes less cost-effective as a business scales. Second, as more companies transform into technology platforms, cloud usage could better enable their competition. Third, more direct access to bare metal could be an attractive option for certain service providers to increase ownership and control workload optimizations.

    These arguments are bolstered by large companies such as Dropbox, Facebook, Walmart, and others that chose to cut their cloud allegiances in favor of building their own data centers or adopting colocation (in other words, running your own hardware in someone else’s data center, also known as “colo”).

    I recently met with Zach Smith, managing director, bare metal, Equinix, to understand the current state of hardware-as-a-service and the future of hybrid server models. He believes that in the coming years, improved interfaces that access low-level infrastructure will arm IT with better consumer choice that brings them closer to the metal. Yet, to enable this, the hardware world will need to take some lessons from the upper stack regarding transparency, open source community, programmability and improved developer experiences.

    Sidestepping the Cloud

    Public clouds arose as a convenient one-stop-shop to host entire software application environments. As a result, “we have a generation of developers who will never physically touch that hardware,” Smith said.

    The cloud infrastructure services market was worth $39.8 billion in Q4 2020, estimates according to estimates from Statista. Having witnessed the “movement toward verticalization of hyperscale clouds,” Smith now sees the infrastructure-as-a-service (IaaS) market as an industry of high margins and escalating fees. This is echoed by others who seek to reduce rising cloud expenses.

    Though cloud computing usage is growing considerably, the data center isn’t dead. Instead, computing models are morphing and becoming hybridized. “By 2025, 85% of infrastructure strategies will integrate on-premises, colocation, cloud and edge delivery options, compared with 20% in 2020,” predicts David Cappuccio, distinguished VP analyst, in a Gartner report.

    As hybrid multi-cloud approaches emerge, Smith notices a resurgence of attention being paid to infrastructure. Some massive service providers are starting to construct their own data center estates; others, such as Box, now own and lease servers from data center providers.

    Benefits of Bare Metal

    As mentioned above, there are a few reasons to move back to the metal. First, it may simply be more cost-effective for large deployments. In his well-researched article, Antoine Beaupré compared monthly recurring costs for colocation versus an AWS bill, and found the break-even point rested at $100,000 per month, or 150 Amazon m4.2xlarge instances. His research also found that I/O-heavy applications are more costly in the cloud than via colocation.

    “While many services simply launch in the cloud without the organizations behind them considering other options, large content-hosting services have actually moved back to their own data centers,” Beaupré said.

    In addition to cost savings, automating colocation with a programmable layer could also offer more fine-grained control over computing optimizations. “I believe what we’re creating is an operating model for a rapidly changing hardware substrate,” said Smith. He described how bare metal opens up a neutral infrastructure substrate to control physical networking aspects such as cross-connects, IP transits and peering — a benefit Smith half-jokingly called ‘NetDevSecOps.’

    Another argument is that investing in hardware could, ironically, bring sustainability benefits. A report conducted by ITRenew estimates that, of the total embodied energy required within a server’s entire lifespan, 77% is used to manufacture the hardware itself. In contrast, the operational energy used over a server’s lifetime only accounts for 22%.

    Thus, there is an environmental benefit to reversing the trend of a make-dispose economy continually producing new servers. Instead, hardware ownership could encourage a more circular economy. “A circular economy aims to end our take-make-dispose economy, which is a very linear approach, and instead, keep products at their highest possible value for as long as possible,” according to the ITRenew report.

    Learning From the Upper Stack

    How can we build a fundamental non-opinionated infrastructure platform? According to Smith, the industry needs “hardware and networks that are programmable and usable by a developer generation.” To Smith, changing firewalls at a kernel level, altering how the runtime works or controlling the IP stack, should all be operational via API commands.

    Yet, hardware accessibility is still rather opaque and, historically, not as developer-friendly. “How can we take abstraction and community-driven ideas from up the stack?” Smith asks. To enable these changes, he believes the hardware world should model itself on the upper stack in a few key areas:

    1. Transparency: The hardware world is not as easy to comprehend. “When you get to the physical side of switches and routers, it’s still arcane,” Smith said. Increased transparency in functionality and ownership will be required to turn servers into something all developers can operate.
    2. Open-source community: In the same way the software world is built on strong developer communities, hardware will require an open community to normalize things like firmware, boot order and support for differences between drives.
    3. Programmability: “Self-service and programmability are requirements for most things these days — there’s no difference with physical infrastructure,” says Smith. Take the rise of the API economy — today’s mantra is, essentially, if something is possible in a UI, it should be possible through an API. Similarly, if it can be done in a server, it should be controllable with an API.
    4. Quality developer experience: Self-service, programmable infrastructure is just the beginning — interfaces to operate infrastructure require good developer experience. Smith feels that hardware requires an improved buying experience and better life cycle management capabilities. This could be enabled by open source tools like Tinkerbell, a provisioning and workflow engine supported by Linux Foundation.

    Back to the Metal — A Platformer’s Dream?

    All this is not to say the public cloud isn’t valuable – it absolutely is. The cloud has been necessary and has proven resilient enough to support online business and digital life as we know it throughout the pandemic and for years prior. “In 2020 and beyond, most organizations are going to be transforming into a completely cloud-based environment,” said Werner Vogel, CTO, Amazon, during an online AWS summit.

    But, even if most organizations are in the cloud, that doesn’t mean all of their assets will be. Service providers, especially, may cling to hybrid models for more control, to avoid supporting the competition and, perhaps, even to save money. Private data centers could also increase security. In an era where raw computing power is becoming a new asset (quite literally, in the case of cryptocurrency), the server rack is starting to look sexy again.

    “The magic happens when software and hardware work together,” said Smith. But, giving access to physical technology to a generation that has never touched it will require some ingenuity. As Smith says, this could be done by “automating colo” through more usable, standardized interfaces for hardware management.

    “We will see a future in next 10 years where operated software is separated from cloud infrastructure,” Smith said. That’s a bold statement, as such a dramatic change would, in effect, usurp the current cloud provider IaaS market share, altering the distribution and economic model associated with global software.

    While this dream may seem far-fetched, if more platforms decide to cut out the cloud middleman and go it alone, it could materialize.

  • Atlassian Extends Open DevOps Ambitions

    Atlassian Extends Open DevOps Ambitions

    At an online Atlassian Team 2021 event this week, Atlassian launched a two-pronged effort to provide organizations with more insights into software development workflows constructed using tools from multiple vendors.

    Suzie Prince, head of product for Atlassian, said an Open DevOps initiative will tighten integration between the Jira project tracking and management tools provided with Atlassian and a wide range of tools commonly employed by DevOps teams. The goal is to not only make it easier to correlate issues that are listed in Jira with artifacts found in various software platforms, but also to collect data from DevOps tools to automatically update Jira.

    That data will then be employed to inform the key performance indicators (KPIs), based on graphs that Atlassian provides within Jira, to keep track of value streams. Rather than having to acquire a separate value stream management (VSM) platform to track software development progress, the insights needed to understand the impact of, for example, a delay to one project becomes a dividend of using Jira.

    At the same time, Atlassian is moving to making it easier for other stakeholders in an organization to track software development projects. A Jira Work Management application is specifically designed for business users that require a higher-level tool to track projects. At the same time, Atlassian revealed this week it has acquired ThinkTilt, a provider of low-code application development tools optimized for Jira.

    Atlassian for the first time this week revealed that half of Jira users are not software developers. As organizations increasingly appreciate the degree to which they are now dependent on software to drive digital business transformation initiatives, Atlassian is adding a set of project tracking applications designed specifically for users that need to consume Jira data in a more intuitive fashion.

    Prince said Atlassian is committed to making it simple to replace one DevOps tool integration for another with a single click. Rather than requiring organizations to standardize on a single DevOps platform, Prince added that developers will be able to continue to rip and replace tools and platforms as they see fit without compromising visibility into application development workflows.

    In addition, the integrations being provided by Atlassian will reduce the time and effort required to configure all the tools that make up a DevOps workflow, from roughly 60 steps today to about six.

    As DevOps workflows become more pervasive, the way organizations operate is fundamentally changing. Formal product launches are giving way to a steady stream of software updates that add new capabilities to any platform with little to no fanfare. End users ranging from sales teams to custom support personnel now need to track updates to platforms more closely as new capabilities are continuously added.

    Of course, not every organization has the same level of maturity. However, as competitors start to add new features to rival offerings, it is now only a matter of time before most business processes – that increasingly revolve around software updates – begin to evolve and change. As the pace of software development continues to accelerate, the pressure on legacy business processes will only continue.

  • Successful Digital Transformation: It’s About Strategy

    Successful Digital Transformation: It’s About Strategy

    While having a mature digital enterprise helped organizations to better survive – and even thrive, in some cases – the pandemic, that’s not the primary reason why organizations will continue to invest in their digital transformation efforts. According to new research from consultancy Deloitte, businesses will continue to invest in their digital transformation capabilities to innovate rapidly and to survive competitive battles in the marketplace.

    Deloitte’s survey found that enterprises believe such ongoing investments in digital transformation will continue to deliver benefits, such as enabling them to innovate more quickly, modernize their business-technology systems and become more resilient. The pandemic proved an unfortunate test of such business resilience, with more than 75% of respondents saying that their digital capabilities helped them better meet the business challenges posed by the pandemic.

    The survey also found that enterprises plan to increase their digital investments and to do so considerably. Respondents indicate, on average, planned investment of nearly $13 million on digital transformation in the next year — a 15% increase from the prior year’s spend.

    These findings mirror those of another survey released this week from software provider Rimini Street, which found digital transformation is one of the top five priorities among CFOs, and that 71% of CFOs believe that such investments are essential to the success of their businesses. Further, 77% of CFOs said they would work with their CIOs to help find funding for digital transformation efforts — if there was a strong ROI demonstrated.

    Perhaps most noteworthy from the Deloitte survey is that, while digital platforms and digital transformation efforts are essential, they are not a competitive advantage by themselves. It’s what businesses do with those platforms that matter.

    Additionally, most Deloitte respondents see plenty of competitive upheavals ahead: most respondents feel it is most likely that their main competitors will be a startup or current digital native competitor in as little as five years. Less than one-third of respondents believe that their current competitors will remain competitors five years from now.

    To win funding for digital transformation and innovation initiatives, the Rimini Street survey suggests CIOs will most likely succeed by not pushing innovation for its own sake, but by seeking out initiatives that will generate a strong return. In that survey, CFOs made it clear that optimizing existing technology, revenue-generating endeavors and improving processes and staff efficiencies were their top three priorities.

    In that race to continuously optimize business technology systems, many CIOs in Deloitte’s survey also see a downside. More than half of those questioned said that the rapid pace of change is harmful to both their organization and their customers, and 75% said the rapid change had created significant upheaval in business leadership or their board during the past 24 months.

    Whether enterprise business and technology leaders want a world with such rapid change doesn’t matter: it is the world in which they must compete. And those enterprises that succeed in the next few years will be those that not only make the right investments in digital transformation, but those that figure out the best ways to innovate and connect with customers by leveraging those investments.

  • JFrog Tightens Integration with Cloud Edition of Jira

    JFrog Tightens Integration with Cloud Edition of Jira

    JFrog this week announced that its DevOps platform, delivered as a software-as-a-service (SaaS), can now be integrated with the Jira project tracking and management application, delivered as a cloud service, from Atlassian.

    Casey O’Mara, vice president of worldwide business development for JFrog, said this bidirectional integration makes it possible to link a Jira issue, such as a bug fix, to the binary or build residing in the JFrog Artifactory repository that is part of the JFrog DevOps Platform.

    Available via an application that can be downloaded from the Atlassian Marketplace, this integration extends an existing alliance between the two companies, said O’Mara. There is, for example, already an integration between Atlassian Bitbucket Cloud for continuous integration and JFrog Artifactory repository.

    Creating a link with a Jira issue will make it easier to collaborate by, for example, making it easier to understand why a specific version of an artifact, such as a container image, was created, added O’Mara.

    Artifactory is already able to collect issue key messages from Git that logged alongside builds. The Artifactory dashboard for build information displays a link to each of the referenced Jira issues in the Issues tab. Now, users of Jira can link to the builds in Artifactory.

    Jira remains the dominant project tracking and management application for software development. As more organizations appreciate the degree to which they now depend on software, O’Mara noted the number of stakeholders in an organization using Jira is starting to increase, as application development schedules are tracked more closely. Atlassian is now making Jira more accessible as a cloud service to help foster that increased adoption, noted O’Mara.

    Atlassian is now making a case for transitioning its customer base to the cloud. In the third quarter of this year, it plans to discontinue new server license sales in addition to increasing prices for on-premises products. Ironically, the company reported preliminary results for its most recent third quarter that indicate revenues of between $566 million to $572 million. That’s $85 million more than originally forecasted, because demand for on-premises products has increased in anticipation of their unavailability later this year.

    In general, both Atlassian and JFrog are strong proponents of a best-of-breed approach to DevOps. JFrog, in its most recent quarter, reported $42.7 million in revenue, representing a 39% gain. Cloud revenue in that quarter grew 69% to $9.8 million, representing 23% of total revenue.

    It’s unclear at what rate organizations are shifting to the cloud. The number of workloads moving into the cloud has certainly accelerated in the wake of the economic downturn brought on by the COVID-19 pandemic. However, the bulk of data continues to reside in on-premises environments, and many organizations, because of performance, security and compliance concerns, don’t have any immediate plans to migrate all their applications to the cloud.

    Regardless of where DevOps platforms reside, there will always be a need to integrate them. It just may be easier to achieve that goal when all the tools that make up that workflow are running in the cloud.

  • IBM Unifies Cloud Services to Simplify App Dev

    IBM Unifies Cloud Services to Simplify App Dev

    IBM announced today that an IBM Cloud Code Engine service that unifies the cloud platforms on which applications are built and deployed is now generally available.

    Built on top of a serverless computing platform, IBM Cloud Code Engine is a managed service that unifies access to a platform-as-a-service (PaaS) environment, a container-as-a-service (CaaS) environment and batch workloads, that run on traditional virtual machines, to a single platform.

    At the core of that managed service is an instance of Kubernetes running Knative middleware for invoking an open source serverless computing framework, the Istio service mesh and Tekton pipelines for building DevOps workflows.

    Jason McGee, CTO and vice president for IBM Cloud Platform, said the goal is to eliminate the artificial constructs that developers are forced to navigate in the cloud today that can each trace their lineage to a different era of software development. The IBM Cloud Code Engine unifies the developer experience in a way that makes it simpler to build and deploy applications on the type of cloud service that best makes sense for a specific application workload, McGee said. Developers no longer need to configure code for a specific type of infrastructure; they can simply describe how they want source code or a container image to behave, and IBM Cloud Code Engine automates deployments accordingly.

    The serverless computing framework that IBM Cloud Code Engine is built on also makes it possible for IBM to only charge organizations when code is actually running, versus requiring them to commit to a specific amount of infrastructure to run a set of virtual machines, McGee added. Charges are based on the memory and vCPU consumed and incoming HTTP calls. That approach will, over time, substantially reduce the total cost of cloud computing, said McGee.

    It should also accelerate the rate at which applications are migrating to the cloud, added McGee. Today roughly 20% of application workloads run in the cloud. Getting the next 40% of workloads shifted into the cloud will require providing a simplified application developer experience, noted McGee.

    The challenge organizations are wrestling with today is that they are deploying a mix of monolithic and microservices-based applications in the cloud that, to varying degrees, rely on batch-oriented and real-time platforms. IBM Cloud Code Engine represents an effort to provide a layer of abstraction over a wide range of cloud services that they can flexibly invoke via an event-driven platform, as required.

    The DevOps implications of IBM Cloud Code Engine are potentially profound. DevOps teams today spend an inordinate amount of time provisioning cloud infrastructure on behalf of developers. IBM is now making a case for a platform that automates that process in few seconds. In effect, control over cloud infrastructure will shift even further left to application developers. DevOps teams, in theory, will spend more of their time optimizing cloud environments after an application has been deployed.

    It’s not clear to what degree platforms such as IBM Cloud Code Engine might force cloud service providers to consolidate distinct cloud services they provide to developers today based on the type of application being built. However, it’s already apparent that the writing on the wall heralding that consolidation have now been indelibly inscribed.

  • Red Hat Extends Reach and Scope of Insights Analytics Service

    Red Hat Extends Reach and Scope of Insights Analytics Service

    During its online Red Hat Summit event, Red Hat today announced it has extended the Red Hat Insights predictive analytics cloud platform for managing IT to now include support for editions of Red Hat OpenShift based on Kubernetes and the Red Hat Ansible Automation Platform.

    In addition, Red Hat has extended Red Hat Insights for Red Hat Enterprise Linux (RHEL) to include the ability to prioritize security alerts, streamline notifications and track Red Hat subscription consumption.

    In total, since launching Red Hat Insights in 2019, Red Hat claims there are now more than 600,000 RHEL hosts analyzed per day.

    Joe Fitzgerald, vice president and general manager for the management business unit at Red Hat, said Red Hat Insights provides IT teams with the equivalent of a co-pilot for managing IT environments. In general, advances in automation and artificial intelligence (AI) are making it easier to manage complex IT environments at scale, noted Fitzgerald. However, it’s not likely IT environments will be automated to the point where lights-out management without human intervention is likely to be achieved any time soon, added Fitzgerald.

    However, it’s also becoming apparent that it’s not possible for IT teams to manage complex IT environments without help in the form of advanced analytics tools. In fact, while many IT professionals are leery of automation tools because of the perceived threat to their jobs, it’s also becoming apparent that IT teams will not be able to manage modern IT environments without these tools. Organizations can’t afford to hire small armies of IT personnel. In addition, finding and retaining IT professionals that have, for example, Red Hat OpenShift skills remains a significant challenge.

    Red Hat Insights provides IT teams with additional levels of context required to manage these environments that goes beyond simple monitoring, noted Fitzgerald. That’s critical, as the IT environment becomes more extended in the age of hybrid cloud and the rate at which platforms are updated steadily increases, added Fitzgerald. Platforms such as Red Hat OpenShift, for example, are now typically updated every three to four months.

    DevOps, of course, has always been about ruthlessly applying automation whenever possible. As analytics applications become more robust, IT teams gain the visibility required to automate a wider range of complex tasks, noted Fitzgerald. In fact, in the absence of that visibility, automation can be a dangerous thing when mistakes caused by a lack of visibility and insight are made, added Fitzgerald.

    In the longer term, Red Hat expects to see continued convergence of job functions and roles as IT teams become more cross-functional, said Fitzgerald. Platforms such as Red Hat Insights will provide a single console around which these teams can collaborate, added Fitzgerald.

    Going forward, there won’t be a handful of administrators with augmented capabilities. Rather, IT specialists that have a particular set of skills will be able to collaborate more easily in a way that both creates a better outcome and ultimately keeps a lid on the total cost of IT.

  • ServiceNow Shifts to Single Unified Agent

    ServiceNow Shifts to Single Unified Agent

    ServiceNow today unveiled an Agent Client Collector (ACC) that makes it possible for IT teams to capture data from software, hardware and cloud infrastructure.

    Jeff Hausman, vice president and general manager for IT operations management at ServiceNow, said this unified agent will enable IT teams to reduce the number of agents they would otherwise have to deploy to collect the data required to monitor IT environments.

    IT teams will also be able to employ incident management tools that can view that data in a way that eliminates the need to install any remote desktop software, Hausman noted. At a time when many employees will be splitting their time between working from home and the office, that approach reduces the level of IT service management (ITSM) friction that many IT teams today regularly encounter, added Hausman.

    ACC surfaces both configuration and performance data in real-time to provide IT teams with greater visibility. That data can then be used to drive a variety of workflows and playbooks that trigger automated incident responses.

    ServiceNow will employ ACC both within its ITSM platforms and IT operations management (ITOM), hardware asset management (HAM), software asset management (SAM), and security operations (SecOps) tools.

    Hausman said ServiceNow will employ ACC alongside agentless tools for managing IT environments as part of an effort to strike a balance between the amount of software that needs to be deployed and the capabilities that agent software enables. Ultimately, ServiceNow will also open up ACC to third-party tools that offer complementary capabilities, he added.

    More than a few IT organizations are suffering today from a phenomenon known as agent fatigue. Each new tool added to the IT arsenal often requires agent software to be installed within a device, application, server or cloud service. The need to reduce the amount of agent software has given rise to agentless approaches to managing IT resources, but the tradeoff is that, in the absence of an agent, the types of data and capabilities that can be enabled tend to be more limited.

    The market research firm International Data Corp. (IDC) is predicting that 75% of Global 2000 IT organizations will adopt automated operations practices by 2023. A major driver of that increased reliance on automation has been, of course, the COVID-19 pandemic. Not only are organizations making greater use of cloud infrastructure, but application users are not often conveniently located behind a firewall in a corporate office. For the last year, IT teams have been tasked with supporting a largely remote workforce. As more of those employees are vaccinated in the weeks ahead, a lot more of them will be returning to the office. However, it’s unlikely most employees will be working in an office full-time even after the COVID-19 pandemic subsides.

    Regardless of how IT is managed, the overall IT environment will continue to become more complex. As such, it’s now more a question of when rather than if organizations will need to revisit how IT gets managed across what has become a highly distributed environment.

  • Applause Delivers Testing Integration Tool

    Applause Delivers Testing Integration Tool

    Applause today made a bi-directional integration capability that simplifies requesting application code tests of, dubbed Applause In-Sprint Testing, generally available.

    Kristin Simonini, vice president of product for Applause, said application owners will be able to, for example, use a Jira project management application to create a ticket that requests a specific piece of code be tested either by a member of dedicated testing team or by a developer that has assumed greater responsibility for application testing within the context of a DevOps workflow.
    Alternatively, that request could be sent to a tester that is a member of uTest, an online community of professional testers that Applause oversees.

    The company also published the results of a global survey of 1,800 quality assurance (QA), product, engineering and DevOps professionals that found 44% of development teams that have shifted application testing left are spending a full workday every week on application testing. More than half the respondents (52%) noted that amount of time spent on testing is impacting developer productivity.

    On the plus side, a full 88% of respondents that release code multiple times per month said their organizations now test features as they are developed versus waiting until the end of application development process, the survey also found.

    The major benefits of shifting testing left cited by respondents are reducing the number of bugs released into production environments (57%), reducing the cost of late-stage bug fixes (48%), and reducing the need for hot-fixes (39%).

    The top two barriers to shifting responsibility for testing left toward developers is they are too busy coding (45%) and that development and quality assurance (QA) efforts remain siloed (37%). Nearly half of developers (44%) said they have issues with context switching as they shift between coding and testing tasks.

    Simonini said Applause In-Sprint Testing will make it easier for application owners to decide when they want to make use of a professional tester versus having a developer run a test. The Applause Product Excellence Platform then enables IT organizations to leverage a software-as-a-service (SaaS) platform to record a series of test case scenarios that can be automatically converted into an automation script without anyone having to write code.

    The overall goal is to simplify testing at a time when the number of applications being built has accelerated in part because of the increased focus on digital business transformation that occurred in the wake of the economic downturn brought on by the COVID-19 pandemic. As organizations realize how dependent they have become on those applications to differentiate themselves, the focus on quality assurance naturally intensifies, noted Simonini.

    There’s no doubt more organizations are testing with greater frequency. The efforts of developers that previously tended to address large numbers of bugs as part of a series of application updates after deployment in production are now being frowned upon. Organizations realize their applications only get one chance to make a first impression with end customers. As a result, the level of attention to detail being applied to application testing has, for better or worse, never been greater.