devopsy.kinsta.cloud

Author: Mike Vizard

  • Armory Looks to Drive Enterprise Adoption of Spinnaker

    Armory Looks to Drive Enterprise Adoption of Spinnaker

    Armory this week committed to advancing adoption of the open source Spinnaker continuous delivery (CD) platform in enterprise IT environments after revealing it has raised an additional $28 million in funding.

    Company CEO Daniel Odio said Armory will add proprietary tools to a curated distribution of Spinnaker that will make it easier for the average IT organization to deploy and manage Spinnaker. Developed by Netflix, Spinnaker is gaining traction as a CD platform in the wake of becoming one of the four projects being managed under the auspices of the Cloud Delivery Foundation (CDF), an arm of the Linux Foundation.

    Spinnaker is designed to be a CD platform that includes all the management tools required to manage that process. While continuous integration/continuous deployment (CI/CD) platforms such as Jenkins have addressed aspects of CD, most of the daily usage of those platforms has been squarely focused on continuous integration. As part of an effort to meld CI/CD platforms and Spinnaker, the CDF has accepted both Spinnaker and Jenkins as part of the first four projects that will be developed under its auspices. The other two are Jenkins X, a CI/CD platform specifically designed for building microservices-based applications on top of Kubernetes, and Tekton, a set of pipelines also designed specifically for Kubernetes.

    Odio said there are already more than 500 organizations using Spinnaker, and each one is not standardized on a specific CI/CD platform. Armory is part of the CDF but also sees a need for a curated instance of Spinnaker that is optimized to meet the needs of enterprise IT environments, he said.

    In general, Odio said a “flywheel effect” manifests once an organization launches roughly its eighth project using Spinnaker. From that point on, adoption of Spinnaker starts to accelerate to the point where an organization sees the need to standardize on a single curated instance of Spinnaker, he said.

    The bigger issue as far as adoption of Spinnaker and other DevOps tools remains cultural, Odio added. Many organizations still don’t accept the fact that CI/CD platforms are intended to foster a level of accelerated development that makes it more feasible to experiment and innovate. There are, of course, inherent risks to that approach in the sense that many of those projects might fail. Many enterprise IT organizations are still coming to terms with the need to accept higher levels of failure as the price of learning, he noted.

    In the meantime, many organizations that have embraced DevOps now find themselves on the cusp of a major transition as the shift toward cloud-native applications increases. Most CI/CD platforms today were designed to accelerate development of monolithic applications. Now what’s needed is a new generation of CI/CD platforms that are designed to accelerate development of microservices-based applications based on containers. As a result, many organizations will end up employing multiple CI/CD platforms. Armory is betting many of them will try to delineate where CI leaves off and CD begins.

    — Mike Vizard

  • With Platform, Dotscience Applies DevOps to AI

    With Platform, Dotscience Applies DevOps to AI

    Dotscience today launched a namesake platform for building and deploying artificial intelligence (AI) models based on a set of best DevOps practices.

    Company CEO Luke Marsden said that as organizations realize that AI models need to be trained and updated continuously, the need for a DevOps platform that accelerates that process will become more apparent. Today most AI models are trained over an extended amount of time and then deployed within an application environment. Over time, however, either more data becomes available or organizations determine the machine and deep learning algorithms originally used to create the AI model need to be updated or replaced. Whatever the underlying reason for replacing an AI model, a platform that addresses all the aspects of the AI model life cycle, including testing, reproducibility, accountability, collaboration and continuous delivery, is required, he said.

    To address those requirements, the Dotscience platform facilitates concurrent collaboration across developer and operations teams, version control of the model creation process, tracking of provenance records in real-time, exploring and optimizing hyper-parameters when training a model and tracking workflows across multiple open source tools.

    Most of the teams that build AI models have backgrounds in data science versus application development. As such, Marsden noted most of them have had little to no exposure to DevOps practices. In that absence of those processes, teams building AI models now routinely encounter issues such as having to navigate siloed data and technical debt, which all conspire to extend the time required to build AI model, Marsden said. In addition, teams building AI models need to keep track of not only versions, but also runs of their code that tie together input data with models and corresponding hyperparameters and metrics, he added.

    Dotscience DevOps AI platform

    In the absence of a DevOps platform such as Dotscience, it becomes challenging for organizations to document what changes were made to an AI model when, Marsden said. That governance issue has become especially problematic when it comes to AI models because organizations are coming under increased regulatory pressure to document how the AI models they are employing are built and updated.

    Dotscience’s “The State of Development and Operations of AI Applications” report also published today identifies the top three challenges with AI workloads are duplicating work (33%), rewriting a model after a team member leaves (27.6%) and justifying its value (27%). Based on a survey of 500 industry professionals, the report also finds 52% of respondents track provenance manually using tools such as spreadsheets, while 27% don’t track provenance at all but think it is important. In total, the survey finds 63% of businesses report they are spending between $500,000 and $10 million on their AI efforts.

    As more organizations rely on DevOps processes to build and deploy applications, there’s no doubt that teams building AI models that need to be inserted into those applications will have to fall in line with best DevOps practices. That challenge now is finding a way to extend those DevOps processes all the way back to the building of the AI models themselves. Only then is the AI model building and deployment process likely to become agile enough to stay relevant to the pace of change now occurring across digital business processes.

    — Mike Vizard

  • DevOps Deeper Dive: BMC Software Bets on AIOps Transformation

    DevOps Deeper Dive: BMC Software Bets on AIOps Transformation

    As BMC tests the AIOps waters, the company seeks to find a balance in serving both the DevOps and ITIL populations

    It’s clear in the enterprise IT space that artificial intelligence (AI) is poised to play a significant role in IT operations, a phenomenon known as AIOps. Often with this level of IT disruption, new entrants funded by venture capitalists flood the segment, leaving incumbents to either fend off the new rivals, cede ground or, in many cases, put an end to the threat by acquiring one or more those startup companies that pose a threat to their existence.

    In the case of BMC Software, it has decided to stand its ground by aggressively investing in AIOps research and development. Most recently, BMC extended the AIOps capabilities of its existing portfolio of TrueSight IT management software through additional advanced analytics to identify patterns and anomalies within an IT environment. Other examples of BMC employing machine learning algorithms to automate IT environments tools include the ability to surface continuous recommendations for cost optimizations and automated event remediation workflows that promise to reduce the mean time to repair (MTTR).

    BMC has been making a case for AIOps as far back as 2017, but it’s only now that many organizations have enough confidence in AI to start embracing AIOps beyond the pilot stage. The challenge organizations face with AIOps are both technical and cultural: It requires a significant amount of time and effort to train and tune an AI model of each customer environment.

    [su_box title=”BMC Software Milestones”]

    • Dec. 2016: Peter Leav succeeded Bob Beauchamp as president and chief executive officer. Beauchamp remains chairman of the board of directors.
    • Oct. 2017: BMC Launches First AIOps Initiative for TrueSight
    • Nov. 2017: BMC Refinances Debt
    • Oct. 2018: BMC Software Goes Private After Being Acquired by Investors
    • Feb. 2019: BMC Partners with IBM on AI
    • April 2019: Bob Beauchamp resumes role as CEO
    • June 2019: BMC Extends AIOps Capabilities of TrueSight

    [/su_box]

    In addition, the effectiveness of any AIOps model varies based on the complexity of the IT environment. Organizations also should be concerned about the potential impact any flawed AI model might have on IT operations—it’s one thing for a human to make a mistake, but an AI model making a mistake at a level of scale could be catastrophic.

    From a cultural perspective, not every organization is yet comfortable with those AI models on current staffing, which can make some members of the IT staff less than comfortable with the whole concept.

    BMC CEO Bob Beauchamp

    It is early days for AIOps in DevOps processes. But the increased complexity of modern IT environments based on cloud-native technologies will force the issue within most organizations. BMC’s challenge is that while its management platform is employed widely in IT environments relying on ITIL-based frameworks, its footprint is comparatively nascent within organizations that have embraced best DevOps practices.

    Bill Talbot, vice president of solutions marketing for BMC, said one of the company’s advantages is access to the massive amounts of data required to train an AI model effectively. Most startup companies in this space don’t have nearly the same depth in terms of customer base, he said. That puts BMC in a better position to employ big data analytics to identify patterns and trends across multiple customers without having to know what data came from any one specific customer, unless the customer elects to share its data with BMC.

    BMC makes it a point to caution customers about rivals that make AIOps claims about their platforms but don’t actually solve a specific problem—a process known as “AIOps washing.” An AIOps platform not only needs to leverage Big Data analytics and machine learning, but it also provides the code and functionality needed to customize specific IT operations use cases, including capabilities such as automated event remediation and service resolution, optimized cost and capacity management and proactive vulnerability mitigation.

    BMC Software today stands at a crossroads. The company recently brought back former longtime CEO Bob Beauchamp to run the company day to day and has made no secret of the fact it is looking for additional investors. Making a pivot to AIOps requires access to massive amounts of funding for incumbents and startups alike.

    The next BMC act undoubtedly will involve employing AIOps across both DevOps and ITIL-based environments running on-premises and in the cloud. By any measure, that effort represents one of the most ambitious transformations ever attempted by any IT vendor.

    — Mike Vizard

  • Mendix Injects More AI to Accelerate Low-Code Development

    Mendix Injects More AI to Accelerate Low-Code Development

    The rate at which low-code applications are built and deployed will accelerate as developers begin to rely more on artificial intelligence (AI) to write code. The summer 2019 release of the Mendix low-code platform includes a revamped instance of Mendix Assist, which employs machine learning algorithms to make coding recommendations. Those algorithms have been trained using data drawn from 5 million application models employed across 15 industries over the last 10 years, and Mendix claims this version of Mendix Assist improves the accuracy rate of the recommendations being made to 95%.

    Sheryl Koenigsberg, director of product and solutions marketing for Mendix, said Mendix Assist will enable new developers to write better code faster, while experienced developers will be able to employ Mendix Assist to address routine issues that often get overlooked faster. Mendix Assist not only advises developers on what to do next but also generates recommended actions in previous logical steps based on whatever new code is introduced in the application.

    Mendix

    To make these capabilities more accessible, the summer release of Mendix adds Mendix Studio and Studio Pro, a set of integrated development environments designed to be accessible to both citizen and professional developers, to the low-code platform.

    In addition, Mendix is adding support for native mobile application development by adding support for React, a set of JavaScript libraries for building user interfaces for mobile applications, and including a native JavaScript editor. Those capabilities eliminate the need to rely on emulation software when building mobile computing applications, said Koenigsberg. Because the Mendix IDEs integrate low-code abstraction across iOS, Android, Java and Objective-C programming models, it also becomes easier for mobile developers to build reusable components. Mendix has also included more than 50 pre-built connectors to mobile device capabilities, such as camera, geolocation, biometric authentication and Bluetooth enablement, along with support for conversational chatbots and voice interfaces such as Alexa and Siri.

    Longer-term, Koenigsberg observed that it’s conceivable the AI capabilities being included in application development tools eventually will share insights with AI models being incorporated into continuous integration/continuous deployment (CI/CD) platforms. Proposed changes to an application could, for example, might be assessed from a performance perspective before any lines of code are written.

    In the meantime, the rate at which low-code applications will be moving through CI/CD platforms is about to increase substantially as developers augment their own skills by relying more on recommendations surfaced by AI engines. The quality of those applications should also improve as AI engines check, for example, to make sure all the appropriate compliance and cybersecurity controls are in place.

    It’s not likely AI engines will replace the need for developers anytime soon. However, it is apparent all the little things that routinely conspire to slow application development and delivery processes increasingly will be automated. That should make it easier for a larger number of organizations to embrace best DevOps processes. After all, the primary issue with DevOps adoption these days is not necessarily appreciating the value of the concept, but rather managing pipelines that still tend to get clogged every time an application fails to pass a gate because a developer forgot to do one thing or another.

    — Mike Vizard

  • Stackery Smooths AWS Serverless Integration for DevOps

    Stackery Smooths AWS Serverless Integration for DevOps

    Stackery today announced a plug-in capability that will allow developers to build and debug code destined to run on the Lambda serverless computing service provided by Amazon Web Services (AWS) from within an integrated development environment (IDE) running on a local machine.

    Company CTO Chase Douglas said the latest Stackery tool can be dropped into any IDE, either via a Stackery VS Code Serverless Tools Plug-In that automates installation or a manual installation process, regardless of the programming language being employed. The goal is to make it easier for DevOps teams to construct workflows that include AWS serverless computing frameworks, which now are expanding rapidly, he said. In total, the Stackery tools can invoke any one of 86 AWS CloudFormation-compatible resources.

    Stackery provides a set of visual tools that make it easier to write functions for the AWS Lambda service without having to know how to create YAML files to manipulate infrastructure as code. This latest offering extends that capability to local environments, which will allow DevOps teams to work offline on their laptops and make changes without having to make every change on the AWS cloud over an internet connection. This capability does not require customers to set up a Stackery account to use it.

    Right now, Stackery is squarely focused on providing those tools for AWS environments, but Thomas said eventually those tools will be extended to other serverless computing environments.

    The goal is to provide DevOps teams with tools that make all serverless computing frameworks more accessible to both developers and IT operations teams, Douglas said.

    Serverless computing frameworks are gaining in popularity because they make it easier for developers to invoke additional IT infrastructure resources to kick off, for example, an analytics module whenever a certain event occurs within their application. That capability reduces the amount of code developers need to include in their core applications. Serverless computing frameworks are usually employed to run stateless processes for a very short amount of time, while containers and virtual machines continue to be relied on for running longer running applications. But for DevOps, that creates another layer of abstraction to include within the context of a larger continuous integration/continuous deployment workflow.

    Most organizations are already struggling with mastering the workflows they employ to manage the building and deployment of applications using containers and virtual machines, so any new abstraction layer of compute resources need to incorporate within the workflows easily if the providers of that service hope to achieve mainstream adoption among DevOps practitioners. Long-term, of course, the expectation is all these processes will be completely automated, which means developers only will have to ever worry about writing business logic.

    In the meantime, it’s likely to be a while before DevOps shops are invoking multiple serverless computing frameworks running on different clouds, much less automating them on end to end. That day, however, may not be as far off as people today might assume.

    — Mike Vizard

  • Morpheus Data Simplifies Management of Ansible and Kubernetes

    Morpheus Data Simplifies Management of Ansible and Kubernetes

    Morpheus Data is moving to make it easier to adopt and manage both Ansible and Kubernetes. Its Morpheus 4.0 update, announced today, includes a distribution of Kubernetes as well as tighter integration with the open source Ansible automation framework.

    Brad Parks, vice president of marketing and business development for Morpheus Data, said in the case of Ansible, Morpheus 4.0 will eliminate the need for some organizations to employ Ansible Tower, a web-based console and application programming interface (API) used to manage instances of Ansible. The goal is to make it easier for organizations to take advantage of the declarative Ansible automation framework without having to master all the low-level minutiae currently required to deploy and manage it, he said.

    Morpheus 4.0 also makes it possible to view real-time job status updates and detailed log output and execute phased-based and operational workflows using multiple playbooks and brings governance, auditing and reporting tools to Ansible. Morpheus 4.0 also makes it possible to configure Ansible to run over the Morpheus secure agent communication bus, allowing playbooks to be applied to instances where SSH/WinRM access may not be feasible due to security constraints. Available on both Linux and Windows platforms, Ansible also can employ that bus to query secrets securely from the Morpheus Cypher service for storing application secrets.

    In a similar vein, Morpheus Data is also moving to automate the deployment and management of Kubernetes, an open source container orchestration engine developed under the auspices of the Cloud Native Computing Foundation (CNCF).

    By including a distribution of Kubernetes in Morpheus 4.0 that has been certified by the CNCF, Parks said Morpheus Data now makes it possible to federate the management of Kubernetes clusters across a hybrid cloud computing environment. DevOps teams can employ either the distribution of Kubernetes provided by Morpheus Data or Morpheus to provision instances of Kubernetes services provided by public cloud service providers such as Amazon Web Services (AWS), Microsoft and Google.

    Morpheus 4.0 also makes it possible to securely share and govern resources using role-based access controls, optimize resource allocation using analytic tools and audit, monitor and manage logging. DevOps teams also have the choice of provisioning applications using either Morpheus or the Helm templates made available by the CNCF.

    As Kubernetes moves into the enterprise, Parks said IT organizations will need a management framework that can automate the provisioning of application stacks on any combination of legacy virtual machines, Kubernetes clusters and bare-metal servers. Rather than be required to acquire and master separate tools for each platform, Morpheus 4.0 provides a management platform that allows a single DevOps team to manage multiple platforms more easily, he said. As an enterprisewide orchestration and automation platform, Morpheus is designed from the ground up to eliminate the need for DevOps teams to create complex playbooks by providing out-of-the-box integration with wide a variety of IT platforms, Parks added, noting Morpheus 4.0 also now includes Morpheus Jobs, a tool through which jobs can be scheduled or run ad-hoc using Bash, PowerShell, HTTP, Ansible, Chef, Puppet, Groovy, Python, jRuby or JavaScript.

    The number of organizations attempting to unify the management of multiple platforms is expected to increase significantly in the months and years ahead as the number of cloud platforms being employed increases. The challenge those organizations will face involves not only what tools to employ to achieve that goal, but also defining the DevOps processes capable of spanning a hybrid cloud computing environment.

    — Mike Vizard

  • Micro Focus Lays DevOps Foundation for RPA

    Micro Focus Lays DevOps Foundation for RPA

    Micro Focus has announced the general availability of Micro Focus Robotic Process Automation (RPA), which sets the stage for employing DevOps processes to construct highly automated business processes.

    Thanks to the rise of artificial intelligence (AI) and digital business transformation initiatives, interest in RPA has increased significantly. However, rather than merely using RPA to build bots to automate a narrow set of static processes, RPA is now leveraging machine and deep learning algorithms to optimize a wider range of dynamic business processes and adjust more easily to changes within an application.

    Travis Greene, senior director for IT operations management ay Micro Focus, said new capabilities such as object recognition technology included within Micro Focus RPA enables the platform to detect and automatically adapt to changes to the user interface.

    Other new capabilities now include the ability to visually or programmatically create workflows using a tool that records screen actions, the ability to more easily combine graphical and programmatic workflows spanning multiple platforms and the ability to deploy hundreds of thousands of bots as needed. A centralized dashboard manages the bots, all of which have unique IDs and encrypted, role-based credentials.

    As RPA and other forms of AI continue to be integrated and embedded with applications, Greene said it’s a matter of time before DevOps practices are extended to RPA platforms. Organizations will seek to train bots continuously as more data is made available, which in turn will drive updates to applications that are dependent on those bots. In most cases, depending on the complexity of the task, the bots will be built using a mixture of application programming interfaces (APIs), command-line interfaces (CLIs) and graphical tools. Organizations will need to define the processes to determine how and when each organization will opt to invoke one interface instead of another, either in isolation or combination, added Greene.

    Historically, organizations have been able to apply RPA to static processes with mixed success. With the rise of AI, the scope of those efforts has become more ambitious. Business leaders are too inclined to believe that just about every business process can be automated using a combination of AI and RPA. However, AI and RPA still are confined to relatively narrow use cases involving highly predictable outcomes.

    That’s changing, however, and RPA and AI are becoming more pervasive across the enterprise. DevOps teams will need to find ways to update both their applications and RPA/AI models without breaking one or the other. Most of the current RPA/AI models are highly sensitive to any change made to the application environment they are monitoring. And, unfortunately, the data scientists who are largely responsible for constructing those RPA/AI models don’t yet tend to have much of an appreciation for best DevOps processes. There will, however, come a day soon when these two worlds will collide.

    — Mike Vizard

  • ASF Moves OpenWhisk Serverless Computing Forward

    ASF Moves OpenWhisk Serverless Computing Forward

    The Apache Software Foundation (ASF) announced today that the OpenWhisk serverless computing framework has now become a high-level open source project.

    Matt Rutkowski, CTO for serverless technologies and advocacy for IBM, said with this announcement, organizations looking to implement an open source serverless computing framework on-premises or in a public cloud now can have confidence the OpenWhisk project is sustainable beyond the handful of vendors, including IBM, that launched it.

    IT organizations of all sizes are embracing serverless computing frameworks as a way to invoke application programming interfaces (APIs) to make additional compute resources available on-demand based on an event. For example, rather than having to embed a lot of additional analytics code within their application, developers alternatively might invoke a serverless computing framework such as OpenWhisk to run analytics whenever necessary.

    The most widely used serverless computing framework today is the Lambda service from Amazon Web Services (AWS). However, rival cloud service providers have been embracing various open source alternatives to provide similar capabilities. At the same time, some internal IT operations teams are deploying serverless computing frameworks to provide similar capabilities within an internal IT environment.

    Regardless of the approach, Rutkowski said hooks to serverless computing frameworks soon will become ubiquitous hooks within continuous integration/continuous deployment environments. In fact, DevOps environments are likely to expose multiple hooks to different serverless computing frameworks as cloud computing becomes more hybrid, he noted. Plugging in multiple serverless computing frameworks should be relatively trivial because the difference in application programming interface (API) parameters between different serverless computing frameworks is minimal, he added.

    While interest in serverless computing has been running high, deciding which open source serverless computing framework to embrace has been something of a challenge. There are at least a half-dozen active serverless computing frameworks, with new ones being added regularly while other projects fade away. The Cloud Native Computing Foundation (CNCF) has made a point of not endorsing any one serverless computing framework in the expectation that many will be adopted for various use cases. Instead, the CNCF has thrown its weight behind a Knative project that provides the middleware required to integrate Kubernetes clusters with multiple serverless computing frameworks.

    Those serverless computing frameworks have already had a profound impact on containerized applications. The first generation of containerized applications was largely stateless. Now stateless functions increasingly are being processed via a serverless computing framework, while stateful applications based on containers that tend to run longer are just now starting to be deployed in production environments.

    Of course, the one fact many IT organizations fail to appreciate is that serverless computing frameworks are built using containers. A serverless computing framework is really a higher-level abstraction of a container platform. The challenge organizations will face now is teaching developers when to rely on a more traditional container platform versus invoking a serverless computing framework to run a child process, for example.

    Whatever path those developers choose, the one thing that is for certain is existing DevOps processes will need to be adjusted accordingly.

    — Mike Vizard

  • WSO2 Advances Microservices Gateway

    WSO2 Advances Microservices Gateway

    At the Open Source and Software Development Conference (OSCON), WSO2 this week announced it has updated an open source microservices gateway to make it possible to expose multiple microservices through a single application programming interface (API).

    Additionally, version 3.0 of the WSO2 API Microgateway now includes the ability to automatically discover microservices and transform legacy API requests into a more modern format. WSO2 also added support for the OpenAPI Specification (OAS), formerly known as Swagger, to make it easier for developers to collaborate on creating APIs, and has separated the WSO2 API Microgateway toolkit from the runtime to enable greater scalability and smoother upgrades.

    Ken Oestreich, vice president of product marketing for WSO2, said the WSO2 API Microgateway is designed to accelerate the convergence of application development and integration into a single team. As part of that effort, WSO2 has been advocating the adoption of Ballerina, a general-purpose programming language designed from the ground up to make it easier for developers to integrate distributed applications on their own. For example, Ballerina makes it possible for developers to create and embed their own micro-enterprise service bus (ESB) within a distributed application, he said.

    Those integration engines then could be deployed and updated within any DevOps processes layered on top of a continuous integration/continuous deployment (CI/CD), Oestreich added.

    A WSO2 API Microgateway is designed to boot up in less than a second and provides authentication, authorization, rate limiting, service composition, discovery, transformation and analytics capabilities. It is designed to be integrated with the WSO2 API Manager, an open source API management platform that can run on-premises or in the cloud.

    As the number of microservices being created within organizations increases thanks to the rise of containers, Oestreich noted there is now a critical need for organizations to find a lightweight approach to building and managing all the APIs required to connect thousands of microservices. WSO2 provides a flow diagram through which organizations can visually manage that process, said Oestreich. As part of its support for containers, the WS02 API Gateway provides built-in support for container orchestration tools such as Kubernetes, which makes it possible to generate artifacts that can be applied directly to Kubernetes clusters.

    Organizations of all sizes are clearly struggling these days with API management. In theory, APIs should remain stable as the software components they connect to are updated. The trouble is, each new microservice generates its own set of APIs, and before too long, organizations find themselves trying to manage thousands of APIs that are all dependent on each other. The removal of any one API might not crash an application, but it could adversely impact performance as API calls are re-routed around the application.

    It’s not all clear these days who inside most organizations is responsible for managing APIs. Developers certainly create the APIs. However, once they are deployed in a production environment, their care and feeding often pass over to an IT operations team. Regardless of whom, however, once any of those APIs break it’s not long before the entire DevOps team knows about it. The challenge now is figuring out how to make the management of all those APIs as natural an extension of a DevOps process as possible.

    — Mike Vizard

  • Datadog Fetches Bevy of Additional DevOps Services

    Datadog Fetches Bevy of Additional DevOps Services

    At its Dash 2019 conference today, Datadog launched a series of DevOps initiatives that significantly expand the use cases for the agent software that drives the company’s monitoring services.

    Additions to the Datadog portfolio include Network Performance Monitoring and Real User Monitoring (RUM) services as well as general availability of a previously announced service for monitoring serverless computing frameworks.

    In addition, Datadog announced it is adding Tracing without Limits to its application performance monitoring (APM) and distributed tracing service that allows DevOps teams to search all traces without live sampling and store the traces matching bad user experiences for the long-term.

    Finally, Datadog is adding support for log rehydration and the ability to generate custom metrics from ingested log data residing within its log management service.

    Ilan Rabinovitch, vice president of product and community for Datadog, said the company continues to invest in expanding the core use cases for which its agent software can be applied. Over time, that approach will enable DevOps teams to rationalize the types of agent software they need to deploy to monitor applications, cybersecurity, infrastructure, networking and user experience, he said.

    Rabinovitch noted that interest in extending the reach and scope of Datadog services into the realm of networking is especially high because DevOps teams today have little visibility into how the various software-defined network (SDN) services provided by cloud service providers are impacting their applications.

    DevOps teams are also now being asked to present IT metrics in a way that reflects actual end user experiences. The RUM service being provided by Datadog achieves that goal by making it easier to track front-end latency metrics such as time to interactive and time to first byte, in addition to providing a geographic location, the operating system and browser types being employed by the end user.

    Rabinovitch noted that as organizations become more dependent on digital business processes, they are moving to instrument every aspect of delivering IT services. For example, APM in the past might have been limited to a handful of mission-critical applications running on-premises. Now, as more digital business applications become distributed across both cloud and on-premises IT environments, the need for visibility across interdependent applications and microservices has become more acute, he said, adding most organizations would prefer to consume monitoring as a service versus having to deploy and maintain that software themselves.

    It’s unclear how being able to apply a common base of agent software might accelerate the convergence of job functions within an IT organization. But it does make it easier for cross-functional IT teams to collaborate and troubleshoot IT environments so all members of a team can use a common management platform to identify issues. In many cases, the amount of time saved by eliminating the need to convene a “war room” meeting whenever a new issue is discovered might in and of itself be priceless.

    — Mike Vizard