staging-devopsy.kinsta.cloud

Category: DevOps Toolbox

  • Are Self-Service Machine Learning Models the Future of AI Integration?

    Are Self-Service Machine Learning Models the Future of AI Integration?

    DevOps teams seeking to step up their mojo in developing cutting-edge artificial intelligence (AI) features are facing a big skills bottleneck when it comes to data analytics and machine learning modeling. As a result, the market is seeing an influx of self-service machine learning models and machine learning-as-a-service offerings designed to help development teams more easily integrate AI capabilities into their software.

    This is coming in direct response to an explosion in demand for AI capabilities in the enterprise. According to Gartner analysts, AI adoption in the enterprise tripled in the past year. A report last fall from MIT Sloan Management Review and Boston Consulting Group found that 91% of enterprises believe that AI will deliver new business growth to them by 2023.

    The trouble is that folding AI functions and predictive analytics into software requires a whole new level of expertise in data science and machine learning from cross-functional DevOps teams. They need added skills to choose the right algorithmic approaches, acquire and manage data, train the models and integrate them into the code base and underlying infrastructure so that everything works properly under the hood.

    “We have heard from customers everywhere that they want to adopt machine learning but struggle to actually get models into production,” said Eric Boyd, vice president of cognitive and AI for Microsoft.

    Ali Farhadi Xnor
    Ali Farhadi, Xnor.ai CEO

    DevOps leaders today already face an uphill battle to keep their developer ranks staffed with well-trained software engineers. Piling on additional requirements for very specialized machine learning and data science expertise further strains those recruitment efforts. According to the most recent Harvey Nash/KPMG CIO Survey, the top one and two technical realms that suffer the biggest skills shortages today are in data science and AI, with 46% and 38% of CIOs respectively reporting recruiting pain in those areas.

    “There’s a huge imbalance between the demand in the market and the supply of the very best AI experience to actually train these models,” said Ali Farhadi, CEO of Xnor.ai, a Seattle firm that just last week released a self-service platform for developers. Called AI2Go, the platform provides pre-trained deep learning models to quickly integrate AI features such as facial recognition and object classification directly into their software.

    “We want to enable anyone who can code to benefit from AI,” Farhadi said.

    The Xnor release comes just a few weeks on the heels of a big launch from Microsoft of several self-service machine learning model tools aimed firmly at MLOps teams—those DevOps teams implementing machine learning capabilities. The new services from Microsoft roll out capabilities to manage the code, data and environments used by MLOps teams throughout the machine learning deployment life cycle.

    “Azure Machine Learning service’s MLOps capabilities provide customers with asset management and orchestration services, enabling effective ML lifecycle management,” explained Jordan Edwards, senior program manager for Azure MLOps, in a blog post on the topic. “With this announcement, Azure is reaffirming its commitment to help customers safely bring their machine learning models to production and solve their business’s key problems faster and more accurately than ever before.”

    Tools such as these are not always going to obviate the need for data scientists and machine learning/AI specialists on DevOps teams. As Farhadi noted, even a simple service like AI2Go requires development teams to choose the right models for the right situations. Nevertheless, this burgeoning market could take the pressure off teams by minimizing the scale of specialized recruiting, while reducing bottlenecks and dreaded re-work.

    “Machine learning projects usually involve several people—data engineers, data scientists, DevOps and others. Conventionally, at each stage of the machine learning life cycle, most, if not all, of these people end up doing an excess of custom coding, redundant work and manual trial and error,” said Craig Stewart, senior vice president of product management and product marketing for SnapLogic, which last fall introduced a self-service machine learning add-on for its integration platform. He noted that one of the primary goals is speed, to help cross-functional teams “build, train, validate and deploy high-performing models faster.”

    — Ericka Chickowski

  • CircleCI Adds Integration With Atlassian Jira

    CircleCI Adds Integration With Atlassian Jira

    One of the trickier issues IT vendors in the age of DevOps are dealing with is that very few organizations have standardized on a platform from a single vendor. Not only do organizations mix and match tools as they see fit, but different departments within the same organization also embrace different tools to automate the same tasks. That DevOps reality requires collaboration between IT vendors that normally would prefer to not work together, whether they like it or not.

    Case in point is a move by CircleCI, a provider of a continuous integration/continuous delivery (CI/CD) platform, to provide integration with the Jira project management software developed by Atlassian. While Atlassian makes its own CI/CD platform, customers and business partners alike have made it clear they needed CircleCI to support Jira, says Tom Trahan, head of business development for CircleCI. In some cases, those organizations have adopted Jira without having Atlassian’s CI/CD platform in their environment, while in other cases, a department within one part of an organization has opted for CircleCI while others are employing a CI/CD platform from Atlassian.

    At the same time, Trahan notes that many DevOps projects now span multiple organizations that have standardized on different DevOps platforms. Jira provides a way for teams in differentorganizations to manage those projects collaboratively, he says.

    To achieve integration with Jira, CircleCI now offers its CircleCI for Jira module, through which teams can assign new tasks and fixes based on job status with CircleCI orbs, a set of reusable configuration packages that allow CircleCI customers to integrate external tools into their workflow. That capability also makes it possible to launch new Jira issues directly from the job page within the CircleCI user interface.

    CircleCI Integrates with Jira

    Trahan says that in the polyglot world of DevOps, it is apparent vendors are being required to expose open application programming interfaces (APIs) that enable organizations to build and integrate various DevOps platforms anyway they want. Organizations won’t consider IT vendors that are too rigid in terms of what level of integration they enable, he says.

    As DevOps continues to evolve, it’s clear that a wave of merger and acquisition activity is makeing the IT vendor landscape somewhat volatile. Providers of DevOps tools that organizations have standardized on are being acquired at a rapid rate. IT organizations can’t be certain that any given tool or platform they are using won’t be scooped up by a vendor they might not want to engage. In that kind of environment, it’s critical for IT organizations to leverage open APIs that not only make it easier to collaborate, but also replace elements of their DevOps stack whenever they deem necessary.

    The challenge, of course, is that IT vendors are always trying to lock customers in as much as they can. Those efforts are not as heavy-handed as they once might have been. But almost inevitably, the extension being offered to access functionality will disappear if the underlying platform that enables it suddenly disappears. IT organizations, therefore, need to determine whether those extensions are worth any potential trouble they might cause somewhere down the DevOps road.

    — Mike Vizard

  • The Essential Toolbox for DevOps Analytics

    The Essential Toolbox for DevOps Analytics

    With DevOps teams under constant pressure to improve software delivery cycles while maintaining—and improving—quality, many have turned to continuous testing (CT), implementing it as part of their overall development strategy. CT offers a number of benefits to DevOps teams, but it also introduces new challenges, specifically infinite amounts of data that require analysis. As more teams integrate CT into their strategy, it is clear that analyzing, understanding and filtering the results data quickly is critical to preventing bottlenecks in the DevOps process. The problem is, teams simply don’t have the time needed to analyze data.

    Current research indicates that teams spend anywhere between 50 and 72 hours per regression cycle analyzing test results. This includes filtering out noise and assessing failures that may impact their software releases. However, the amount of time DevOps teams have to review and qualify test results has shrunk dramatically in recent years—from days to hours or even minutes, in some cases—leaving teams scrambling.

    With pressure to accelerate velocity and deliver consistent, high-quality experiences, DevOps team require new analytics solutions to help them manage large test-results datasets in a CI/DevOps environment.

    Let’s explore five essential tools that enable DevOps teams to quickly and efficiently analyze data, triage issues and act upon failures with the best possible insights.

    Executive Dashboards

    Dashboards have evolved immensely over the years, allowing dev managers and QA managers to easily examine the pipeline, see CI trends related to time, build health and more. When looking for the best solution, make sure it includes quality heat maps and CI dashboards, which make it easy to spot an anomaly in the CI pipeline and allow managers, DevOps teams and practitioners to quickly drill down into the single test report and the issue.

    Single Test Report Visibility With Advanced Reporting Artifacts

    With a single test report, practitioners have access to the entire flow of test steps, video, logs, screenshots and Jira–even the ability to drill down into the source code. This makes it quick and easy to locate an issue. For teams, these means more time fixing and less time searching.

    Cross-Platform Reports

    These analytics reports show the UI/UX simultaneously across multiple screen sizes, resolutions and platforms. Since the boundaries between the digital platforms need to be seamless, whether on desktop browsers or mobile devices, having the ability to see the UI/UX on multiple form factors (and layouts) at the same time is essential to assess overall quality.

    DevOps Noise Reduction Tools Powered by AI and Analytics 

    Today, finding which error classifications are true application bugs is critical to efficiency. Noise reduction tools that are powered by AI allow teams to filter out problems caused by various issues that are not software defects—for example, device connectivity issues and wrong scripting. Having a tool with the ability to locate each failed test execution, the root cause and the classification category is a huge productivity boost for both the test engineer and the developer.

    DevOps and Actionable Insights

    Analyzing data is one thing, knowing what to do it with it is another. Today, there are a number of analytics solutions on the market that provide teams with both capabilities. Once an issue is detected, classified and reported, having deep insight brings practitioners halfway toward the resolution of the issue.

    To succeed in software delivery, teams not only need better automation as part of their processes, test flows and CI/CD workflows, but also an analytics platform to manage all of their test results data. Since DevOps involves a collection of team members from all parts of the software delivery lifecycle (SDLC) process, the central platform needs to meet the needs of all team members. As you work to build your next test analysis toolbox, consider the five features above to efficiently evaluate the data, act upon it and deliver iterations and features with confidence.

    — Eran Kinsbruner

  • Chef Extends Automation Reach and Scope

    Chef Extends Automation Reach and Scope

    At its ChefConf 2019 conference today, Chef extended its core platform in ways that collectively serve to automate further the management of applications and the IT infrastructure they are deployed on.

    Extensions to the Chef Enterprise Automation (EAS) Stack include the addition of Application Operations Dashboards, Migration Accelerators for moving applications to the cloud and tighter integration between the Chef Infra and Chef InSpec modules within the Chef Habitat management framework.

    Brian Goldfarb, chief marketing officer for Chef, said these latest additions to Chef Enterprise Automation Stack are part of an ongoing Chef initiative to make it easier to seamlessly unify the management of infrastructure and applications in keeping with best DevOps practices, which Chef refers to as the “Coded Enterprise.”

    Chef DashboardAs part of that effort, Chef Application Operations Dashboards provide visibility into both applications and infrastructure to simplify troubleshooting and compliance, said Goldfarb. For example, IT teams will be able to see how individual security and compliance controls are performing across a heterogeneous computing environment that now includes Microsoft Azure and Google Cloud Platform (GCP) alongside Amazon Web Services (AWS), he said.

     

    At the same time, Chef is trying to make it easier to lift and shift applications to the cloud. EAS Migration Accelerators automate an application migration process that today requires most organizations to spend considerable time and effort to accomplish manually, said Goldfarb.

    An EAS Migration Accelerator for Windows, for example, will scan existing .NET applications running on IIS to discover configuration and dependency details and then package that information as code. That approach significantly reduces the time required to build application packages in Chef Habitat.

    Within Chef Habitat, the integration between Chef Infra, for automating infrastructure configuration, and Chef InSpec, a tool for automation compliance, is now more unified via pre-configured compliance profiles and cookbooks that make it easier to customize and modify which security and compliance controls are tested and enforced.

    Finally, Chef has also added support for high availability to the EAS platform to make sure the environment is always accessible.

    Goldfarb said the goal is to continue to make automation more accessible to IT generalists versus requiring them to hire and train dedicated specialists. One of the primary reasons that DevOps practices have been adopted so unevenly within IT organizations is the bar to master them has been set too high. By making it easier to automate the management of both infrastructure and applications, Chef is moving to lower that bar and make it easier to manage IT by unifying the management of applications and infrastructure, said Goldfarb.

    It’s too early to say to what degree IT automation will advance the adoption of DevOps. What is apparent is that IT environments are becoming too complex for mere mortal IT administrators to manage manually. IT organizations are also expected to be able to respond faster to any issues that arise, which requires IT teams to have a unified view of applications and the infrastructure o which they are deployed. In fact, as IT organizations continue down that IT automation path, many of them one day may discover they have embraced DevOps without even realizing it.

    — Mike Vizard

  • Survey Finds CI/CD Adoption Has Long Way to Go

    Survey Finds CI/CD Adoption Has Long Way to Go

    At the KubeCon + CloudNativeCon Europe 2019 conference, Codefresh published the results of a survey of 130 developers that finds not only are nearly a third (32%) not using any type of continuous integration/continuous development (CI/CD) platform at all, but 60% said their organization has yet to take full advantage of automation to accelerate application development and deployment.

    In fact, according to the survey, it takes more than two weeks for two-thirds of developers (64%) to push a commit into a production environment. Additionally, the survey finds that for 39% of respondents, less than 10% of their company’s processes are automated from Git commit to code to production.

    Not surprisingly, only 19% of developers said they deploy code at least once daily. Roughly a third said they release code into a production environment only once a quarter. At that rate, it may be difficult for those organizations to justify investments in a CI/CD platform.

    Dan Garfield, chief technology evangelist for Codefresh, which develops a CI/CD platform, said that while much progress still need to be made in terms of spurring adoption of CI/CD platforms and best DevOps practices, the shift toward microservices-based applications inevitably will force the issue. The inherent complexity associated with building and maintaining applications consisting of hundreds of microservices based on containers, which regularly are ripped and replaced, will require all development teams to adopt a CI/CD platform. Right now, however, the shift to microservices is even less nascent than DevOps—21% of survey respondents said they are not employing cloud-native architectures because they are overwhelmed by the prospect.

    Garfield said once organizations more aggressively embrace microservices to increase the rate at which applications are developed and deployed, Codefresh is betting most will opt to standardize on a CI/CD platform based on Kubernetes. Most organizations have come to realize they will be building and deploying applications across multiple clouds. A CI/CD platform based on Kubernetes, such as the one offered by Codefresh, enables organizations to consistently apply the same set of best DevOps practices, he said Garfield. As such, competition among vendors that provide CI/CD platforms based on Kubernetes is sure to be fierce in the months ahead.

    In the meantime, a 10-year effort to convince organizations to employ best DevOps practices more broadly appears finally to be on the cusp of becoming mainstream. Organizations of all sizes have embraced DevOps unevenly. In fact, while most organizations have been able to achieve continuous integration with a handful of development teams, very few organizations are anywhere near close to achieving continuous delivery of application code within a production environment.

    The shift to modern applications based on containers, however, will require most organizations to standardize on a set of best practices across the enterprise. Pressure to deliver applications faster in the age of digital business transformation is mounting with each passing day. The only unknown at this point is to what degree will organizations be able to automate those processes.

    — Mike Vizard

  • Using Automation Tools to Drive Collaboration, Innovation

    Using Automation Tools to Drive Collaboration, Innovation

    How automation can help business move past the walls of confusion between dev and ops

    In the current state of things, businesses are leaning more than ever on the collective intelligence of their tech teams to drive innovation within their respective organizations. These teams are always comprised of developers and operations professionals. With the foray into automation and the desire for companies to do more with less, it has never been more critical that all individuals, regardless of team, come together to do amazing things. Of all of the services available, Chef is a great example of a suite of tools that want to empower teams to do just that: come together and innovate. It is all about bridging gaps, which can range from simply redefining how teams think about each other to more complex things such as knowledge gaps.

    The first gap that almost always seems to come up when bringing teams together and driving business value is the duties gap. For too long we have sat on opposite sides of the coin. In operations in particular, too often we see ourselves as the ones that have to deal with the aftermath of unfortunate problems within code. But the fact is, we should all care about our systems, we should all care about our code and we should all be ensuring the longevity of both.

    Once you’ve moved past the first hurdle, then comes the gap in knowledge.  Scripting has become pretty common as companies press for automation, but in some instances, it becomes necessary to build up existing team members. Using enterprise automation tools such as Chef, entire teams and entire companies can begin caring about a shared thing: the configuration, health and state of their infrastructure and applications. In doing so, those same teams can begin speaking a shared language. Once this knowledge and shared language are in place, developers no longer view the ops team as an “other,” but rather as collaborators. They can each use their various areas of expertise and speak the same language without having actually having to speak the same language.

    The third common gap is the process gap. Process can represent all of those past processes that a company is reluctant to let go of, which can hinder the ability of the developers and operations humans when they’re attempting to collaborate. The process gap can become particularly difficult to move past without leadership buy-in; as such, it is critical to involve business decision-makers in this transformation. While nearly the entire industry is beginning to move toward more collaborative environments, the entire leadership team must be onboard with the requirements to make changes happen. With the use of automation tools in particular, though, processes can begin to shift more toward collaboration-friendly policies and you can then make the case for further expansion with proof that it can aid in your transformation.

    Empathy is the final gap that must be overcome. The great part about the other gaps is that they work hand in hand to solve each other’s problems. By promoting collaboration, resolving these gaps are also facilitating collaboration. The empathy gap is largely caused by silos of the past that have led to the commonly talked-about “wall of confusion.” Closing the knowledge and duties gap, developers and operations humans can now communicate and understand the same language and processes each is following. This allows the wall to be broken down and operations humans and developers alike can care about both code and stability.

    It’s easy to start getting dev and ops teams working together and on a more even playing field once these gaps have been eradicated. This becomes a big driver for innovation and is, in many cases, a true recipe for success within the company. During my career, I’ve both watched and been involved in these transformations. Working with solutions such as Chef has allowed me to cross the bridge myself, and likewise, be able to share with others how that can be scaled out to entire organizations.

    — Brittany Woods

  • The Role of Bots in DevOps

    The Role of Bots in DevOps

    DevOps has evolved from its infancy into a mainstream focus area for a majority of CIOs. DevOps has become a main focus and has been shaping the world of software and infrastructure engineering and operations for the last few years.

    Some of the key DevOps trends include:

    • DevOps assembly lines automation.
    • Smart, actionable alerts from monitoring tools.
    • Monitor and orchestration infrastructure.

    Improved Collaboration

    With the increase of DevOps adoption, organizations today face many challenges in the end-to-end service delivery life cycle.

    • For applications with complex environment configurations, creating, setting up and deploying a new environment is costly, time-consuming and prone to errors.
    • Due to manual interventions, moving/promoting code across environments involves risks and may give rise to outages.
    • Development teams are looking to maximize change by writing new code or enhancing existing code, while operations teams are looking to minimize change to keep up with key performance indicators (KPIs) and service level agreements (SLAs). These goals are opposing in nature and create a culture of blame between dev and ops teams.
    • Organizations are unable to keep dev, test and production in synchronization due to process and tool gaps. A manual process cannot bridge this gap in consistency; thus, outages in production are common.

    Various collaboration mechanisms let teams work and learn together to produce better results. The figure below depicts the end-to-end life cycle of DevOps. Collaboration across the phases is essential to the success of your enterprise DevOps transformation.

    DevOps Lifecycle

    What are ChatOps and Bots?

    ChatOps is a term coined by GitHub to describe “putting tools in the middle of a conversation.” In a typical CI/CD pipeline, there are multiple tools that you interact with that have varied functionalities, such as source code management (SCM), defect management, continuous integration, continuous deployment and others. These are all discrete tools, but there is nothing that bridges them together. This is where ChatOps comes into play.

    A bot is a bridge between the collaboration tool and the DevOps tools. The bot receives a request from the user in the form of a chat command through a collaboration tool, analyzes the request and executes a set of commands on the target DevOps tool.

    The main components of ChatOps and bots are:

    Chat app/collaboration tool: This is the front-end chat system that connects the various stakeholders and enables them to interact between themselves and the systems around them.

    The bot: This is the core of ChatOps. A bot is the glue between your collaboration tool and your systems. It facilitates a two-way communication channel where you can fetch relevant information from the systems and act on the information received. A bot fits in between your collaboration tool and the DevOps tools, e.g. Hubot, Lita, ErrBot or AWS Lex.

    Target platform/infrastructure: Integration with the target platforms/DevOps tools is a key ingredient to a successful implementation of bots. These are the target tools and platforms on which the bot will execute the required commands. The tools integration allows your bot to communicate with tools and execute actions such as build, deploy, test, provision and scale infrastructure directly from the chat window.

    Where Bots Fit in the DevOps Pipeline

    Bots can prove to be an accelerator in various stages of the CI/CD pipeline. Below are the details of the integration with various DevOps tools in each phase of the life cycle:

    • Proactive planning – JIRA
    • Requirements management – JIRA
    • Continuous integration – Jenkins
    • Continuous deployment – Ansible, Chef
    • Continuous monitoring – Nagios, Grafana, Splunk
    • Continuous feedback – JIRA

    A chatbot plays a major role in bringing the different teams together into a single, persistent chat room to triage and resolve the issue at hand. In addition to just troubleshooting and triaging issues, bots can be used for various other business-as-usual jobs including:

    • Cleaning up servers.
    • Kicking off build and deployment jobs.
    • Rotating server logs.
    • On-boarding application on the monitoring tools.
    • Collecting metrics from tools such as Nagios or AppDynamics.

    Bot Technical Blueprint

    To achieve the aforesaid targets, we need to have a supportive bot platform in place. How closely the tools integrate with the bot ensures the quality of the implementation and opens new opportunities of automation.
    Bot Blueprint
    As the diagram depicts, the chatbot is hosted on a chat tool such as Slack. This can be on the cloud platform or an existing chat/communicator application. The bot is integrated with a key-value pair reference database, which is fed with the responses depending upon the activities or capabilities that have been fed to it. The key could be the name of the application to retrieve data from or any unique ID that would reduce the number of reads. A lookup of the defined key corresponding to the secondary key is performed on the response database and a response is sent back to the chatbot. Depending upon the number of outputs, the queries can be defined and stored in the response database.

    DevOps Bots: Use Cases

    Below are some examples of use cases for bots. This includes the complete life cycle of DevOps:

    Proactive Planning
    Create new user stories in sprint planning tools and assign sprints to teams. Update sprints and product backlogs.

    Build and Continuous Integration
    Execute build jobs and report back statistics of the build job. Perform daily/nightly builds and report on the status of the build to the relevant teams.

    Continuous Deployment
    Run deployment jobs and perform deployments across environments. Roll back deployments in case of failures, status checks, perform post-deployment actions such as JVM restarts.

    Infrastructure Provisioning and Configuration Management
    Kick off Chef jobs to provision infrastructure or provision application environments. Enable monitoring and restarting services and servers.

    Continuous Monitoring
    Provide application statistics or performing daily data lookups and grabbing metrics.

    Continuous Feedback
    Monitor application health and perform analytics.

    Key Measurement Metrics

    To achieve optimization and enhance performance of the continuous delivery process, metric measurement is the key. These indicators will help in taking certain corrective and preventive actions based on the results. Below are some of the key metrics indicators that can be measured.

    Effort Reduction
    Indicates the reduction of human/manual efforts for tasks such as triggering a build or deployment or collecting metrics from monitoring tools.

    Human Error Reduction Rate
    Reduction in the effort required due to rework caused by human errors.

    Reduce Issue Triaging time
    Indicates the time taken to resolve issues where multiple parties are involved and triaging of problems is required.

    Conclusion

    DevOps bots can significantly improve team efficiency, as well as a team’s ability to respond to emergencies. They save time and money, are fun to build and use and can have a positive impact on team morale, as well as increases the overall productivity of teams. This applies to both the engineering and operations teams. Enterprises embracing digitization are looking for partners with an engineering mindset who know how to bring in collaborative agile teams with the very latest knowledge of open source platforms and DevOps toolchains.

     

    Contact the Authors

    For more details please contact the authors on LinkedIn @
    Shriniwas Sathe
    Saswati Mohanty

    — Shriniwas Sathe

  • Nutanix Eases Development of IoT Apps

    Nutanix Eases Development of IoT Apps

    Nutanix, a vendor of hyperconverged infrastructure solutions, has released a new developer environment that allows developers to try and test IoT and AI apps in the cloud. Starting May 7, developers can sign up for a free 10-day trial of this experience.

    The developer environment is built under Nutanix’s Xi IoT Platform and gives developers access to a rapid development environment for creating internet of things and artificial intelligence apps in the cloud. The Rapid Development Environment for IoT includes features such as Xi IoT Cloud Instance, Xi IoT Sensor App and Xi IoT App Library and supports the ability to easily deploy IoT software in the cloud or at the edge, according to the company. The environment has been tuned specifically for IoT and AI, eliminating many of the configuration chores developers had to perform using other cloud-based development environments, and enables single-click deployment via a management console.

    For developers targeting production-edge environments, the new environment brings forth the ability to develop for the edge or for the cloud, bringing application portability into the development and testing process. By being able to use a common set of APIs, cloud and edge development becomes relatively seamless and deployment friction is vastly reduced, according to the company.

    Beyond ensuring compatibility across platform services and APIs, the environment enables development and production environments to use the same components, so recoding is not needed as part of the transition from dev to ops. That helps to simplify lifecycle management as well as fit agile practices better into the dev process.

    Nutanix also offers an extensive library of applications that can be used to ease development chores. The Xi IoT App Library offers  individual components (message bus services, time series databases, etc.) and full solutions that developers can use to address various business problems.

    Nutanix is framing the new delivery mechanism as a new experience to get more developers—from novice to advanced—creating AI and IoT scenarios.

    — Frank Ohlhorst

  • With RHEL 8, Red Hat Adds More Automation to IT Ops

    With RHEL 8, Red Hat Adds More Automation to IT Ops

    At the Red Hat Summit 2019 conference, Red Hat today announced the general availability of Red Hat Enterprise Linux (RHEL) 8, which includes among other things a Smart Management add-on designed to make it easier to manage RHEL 8 across hybrid cloud computing environments.

    In addition, RHEL 8 includes Application Streams, a set of utilities for updating languages, frameworks and developer tools without impacting the core resources, as well as updating RHEL 7 to RHEL 8 in place.

    RHEL 8 also adds Red Hat Enterprise Linux System Roles, which provides modules to automate complex tasks using the Ansible automation framework along with support for the Red Hat container toolkit and the general availability of the Red Hat Universal Base Image, a userspace image derived from RHEL that makes it easier to build Linux containers certified to run on RHEL.

    Red Hat also revealed that Red Hat Insights, a set of predictive analytics tools, will be included with the RHEL 8 subscription and that RHEL 8 supports both the OpenSSL 1.1.1 and TLS 1.3 cryptographic standards.

    Gunnar Hellekson, director for product management for Red Hat, said Red Hat is focusing on automating as many tasks as possible as part of an effort to make the life of IT operations teams simpler. As part of that effort, Hellekson said Red Hat is moving to lower the barrier to becoming a RHEL administrator by abstracting away many of the complexities historically associated with trying to manage Linux environments using a command line interface (CLI). Much of that focus will manifest themselves via ongoing enhancements to the Compose and Cockpit tools Red Hat provides for deploying and managing instances of RHEL, said Hellekson.

    Red Hat is making it clear it wants to make RHEL much more accessible to a larger number of IT administrators, especially those that historically have favored a more graphical approach to managing operating system environments. At the same time, however, Red Hat is infusing more automation into RHEL 8 as part of an effort to make it easier to manage deployments at scale. That latter capability is crucial for DevOps teams that, for example, need to be able to update a development environment without waiting for an IT operations team to reconfigure and reboot an operating system. Via add-ons to the core RHEL platform, Red Hat is now starting to expand those automation capabilities across both on-premises and public cloud computing environments.

    It’s unclear going forward how many instances of RHEL any one IT administrator might be able to manage on their own. Trying to determine that number might not even be worth the effort because advances in automation are now coming so rapidly that trying to determine that right number of IT administrators per environment is not possible to determine consistently. Instead, IT organizations should just assume that, thanks to automation enabled by machine learning algorithms and predictive analytics, the operating system environment is now flexible enough to scale up and down as needed.

    — Mike Vizard

  • IT Operations: PagerDuty Unveils Hybrid ITSM Platform

    IT Operations: PagerDuty Unveils Hybrid ITSM Platform

    PagerDuty today unveiled a framework intended to make it possible for organizations to bridge multiple styles of IT service management (ITSM) methodologies for IT operations.

    Rachel Obstler, vice president of product for PagerDuty, said PagerDuty Solution for HybridOps provides a comprehensive incident management framework capable of spanning both ITIL and DevOps processes for IT operations.

    PagerDuty Solution for HybridOps combines existing and new product capabilities such as Event Intelligence and Modern Incident Response with machine learning algorithms and bi-directional integrations the company has developed between its incident management software and more than 300 third-party products.

    Those capabilities make it possible to facilitate real-time communications between platforms that tend to be favored by IT shops relying mainly on ITIL processes, such as ServiceNow, and DevOps teams that rely on Slack to communicate with one another, Obstler said.

    IT Operations: PagerDuty Unveils Hybrid ITSM Platform

    Rather than forcing an entire IT organization to transition to single framework for IT operations, PagerDuty Solution for HybridOps allows organizations to selectively apply each model where and when they best see fit, she said.

    The latest version of the ITIL framework goes a long way toward injecting some flexibility into what historically has been viewed as a rigid approach to managing IT. The ITIL framework is still a long way from being as agile as the various forms of DevOps that many organizations have adopted over the last several years to accelerate application development and deployment.

    Obstler said PagerDuty is moving to bridge that divide by leveraging machine learning algorithms to group all the various alerts generated by all the tools in an IT environment. That capability not only reduces the amount of alert fatigue any IT operations group is likely to suffer, but it also makes it easier to identify the root cause of any IT incident, she noted.

    One of the primary reasons DevOps has been adopted evenly in the enterprise is that IT operations teams are expected to be able to programmatically adapt IT infrastructure to meet the demands of developers. The number of IT operations that have those skills, however, is limited. In theory, IT operations teams without programming skills could rely on automated frameworks to achieve that goal. But that approach requires IT organizations to standardize on a single IT automation framework across compute, storage and networking services. The number of organizations that have been able to bridge all the islands of automation that have been adopted across all the services they deliver are few and far between. Put it altogether and it’s clear that both legacy and modern approaches to ITSM will need to coexist well through the next decade.

    In the meantime, IT leaders might want to consider that old proverb about leading a horse to water. IT leaders can issue all the mandates they want. But when it comes time to accomplish a task, most IT professionals are naturally going to fall back on what they know. The challenge is to create ways to wean the IT operations staff off those legacy processes in a way that doesn’t necessarily result in everything grinding to a halt because nobody knows how to fix an issue that simply wouldn’t otherwise wait.

    — Mike Vizard