devopsy.kinsta.cloud

Tag: it automation

  • Survey Shows Shift to SRE Principles to Automate IT Management

    Survey Shows Shift to SRE Principles to Automate IT Management

    A global survey of 1,500 IT decision-makers conducted by F5 found that, on average, organizations are managing more than 200 applications deployed across an extended enterprise as well as more than 20 different security and delivery technologies.

    Lori MacVittie, principal technical evangelist in the Office of the CTO for F5, said that level of complexity makes it apparent that IT teams will need to embrace higher levels of automation to manage the IT environments that are now at the core of a wide range of digital business transformation initiatives. The survey revealed that more than three-quarters of respondents (77%) were embracing site reliability engineering (SRE) principles to automate the management of IT.

    A full 95% of respondents also planned to mine operational data for insights they could use to improve the customer experience and drive business growth. However, 98% of respondents also said they are currently unable to extract those needed insights from their existing systems. A total of 90% said they planned to implement some form of artificial intelligence (AI) to achieve that goal. More than two-thirds of respondents said their organizations realized that creating superior digital interactions for customers will require modernizing business processes and back-office functions.

    As part of those efforts, the survey suggested that application workloads are being shifted across highly distributed computing environments. In addition to the 84% of respondents that are planning to move workloads to the edge, the survey found two-thirds of organizations (67%) are currently or planning to repatriate applications from the cloud to a data center environment in the next 12 months. A total of 93% of respondents reported using some type of as-a-service offering delivered via the cloud today.

    Naturally, securing that many platforms also represents a major challenge. However, despite inherent risks, more than three-quarters (76%) of respondents said, given the choice, they’d turn off security measures to improve performance. That lack of willingness to sacrifice performance suggests that attitudes to security may not have changed much despite all the breaches that now regularly occur, said MacVittie.

    It’s not clear to what degree managing enterprise IT environments has become untenable; however, it’s clear that legacy manual processes will need to become automated. Organizations can’t afford to keep hiring IT staff to manage IT platforms that span everything from the network edge to public clouds. In fact, the survey makes clear that DevOps practices—in the form of the SRE principles first defined by Google—are gaining traction. That doesn’t necessarily mean everyone managing IT is becoming an SRE or an engineer, but it does suggest that automation frameworks are being more widely used.

    It may be a while before those automation frameworks are ubiquitous. However, one way or another, many of the tasks that have historically conspired to make working in IT tedious are going to disappear. The issue, of course, is to not wind up with islands of disconnected automation that introduce more complexity.

  • What Does AIOps Mean for SREs?

    What Does AIOps Mean for SREs?

    It seems SREs are of two minds when it comes to AIOps. On one hand, AIOps’ potential is pretty exciting. By automating complex workflows and troubleshooting processes, AIOps could make your life as an SRE much easier.

    But on the other hand, some SREs may choose to view AIOps with disdain and distrust. They might think of AIOps as just another trendy buzzword that doesn’t live up to the hype and that can become a distraction from the SRE tools that really matter.

    Which perspective is right? Should SREs embrace AIOps with open arms, or should they resist marketers’ efforts to position AIOps as the latest, greatest tooling innovation in the IT industry?

    Those are subjective questions that we can’t answer definitively, but let’s at least gain some perspective by examining what AIOps means for SREs.

    What is AIOps?

    If you keep up with IT buzzwords, you’ve probably at least heard the term AIOps—which is short for artificial intelligence for IT operations—and that it refers to the use of AI and machine learning (ML) to help automate IT operations workflows.

    The big idea behind AIOps is that, by using AI and ML to perform advanced analysis of large volumes of data from IT systems, IT and SRE teams can solve complex problems more efficiently than they could using a traditional, manual approach.

    AIOps can, for example, help to surface the root cause of a performance issue in a complex, multilayered environment like Kubernetes. Or it could make recommendations about how best to resolve an incident.

    AIOps entered the IT lexicon in 2016, when Gartner coined the term. Now, six years later, it’s a relatively well-established tool domain.

    How SREs View AIOps

    Despite the fact that AIOps has been around for some time, it doesn’t yet appear that many SREs have bought into the AIOps revolution. Catchpoint found in a 2021 survey that just 7.5% of SREs reported that AIOps tools delivered high value to their organizations.

    It’s unclear exactly why there are such low rates of excitement about AIOps, but we’d speculate that there are a few key factors at play:

    • AIOps is a new term for an old idea: Many monitoring and observability tools have included at least basic AI and ML analytics features for a long time, even before tool vendors slapped the AIOps label on their products. SREs probably realize this and, to some extent, view AIOps as an effort by marketers to rebrand functionality that is not actually new.
    • AIOps is hard to implement: Setting up an AIOps tool requires integrating it with diverse data sources and customizing it to fit your workflows and environment. It’s possible some SREs view this setup work as requiring more effort than it’s worth.
    • AIOps can’t replace human insight: While AIOps tools may be useful to a point, it would be unwise to place blind trust in AIOps-based analyses or recommendations. For this reason, some SREs may believe that AIOps encourages organizations to rely too heavily on automated tools at the cost of the expert analysis and perspective that only SREs can provide. (This is similar to the fact that it sometimes makes sense to prioritize human intuition and expertise over playbooks.)

    From an SRE’s perspective, then, AIOps may appear over-hyped, overly complicated and underperforming compared to traditional approaches to SRE.

    What SREs can Gain From AIOps

    SREs’ wariness toward AIOps is valid—but only to a point. It’s important not to let suspicions about the limitations of AIOps turn into excuses not to use AIOps at all. AIOps has some value to offer to SREs, even if it’s not perfect.

    For example, AIOps can play a role in reducing toil. To the extent that AIOps tools can recognize complex patterns or discover interrelated data sets more quickly than human engineers, AIOps reduces the time SREs have to spend manually troubleshooting problems or poring over complicated information.

    AIOps also helps to enable a more proactive approach to monitoring and incident management. If AIOps tools can alert SREs to emerging issues before they would otherwise recognize them, AIOps can help the SREs to get in front of the problems before they turn into true incidents. That’s better for SREs and end users alike.

    There is also an argument to be made that AIOps can help SREs do more with fewer engineering resources. If you can use AI to automate some aspects of monitoring and incident response, you can maintain the same levels of availability and performance with fewer human engineers on hand.

    Conclusion: AI Won’t Replace SREs—But it can Help

    None of the above is to say that AIOps can replace SREs, or that it magically solves every problem SREs face. Anyone who believes AIOps is a silver bullet has bought into the marketing hype to an unhealthy degree.

    Nonetheless, AIOps tools do offer value to SREs by making their jobs easier in some respects and improving reliability outcomes.

    So, while it’s wise to maintain a healthy perspective about the limitations of AIOps, SREs shouldn’t rule out AIOps tools as one way to improve reliability engineering.

  • OpsRamp Extends AI Reach to Incident Management

    OpsRamp Extends AI Reach to Incident Management

    OpsRamp today extended its IT operations platform infused with machine learning algorithms, also known as AIOps, into the realm of incident management.

    The Summer 2021 release of the company’s namesake platform adds alert predictions for preventing outages and incidents, alert enrichment policies for faster incident troubleshooting and enhancements for automatically ingesting metrics data collected from the Alibaba Cloud environment and open source Prometheus monitoring software as well as Hitachi, Poly, VMware and Dell EMC platforms.

    IT operations teams can now also visualize metric values that can increase or decrease within a fixed range using Gauge charts. IT teams can also now add alert context details to provide more relevant information. There’s also now a mobile app for both Apple iOS and Google Android devices through which IT teams can now respond to alerts and incidents.

    Finally, OpsRamp is also making available a beta release of dynamic Workflows, which enable IT team to maintain a single decision table to address specific operational scenarios.

    Sheen Khoury, chief revenue officer at OpsRamp, said the goal is to leverage artificial intelligence (AI) to increase application availability by enabling IT teams to better predict when there are indicators of an incident caused by, for example, higher volumes of seasonal traffic that could lead to an outage.

    At the same time, IT operations teams can improve overall time-to-value by leveraging the automatic monitoring tools that are embedded in the platform, he added.

    OpsRamp is betting that rather than waiting for incumbent providers of IT operations platforms to add AI capabilities, many IT teams will opt to deploy a new IT management framework altogether. Many of the manual tasks IT operations teams regularly perform today can then be automated faster, noted Khoury.

    Naturally, it takes time for machine learning algorithms to be trained, so the benefits of AIOps are not instantaneous. However, those algorithms will continuously learn the unique attributes of an IT environment in a way that makes it easier for IT teams to manage an IT environment more proactively. The algorithms provide the added benefit of making it easier for new members to join an IT operations team without having to spend months learning all the nuances that are unique to that environment.

    Each IT team will need to decide for itself the degree to which they want to rely on an AIOps platform to manage their IT environment. Initially, most IT teams will need to evaluate the recommendations made by an AI platform. However, as they gain confidence in the recommendations, they will trust the platform to automate more processes in response to events occurring in the IT environment in real-time.

    Regardless of how much faith IT teams put in AI, it has become apparent that enterprise IT environments are only going to become more complex. Many IT teams will not be able to manage some environments without the aid of an AI platform. Many IT professionals may not want to work for organizations that don’t provide some way to augment their skills using AI—the stress level would simply be too high.

    One way or another, DevOps teams that are highly committed to ruthlessly applying automation will be at the forefront of AI adoption in the enterprise.

  • Key NoOps Insights From DevOps Leaders

    Key NoOps Insights From DevOps Leaders

    NoOps is coming, in some form or another. Whether you have homegrown DevOps or outsourced DevOps, it’s time to realize that a simpler way is coming: NoOps automation. We spoke with a group of IT pros to get their perspective and insights, including James Rutt, CIO, The Dana Foundation; Rahul Subramaniam, CEO, DevFactory; and Mark Hahn, director of DevOps and cloud strategies, Ciber Global.

    Forrester Research defines NoOps as the goal of completely automating the deployment, monitoring and management of applications and the infrastructure on which they run.

    The next generation of PaaS platforms is evolving to meet this goal. If development teams prefer not to deal with operations or lack the necessary skill sets, they can opt into platforms that provide standardized best-in-class operations with minimal hassle. This also accelerates the evolution of their infrastructure to emerging technologies such as Kubernetes and containers. Not only that, but it can be accomplished at a fraction of the cost. However, the NoOps concept is not without its own bit of controversy.

    Insight #1: The End Goal is to Empower Development Teams

    Mark Hahn: “The differences [between DevOps and NoOps] have a lot to do with shifting left more on all of the processes. With DevOps, teams have to rely on various operations and infrastructure support services. With NoOps, the goal is to make those teams fully self-sufficient.”

    Automation is the key to this self-sufficiency. Continuous integration and deployment automation can be created and configured by the DevOps team or provided by the platform (NoOps). In either case, the end goal is to empower the team such that they can focus more on the business problem at hand than deployment.

    In a DevOps model, a few developers on the team typically manage the continuous integration pipelines and their associated deployments. This includes the creation of the application stack and subsequent updates, as well as observability and scalability mechanisms. The widespread availability of infrastructure-as-code and associated APIs has made this possible.

    NoOps platforms provide these capabilities without much additional work by developers, thus enabling application teams to accelerate their delivery velocity. This does come at the cost of some flexibility. Teams with special requirements, such as GPU-centric environments or extremely high-scale use cases, may opt to build their own infrastructure to meet their individual needs.
    Most teams don’t need the additional complexity, though, and are better served to avoid it. Applications with a user base in the low thousands will likely not need much beyond the standard configuration provided with frameworks such as Spring Boot or .Net Core. You start with just the infrastructure you need, avoid solving problems you don’t have and leverage only select offerings from cloud providers.

    Insight #2: Consistently Making the Right Infrastructure Choices is Hard

    Rahul Subramaniam: “We have far too many choices; making the right choices is extraordinarily hard. When you build a Spring Boot application, the number of deployment choices you make is ten times what it was even five years ago.”

    “I’ve seen teams that put together really large CI/CD pipelines that run thousands of builds a day. The problem is, it works for 50% of the teams really well, and the other half are struggling. For developers building Java-based systems, it works great, but those that are doing Android development, it doesn’t support mobile applications well,” added Hahn.

    The NoOps approach has a key dimension that extends beyond automation. The infrastructure landscape is continually evolving, and developers are faced with a growing array of choices as they deploy and manage applications. How can teams know which are the right tools to pick? There are too many out there to be an expert on all of them.

    Consider the area of observability, where choices range from open-source solutions such as Prometheus and Grafana to commercial offerings such as Dynatrace and DataDog. Is the extra value added by the commercial offerings worth it? Is it a requirement for your application?

    It can be difficult to say, upfront. Oftentimes, the best way to learn how to operate your service is to operate your service. Starting with an opinionated, bundled solution gets you started quickly and puts you in a position where you can learn those lessons. With NoOps, the infrastructure arrives ready-to-go, right out of the box. You can focus on your core business function and not worry about the deployment mechanism. This shrinks the surface area where errors may occur, and improves the efficiency of development teams. From a management perspective, the reduced cost is also quite appealing.

    Mark Hahn offered a different perspective on this topic. He noted that if there is one opinionated CI/CD framework, it may suit some teams well but not the others. Teams that develop various components may have different requirements; thus, they may need the option to build their own pipelines. This is a consideration to keep in mind as organizations seek to adopt the NoOps philosophy.

    Insight #3: Evolve from NoOps to DevOps, Instead of the Reverse

    James Rutt: “There is a broad assumption that DevOps is mature, whereas in most shops, they feel mature in some areas of the value stream but not necessarily in the synchronization of all the tools. Now, we are talking about another quantum leap into NoOps. Do you think we are jumping ahead too quickly?”

    DevOps and NoOps represent a spectrum, rather than a conflict where one wins over the other. Many applications don’t need a highly engineered infrastructure, as opposed to companies like Amazon and Netflix who require it. Thus, don’t over-architect solutions until the time where you need to. Grow into DevOps when it becomes a business priority for you. For Amazon, it is a business priority to manage that infrastructure. For you, it may not be.

    Subramaniam made the point that teams should actually begin with the NoOps approach as the default. Look for NoOps solutions out there to quickly get started, and at some point, you may need to manage that infrastructure yourself as your business grows or requires it.

    Another consideration is that not all organizations are at the point where developers can make choices independently. You always want the business and technology groups to be in alignment. This is where more traditional processes fall into place. Further, DevOps teams typically place numerous checks and balances in their systems. For example, custom pipelines enable reconciliations and cross-checks to make sure the data being operated on is correct and accurate.

    Insight #4: NoOps Platforms vary by Cloud Provider

    For developers running on Google’s cloud, App Engine “lets app developers build scalable web and mobile back ends in any programming language on a fully managed serverless platform.” Teams running on AWS can use Engine Yard Kontainers from DevGraph to “deploy apps in one click directly from your Git repo.” There is also AWS Elastic Beanstalk, which bills itself as “an easy-to-use service for deploying and scaling web applications and services” on one of their supported technology stacks.

    Regardless of DevOps versus NoOps, our interviewees agreed that development teams need to be empowered. Gone are the days where you can afford to spend time on undifferentiated activities or wait on dependent service teams. Focus on the business value from day one, make it observable and use the platform that best enables you to accomplish that goal.

  • Puppet Makes IT Automation More Accessible

    Puppet Makes IT Automation More Accessible

    Puppet today launched two efforts to make its IT automation platforms accessible to a broader range of IT teams.

    The Puppet Enterprise Platform integrates the company’s flagship Puppet Enterprise offering with Relay by Puppet, the company’s existing event-driven automation platform.

    At the same time, Puppet announced Puppet Connect, a self-service platform for executing tasks on-premises or in the cloud without requiring any agent software to be installed, managed or updated. Based on the open source Bolt orchestration engine, Puppet Connect is a commercial platform scheduled to be available in early 2021.

    Puppet CTO Deepak Giridharagopal said Puppet Enterprise Platform is unique in that it allows IT teams with varying levels of skill and expertise to employ the same platform to automate IT operations. It is the first to support task-driven orchestration, model-driven infrastructure as code and application programming interface (API) event-driven workflows in a single platform, he said, noting as such, Puppet Enterprise Platform is designed to enable organizations to better approach IT management as a team sport.

    The company is also providing access to thousands of pre-built automation modules and hundreds of API integrations for Puppet Enterprise Platform that can be downloaded from the Puppet Forge repository.

    Puppet Connect, meanwhile, is designed to make it easier for IT teams to build self-service portals more consistently. IT teams regularly build self-service portals to automate tasks to help reduce the number of help desk requests generated by end users. According to the “2020 State of DevOps Report” published by Puppet, 63% of respondents have at least one self-service internal platform. Puppet Connect streamlines the process of creating a self-service framework using the orchestration capabilities of Bolt, said Giridharagopal.

    Interest in automating IT tasks has risen sharply as IT teams cope with more end users working from home to limit the spread of COVID-19. In some cases, the size of the IT staff has been reduced because of the economic downturn brought on by the pandemic. Regardless of motivation, IT staffs that have varying levels of skills all need to find an easier way to automate tasks. The Puppet platforms provide a more accessible layer of abstraction to enable IT teams to automate tasks spanning multiple platforms, noted Giridharagopal.

    It may be a while before IT teams of all sizes automate every IT task; however, the more those tasks become automated the further down the path they move toward embracing best DevOps practices. Those organizations may not deliberately start out to embrace DevOps, but once an IT team automates its first set of tasks it’s not long before other manual tasks become automated.

    Of course, there’s no shortage of IT automation frameworks to standardize on. At this point, the more important thing for many IT teams is to simply get started at a time when no one knows for sure how many years the impact of the COVID-19 pandemic will be felt.

  • Survey Uncovers Issues Even With Advanced IT Teams

    Survey Uncovers Issues Even With Advanced IT Teams

    Even in the best of times, IT teams struggle with myriad issues related to managing their application environments

    A survey of 1,000 C-level executives at software-as-a-service (SaaS) application providers finds that while the bulk of respondents are “highly confident” or “confident” that their cloud applications were running efficiently (91%), many also are still concerned about staying within budget (65%), maximizing resources (62%) and maintaining uptime.

    Results of the survey conducted by Opsani, a provider of tools for optimizing cloud applications based on machine learning algorithms, suggest that even the most advanced IT organizations are finding it challenging to optimize application performance within the constraints of their IT budgets.

    Amir Sharif, vice president of marketing for Opsani, said most SaaS providers have already optimized complex application environments to the greatest extent possible by a team of humans no matter how mature their DevOps processes. The next level of optimization requires artificial intelligence (AI) capabilities that can discover, correlate and analyze real-time events and dependencies at levels of scale no human can match, he said.

    Within the most advanced IT teams, all the tasks that can be automated easily have already been completed, added Sharif. As IT environments become more complex, optimizing the IT environment requires platforms capable of instantly implementing policies and procedures defined by the IT team. That shift doesn’t eliminate the need for a DevOps team, but rather a shift in their role to define the policies that need to be automated, he said.

    The Opsani survey finds 43% of respondents update software daily and 37% release new software weekly. Only 15% said they conduct hourly sprints. The top concerns among respondents are employees wasting time on mundane tasks (54%), followed by finding talent (47%) and legacy processes that don’t reflect today’s technology landscape (43%).

    When asked how often their organizations optimized their application stack, 82% said they do so regularly, with 81% reporting their organizations already make use of AI tools for faster decision-making.

    When asked about service level objectives and performance goals, respondents cited transactions per second as their top metric (63%), followed by latency (47%), dollar per transaction (43%). IOPS and throughput tied for fourth (34%).

    Sharif said resistance to AI in general is declining in most IT organizations given the level of complexity faced. A 10-tier microservices application and a backend database developed by Google has more than 75 quintillion configuration permutations that must be adjusted. The average IT team might never attempt to deploy something that complex, but even comparatively simple microservices-based applications can have millions of configuration permutations that can adversely impact performance and security.

    Of course, most C-level executives are likely to think highly of their organization’s IT capabilities. The rank and file, however, make assessments that are a little less rosy. The challenge is, not many IT teams have a lot of insight into how well anyone else is doing. It may be cold comfort to see that even advanced IT teams are struggling with issues.

    However, most teams that are driving revenue-generating applications for an organization will have access to more advanced IT tools a lot sooner than the average enterprise.

  • Red Hat Expands Scope, Reach of Ansible Automation Framework

    Red Hat Expands Scope, Reach of Ansible Automation Framework

    Red Hat, its online AnsibleFest 2020 conference today, announced an on-premises edition of Ansible Automation Platform dubbed Private Automation Hub and previewed technology to connect the Ansible Automation Platform managed as a cloud service by Red Hat and the on-premises edition.

    In addition, Red Hat is making available more pre-integrated workflows to its certified Ansible Content Collections service for Red Hat OpenShift, Kubernetes Core and the VMware vSphere REST application programming interface (API).

    Finally, the company previewed integration between Ansible Automation Platform and Red Hat Advanced Cluster Management, a tool originally developed by parent company IBM for managing Kubernetes clusters at scale. As part of that effort, Red Hat will integrate its implementation of Kubernetes Operators tools for deploying applications on the Red Hat OpenShift platform, which is built on top of Kubernetes, with a Resource Operator for Red Hat Advanced Cluster Management that will enable Ansible Automation Platform to execute tasks outside of the Kubernetes cluster when required.

    Joe Fitzgerald, vice president of management for Red Hat, said there are now more than 60 Ansible Content Collections available that can be deployed on-premises or in a cloud service managed by Red Hat. The connectors will make it easier for IT teams to access workflow content curated by Red Hat and its partners while continuing to create automated playbooks for their own unique IT environments that are stored locally, he said.

    As the number of IT domains to which a declarative IT automation framework can be applied continues to expand, Fitzgerald said the playbooks an IT team can create are becoming more comprehensive. Unlike other IT automation platforms, however, Ansible doesn’t require the IT operations team to learn how to code. In the wake of the COVID-19 pandemic and most employees working from home, the number of workflows that IT teams are trying to automate has increased substantially, he said.

    That framework can now also be applied to both legacy IT environments as well as Kubernetes clusters upon which the cloud-native technologies are being deployed. During AnsibleFest, Red Hat will be showing proofs of concept of support for Knative, open source middleware developed by Google that integrates serverless computing frameworks with Kubernetes clusters.

    While there are still DevOps teams that have adopted programmable frameworks to manage IT as code, many traditional IT administrators are embracing Ansible as a means to automate increasingly complex IT environments. Rather than acquiring and deploying automation tools for each platform in the IT environment, Ansible provides a common framework through which IT teams can automate the provisioning of servers, virtual machines, clusters, switches, routers and storage systems. With vendors such as Cisco Systems supporting Ansible, the number of workflows capable of spanning multiple IT domains continues to expand as internal IT teams share the playbooks either they created or had crafted for them by an IT services firm.

    Regardless of how an internal IT gains access to those playbooks, it’s probable that no matter what the automation requirement is, there is now somewhere a playbook written in Ansible to address it.

  • Puppet Deepens Windows Integration

    Puppet Deepens Windows Integration

    Puppet today announced it has extended support for Windows environments across its portfolio of IT automation tools by adding a Group Policy Migration capability that enables multiple Windows configurations to be tracked simultaneously and offering to assist organizations seeking to deploy the open source Chocolately package manager.

    In addition, Puppet has extended its support for Microsoft tools by adding a Puppet PowerShell Desired State Configuration (DSC) Builder module, through which the Powershell tools Microsoft relies on to configure operating systems are directly exposed.

    Finally, Puppet has also added a Puppet VSCode Extension that gives Windows administrators the ability to invoke the Puppet Domain Specific Language (DSL) to access capabilities such as Intellisense and error-checking using their existing user interface and text editor for Windows.

    Puppet CTO Abby Kearns said interest in IT automation has significantly increased in the wake of the downturn brought on by the COVID-19 pandemic. While IT organizations that have been running instances of Linux have had access to a broad range of IT automation tools for years, Windows environments have not enjoyed the same level of parity even though half the workloads organizations are trying to manage today are based on Microsoft.net code, she said.

    With more pressure to automate than ever, Puppet sees an opportunity to fill that void, Kearns added.

    By relying on Puppet tools to automate both Linux and Windows platforms, an opportunity to reduce the total cost of IT also presents itself as organizations look to either limit or reduce IT headcount. Puppet claims there are already more than 40,000 organizations using its tools, including more than 80% of Global 5,000 organizations.

    It’s not clear to what degree Microsoft is invested in IT automation tools, especially compared to IT vendors that make managing infrastructure as code both inside and out of the cloud their sole focus. However, since it launched Azure Microsoft has been investing in tools to manage infrastructure as code. The depth of the Puppet portfolio enables IT organizations to also apply IT automation to operating systems and now to applications via Chocolately.

    Less clear is to what degree IT organizations may finally unify the management of Windows and Linux systems as part of an effort to reduce costs in the wake of the downturn. Most organizations continue to manage Windows and Linux systems in isolation. However, as IT organizations embrace IT automation more broadly, many are looking to standardize on a common set of best DevOps practices whenever possible.

    In the meantime, the opportunity to extend IT automation into the midmarket remains significant. Most enterprise IT organizations have already embraced IT automation to a significant degree. Midmarket IT teams have generally not had the skills and resources required to manage infrastructure as code. However, as IT automation tools become more accessible to the average IT administrator, there may come a day soon when broad swaths of IT systems deployed by midmarket IT organizations will finally be automated.

  • ServiceNow Extends Reach Into DevOps Ecosystem

    ServiceNow Extends Reach Into DevOps Ecosystem

    ServiceNow this week, as part of a massive Paris update to its core software-as-a-service (SaaS) platform for managing IT operations, has extended its DevOps integration efforts by adding connectors for Microsoft Azure DevOps (ADO) and Atlassian Jira platforms.

    Pablo Stern, senior vice president for IT workflow products at ServiceNow, said those connectors are the latest in a series of moves that ServiceNow is making available to bridge the divide between traditional IT service management (ITSM) and DevOps processes.

    ServiceNow this week also announced it adding a Process Automation Designer tool to its App Engine platform for building applications on the ServiceNow platform. IT teams will be able to use that tool to create workflows spanning ITSM and DevOps processes, noted Stern.

    In addition, ServiceNow announced enhancements to its Flow Designer and IntegrationHub tools to simplify the building of workflows, and unlocked a Source Control function across its application portfolio.

    Finally, Service Now is now bringing third-party data into the ServiceNow Service Graph and Configuration Management Database to make it easier to integrate ServiceNow tools with those from partners such as SolarWinds.

    Stern said the ServiceNow strategy is not to build a DevOps platform, but rather to foster interoperability across what has become a broad DevOps ecosystem. Most IT teams are now trying to create workflows that span traditional ticket-based approaches to manage IT processes and DevOps teams that routinely leverage programming tools to automate those processes, so the goal is to enable each organization to strike a balance between those approaches as they best see fit, said Stern, citing JP Morgan as a customer using ServiceNow connectors to DevOps platforms to achieve that goal.

    Very few IT organizations are relying on DevOps processes end to end to manage IT. Organizations have been managing IT using processes based on the ITIL framework for several decades. The challenge they face is ITIL-based processes are not often agile enough to support digital business initiatives that typically require rapid responses to any event, especially when the application involved generates revenue for the business. Every second of downtime or sub-optimal performance impacts the bottom line. Minimizing disruptions to those applications requires more reliance on both automated DevOps and DevSecOps processes.

    Naturally, the arguments over the merits of DevOps versus ITIL approaches to managing IT will remain unabated for years to come. Proponents of ITIL approaches often note there are applications that are so critical to the business that a more deliberate approach to rolling them out and updating them is an absolute requirement.

    Regardless of IT philosophy, it’s clear IT and DevOps processes will be employed side-by-side for many years come. The number of IT operations professionals who have the programming skills required to automate IT processes is still fairly limited compared to the total population of IT administrators. As such, IT teams might want to focus less on the debate itself in favor of determining where they are on the maturity curve when it comes to managing IT. Once that’s determined, it then becomes a lot easier to discern the next step in their IT journey.