Category: DevOps Toolbox

  • In Service Management, AI Is Still Aspirational

    In Service Management, AI Is Still Aspirational

    Artificial intelligence (AI) has become a matured concept, the excitement of which is bearing results for a number of sectors and it holds a good deal of promise for a bright future. AI is the act of making possible for machines to learn from “experience” while adjusting to new input and stimuli so they can perform human-like tasks, ultimately leading for more complete automation in many traditionally man-powered processes. Computers can be “trained” to accomplish specific tasks, process data and recognize patterns in the data.

    While the use of service management solutions escalates, so do the potential uses for AI approaches in the sector. Because of this, there are advantages to discuss as well as examples of how AI can help to improve the service management operations of your organizations. But AI is a broad and far-reaching concept that’s often misunderstood and difficult for those that don’t work with the technology to understand its full capabilities.

    Is AI All Hype or Is It Actually Helpful?

    Based on the 2018 Interop ITX AI: Hype or Substance report, in a survey of 182 technology professionals, almost two-thirds of these respondents’ organizations are currently working on AI products or evaluating the technology. However, only 12 percent are using AI in production today. For those who responded during 2018, 6 percent of those using the technology said their budgets for it were set to decrease. The outcome, per the report, is that AI interest is high, but the ability to execute is low.

    Are AI Expectations Too High?

    The return on investment of AI is not clear and nearly one-third of organizations say they lack the budget they need to move forward, Information Week reports. Additionally, despite the desire for AI initiatives to reduce manual processes, these tasks must still be carried out by talent in the organization. A lack of expertise is often cited as a barrier to AI initiatives because there is not enough expertise to push the efforts forward. Alternatively, of those surveyed, more than a quarter said they haven’t defined a business case yet and close to half said they “have no idea” what effect AI may have on their businesses.

    Part of the problem with AI is the broad nature of its concept. Much of what we thought we knew AI was is now standard practice. For example, early AI efforts like IBM’s chess computer, Deep Blue, is part of our computing world now. Currently, demand or desire for AI capabilities is still aspirational, but usually is conflated with “machine learning”—where a computer or programming provides examples for how a machine can “learn” how to complete said task. Machine learning has huge potential to help societies automate previously manual systems. Through this, new economies will be developed and work (and workers) will evolve. Certain jobs, eventually, will become minimized and even discontinued in favor of new process and “ways of doing things.”

    We have seen these cycles before. In the United States, from a macro level, there’s been a major shift from a farming/agricultural society to one of more urban-based manufacturing/industry; into the post-industrial; then global-focused; and web-connected economies. These can be drilled down further but the point is made—major variations in our economies and jobs have taken place in a relatively short period of time. Based on these changes, we’ve had to change; jobs and workers have had to change. Machine learning is another disruptor for the new global economy that will force change.

    Hyped Up

    The hype of machine learning—a technology with huge potential—may not actually be overhyped. That said, how will this technology actually impact our everyday lives, and will machine learning change the work we do in service management? Perhaps we’re now starting to get a better idea of what those realities may look like.

    As far back as 2017, Gartner said that machine learning hype peaked, but expectations remain high. For service managers, there’s going to be more than intelligent chatbots to worry about but for now, much of the anticipation likely will continue. Machine learning can be a beneficial tool for identifying trends and changes in trends. In service management, machine learning means quick responses can help recognize when there is an above average number of calls logged, for example, or an unusual number of calls within one category, which can be acted upon.

    For most pressing trends—a specific cloud service that may no longer be available, for example—meaning machine learning-driven technology can recognize this breakdown by sending a signal to a specialized member of the service team, who can then react to this issue. Long-term problems also can be addressed through machine learning technology, spotting urgent disruptions. This may be particularly important during problem management. A labor-intensive process, machine learning has the capability of being able to recognize patterns in these calls, making the discovery of structural problems much easier.

    Misconceptions About Machine Learning

    Misconception surrounding AI and machine learning is rampant from replacing most of our jobs and replacing massive amounts of humans in the workforce to their surpassing our pre-programmed uses for the technology, in which the machines rise up and enslave us all. The more realistic version of things is a bit more benign. The most common current misconception is that chatbots and virtual assistants will make service desk employees redundant in short order. But this won’t likely be the case for the better part of a half decade or more because the technology isn’t sophisticated enough. Most chatbots are pretty expensive and don’t always work well.

    For now, machine learning will likely only help “answer” direct questions more quickly. More complex issues must still be handled by people. The realized benefit here is that because machine learning technology can help solve the easiest questions service desks face, there’s more time for service desk team members to solve the more complex calls.

    Someday Soon …

    Soon, machine learning technology will become better at finding the right information and offering solutions that actually benefit humans. Then, service desk employees will be able to focus more on the overall customer experience in ways that machine learning likely never could.

    While AI is maturing, excitement surrounding this experiment may need to be tempered for a bit. The technology is in the act of making possible for machines to learn from “experience” while adjusting to new input and stimuli so they can perform human-like tasks, but more complete automation in many traditionally man-powered processes is still needed.

    — Nancy Van Elsacker Louisnord

  • ‘DevOoops’ Moves: SCM Conflicts

    ‘DevOoops’ Moves: SCM Conflicts

    DevOps’ ultimate aim is to create efficiencies in the software delivery process. But it doesn’t always work out that way. Sometimes DevOps initiatives lead to mistakes—something we lovingly call a “DevOoops.” CloudBees recently polled some colleagues and came up with five examples of a DevOoops in action. Following is a discussion submitted by solution architect Will Refvem about siloed departments.

    Scenario:

    One of the biggest challenges in DevOps is SCM. Early in my career, being given access to Git repositories was a bit like handing a belt-fed machine gun to a drunken toddler. My biggest DevOoops moment came when I was trying to master the basics of Git in a project that used Git submodules—don’t, just don’t—and had a series of bash scripts that implemented a primitive CI/CD workflow by running in the environments we were deploying to (seriously). I can’t tell you how many merge conflicts and detached HEADs I encountered, or how I got out of them. Fortunately, we were using the fork-PR model, so I did no real damage.

    Software configuration management (SCM) is key not only for versioning, but also for providing a shared view of code and other assets, from development through to production. Giving proper consideration to your SCM structure, branching and merging model, access controls, etc., will support collaboration, reliability and traceability—all key for DevOps success.

    In the 2019 DevOps and Jenkins Community Report, 66 percent of organizations respondents reported the use of modern solutions SCMs, specifically GIT-based solutions GitHub or BitBucket. But the older SCM solutions aren’t going away completely—45 percent of all organizations still use pre-GIT, pre-DVCS (distributed version control systems) such as Perforce, Subversion and CVS. While it’s possible to apply DevOps practices using these legacy solutions, it is important (and more challenging) to design a branching/merging model and surrounding workflow, which supports the key aspects of DevOps such as peer review, collaboration and short-lived branches.

    Modern SCMs such as GitHub have features that inherently support collaboration, including the game-changing Pull Request, making it much easier to implement processes that best support CD and DevOps.

    Poorly designed CD workflows or inadequate CD systems create friction multiple ways. If the interactions are too cumbersome, users will not commit code to the pipeline frequently enough. If it’s difficult to access the pipeline and create visibility into the process, it can lead to unresolved conflicts.

    You need to pick the right tool. If you don’t have the option to get the modern tool, you need to take the time to design a legacy tool.

    It’s also important to consider two other issues in relation to this DevOoops example: branching and acquiring the appropriate level of DevOps skills.

    • Branching: A proper branching and merging model is required to ensure you are feeding the appropriate inputs into your DevOps pipeline, such that you are able to continuously integrate, test and ultimately deploy changes. A simple guide here is encapsulated in the KISS (keep it simple, stupid) principle. If you need a full-wall whiteboard or a spreadsheet fit for an accountant to list your active branches, you need to rethink things. Get as close to the ideal of mainline trunk development as possible, with short-lived feature branches, minimal application versions, etc.
    • Skills: As organizations seek to implement DevOps, most likely new tools and practices will be implemented simultaneously. It’s important to understand and accommodate the fact that there will be bumps and bruises as you learn to use these new tools and practices. For instance, shifting from centralized version control such as Apache Subversion (SVN) to distributed version control such as Git is a paradigm shift that can be difficult to fully grasp and result in destructive mistakes, such as deletion of nodes from the change history, overwriting changes or misconfiguration access control. Consider hiring for these new skills and/or account for time and training.

    Takeaways

    • A proper branching and merging model are required to ensure that you are feeding the appropriate inputs into your DevOps pipeline to let you continuously integrate, test and ultimately deploy changes.
    • If you are using a pre-Git legacy SCM solution, develop a branching and merging strategy within the legacy solution to achieve appropriate velocity in your DevOps model.
    • Consider that you will need to develop new skills to adopt new SCM tools and practice and account for this in your plan.

    — Brian Dawson

  • Akamai Extends Scope of DevOps Reach

    Akamai Extends Scope of DevOps Reach

    Akamai today moved to further extend the number of capabilities it exposes via its content delivery network (CDN) that are designed to appeal to DevOps teams.

    Those enhancements include HTTP/2 performance optimizations and the ability to automatically load font libraries, as well as providing access to “middle-mile” logs that will enable DevOps teams to more precisely investigate performance issues and test logic in a local development environment before moving those changes into production.

    Akamai has also re-engineered Control Center to provide more detailed reporting across security, acceleration and delivery functions, and made TLS 1.3 the standard mechanism for establishing connections.

    Finally, Akamai is also looking to advance DevSecOps processes. Its CDN now can optimize or block access to content within a fully integrated virtual private network and domain name system proxy detection service. Akamai’s Token Authentication capabilities have been extended to include coverage for browsers and devices that do not support cookies.

    Ari Weil, vice president of product marketing for Akamai, said these latest extensions are part of an ongoing effort to make the company’s CDN a natural extension of any DevOps process. Developers today often wind up wasting a lot of time and effort writing code to load fonts that now can be automated using via the Akamai CDN, for example. The enhancements should free them to write code that adds more value to the business, he said.

    Akamai is also promising DevOps teams they will see much faster activation times across Akamai CDN, as well as have deeper visibility into application performance issues beyond what most application performance management (APM) tools offer, added Weil. Akamai is especially focused on any application development project where service level agreements need to be both achieved and maintained, he said.

    Thus far, Weil said Akamai is finding a higher level of appreciation for the role CDNs can play in DevOps. CTOs and enterprise architects who are typically held responsible for achieving application delivery goals in particular are now taking notice of CDNs’ capabilities, as most individual developers aren’t usually focused enough on finding ways to automate the routine aspects of building a modern web application, he said.

    Akamai will continue to focus on making its CDN a natural extension of the continuous integration/continuous deployment (CI/CD) platforms on which DevOps processes are implemented, with an eye toward making its CDN a preferred deployment platform for web and mobile applications. It may take while longer before DevOps teams view CDNs as a deployment platform for their applications. Much of the decision regarding what CDN to employ historically has been been left to application owners. But Akamai is clearly betting that if more applications take advantage of CDN functionality as they are being built, there’s a much greater likelihood those applications will be distributed on the Akamai technology.

    — Mike Vizard

  • Atlassian Adds Pre-Configured Pipelines to Bitbucket CI/CD

    Atlassian Adds Pre-Configured Pipelines to Bitbucket CI/CD

    One of the primary reasons DevOps processes have not been widely adopted across the enterprise is that building pipelines across all the tools required is a painstaking effort. As a result, most pipelines today are constructed using manual pipelines. However, Atlassian has announced it is now making available pre-configured Bitbucket Pipelines that DevOps teams can access via a simple drag-and-drop interface.

    Harpreet Singh, head of product for Bitbucket Cloud at Atlassian, said DevOps teams that rely on the Atlassian Bitbucket continuous integration/continuous deployment (CI/CD) platform will be able to employ a series of pre-configured Bitbucket Pipelines built by Atlassian or one of its third-party partners, rather than having to manually build every pipeline.

    The goal is to make it much easier for DevOps teams to incorporate, for example, a new cloud platform into an existing set of DevOps processes without waiting for someone on the DevOps team to write, test and validate a script, said Singh. IT vendors that have worked with Atlassian to create Bitbucket Pipelines include Google Cloud, Microsoft, Slack and Amazon Web Services (AWS).

    One of the ironies of DevOps is that while CI/CD platforms make it easier to build and deploy applications, constructing the CI/CD platform can be exceedingly complex. A recent survey conducted by Atlassian found DevOps teams rely on 4.3 tools to move code from development into production environments. A full 62 percent of respondents reported they resort to performing manual testing due to insufficient automated test coverage, additional manual processes or a lack of build/deployment pipeline automation.

    While some organizations might have the engineering resources required to build pipelines, he noted, the average IT organization can’t afford to hire operations specialists that have the requisite programming skills required to build pipelines manually.

    Best of all, noted Singh, the pre-configured Bitbucket Pipelines that Atlassian makes available will be maintained and updated by their original authors.

    It’s too early to say to what impact pre-configured pipelines is likely to have on DevOps adoption in the enterprise. But most enterprise IT organizations won’t significantly alter their process until it becomes relatively easy to make that transition. Enterprise IT organizations have relied on administrators to manage IT for decades, and most of those administrators wouldn’t know where to begin if asked to manually construct a pipeline. The few enterprise developers who might be able to build those pipelines are simply to busy writing application code. The result is a paralysis that prevents organizations from modernizing their application development and deployment processes.

    Of course, any meaningful change in the enterprise also involves a chicken-and-egg debate. Lacking skills and tools, enterprise IT organizations are unable to overcome internal inertia, which in turn results in conservative IT organizations preferring to rely on known processes no matter how inefficient they might be. The real challenge facing IT leaders trying to advance DevOps adoption is to remove as many excuses for resisting change whenever and wherever possible, starting with how pipelines are constructed and maintained.

    — Mike Vizard

  • VMware Brings NSX Network Virtualization into DevOps Realm

    VMware Brings NSX Network Virtualization into DevOps Realm

    At the Mobile World Congress (MWC) 2019 conference, VMware moved to bring network virtualization into the realm of DevOps by adding support for a declarative programming model and JSON data formats to version 2.4 of NSX-T.

    In addition, VMware is making it possible to use the open source Ansible automation framework to deploy NSX-T.

    Finally, VMware is adding support for IPv6 as well as the ability to now extend microsegmentation all the way to Layer 7 of the application stack.

    Jonathan Morin, product marketing manager for NSX at VMware, said this release of NSX-T not only will become the dominant version of NSX for VMware in the enterprise, it also represents a concerted effort to make network virtualization directly accessible to both developers and IT operations teams alike. JSON support is critical from that perspective because it makes it easier to programmatically replicate the networking requirements and security controls attached to any class of applications.

    Longer-term, JSON support will also make it easier for a wide variety of management tools to consume metrics generated by NSX-T.

    IT organizations must determine to what degree they want to fold network operations into DevOps. Some organizations will simply prefer to provide developers with access to self-service virtual networks, while others will move to expose the declarative application programming interfaces (APIs) in NSX-T 2.4 directly to developers, said Morin.

    VMware expects that, going forward, a hybrid method for deploying and managing NSX will emerge. Developers will want to programmatically invoke network resources as they build and deploy applications. But network administrators will need to be able to access tools to manage those virtual networks over time. To facilitate that process, the latest version of NSX-T has been updated to add support for an HTML5-based user interface. The goal is to not just distribute NSX-T, but also make it accessible to everyone, said Morin.

    Rather than requiring organizations to upgrade switches and routers to enable programmability, VMware has been making a case for employing network virtualization to create a programmable overlay. That approach serves to make the underlying physical network agile enough to be employed with a DevOps framework without requiring organizations to upgrade the entire physical network.

    In many ways, networking represents the last major frontier to which DevOps processes need to expand. It’s possible for developers to spin up a virtual machine in the cloud or in an on-premises environment in seconds. But it can still take weeks to manually provision the networking resources in an on-premises environment that a virtual machine requires. VMware has been advocating for the deployment of instances of NSX in both on-premises IT environments and in public clouds to provide a consistent network overlay that can be programmatically invoked and automated.

    It remains to be seen to what degree network operations will be pulled into DevOps processes going forward. But the one thing that is clear is that IT organizations have the option to decide to what level they might want to achieve that goal.

    — Mike Vizard

  • What AI Could Mean for Developers

    What AI Could Mean for Developers

    Artificial intelligence has been dominating the tech news headlines for a few years now, as the innovations in the sector keep rolling out at increased rates. The technology is, for lack of a better term, awesome, and when used correctly, it can have tremendous effects. We have already begun to see artificial intelligence in the consumer sphere take off at lightning speed.

    Artificial Intelligence is in More Things Than You Think

    Smart assistants, such as Google Home, Amazon Alexa and Apple’s Siri, have all dominated their share of the market with intuitive daily assistants that can keep track of your schedule and tell you the weather. They can even tell jokes—which may or may not leave you in a state of disrepair.

    Looking to the future, we also have autonomous vehicles, which will change our lives undoubtedly by potentially limiting traffic collisions and deaths. That is the true endeavor of technology: to change our lives in such a way that they are never quite the same.

    Artificial Intelligence Development is Open to All

    Development of AI programs is being accelerated due to the availability of AI libraries. With these powerful libraries, development teams are able to build custom code on a complex pre-built infrastructure. Google, IBM and Microsoft all have their own AI APIs that programmers can use to create better products.

    Using paid APIs, developers can use advanced programs developed by tech giants in their own applications. Google Cloud AI provides a suite of machine learning services. You can venture into other APIs also powered by AI. For example, you can use Google’s Cloud Speech API, which uses AI to dynamically convert audio to text in an existing application.

    TensorFlow is freely available to help programmers, developers and engineers use machine learning algorithms to better manage and classify data. All of these APIs empower development teams to dig deeper into deep learning.

    What Advancements Mean for Developers

    The goal of the openness of AI development is to create a new normal brought to life by the endless innovations of the tech industry.

    Without hesitation, we can call AI the next great invention. It has an ability to completely reshape the face of our world in such a way, that this current life will become one of distant fondness and inelegant trite labor. Indeed, the developers of AI will be contributing to the total revolution of life as we know it and the consequences thereafter.

    This is why it is so important to get it right. Using a guideline to build the future will ensure that it can handle the weight of use, without failing itself into obscurity.

    Innovation Means Opportunity

    Ultimately, AI is at its best when it fixes a common problem and is developed with best practices. Because the technology is so new, developers must work around the clock to create applications and get them to market so that their impacts, if any, can be registered and used for analytics. Developing AI is much bigger than a simple web application or smartphone app.

    The pure potential of the tech alone is enough to incite the most lethargic to action, but development will be in vain if not for best practices. Once developers around the world start to follow a development guide, it will increase the fluidity of innovation and knock down any barriers in its way.

    This ensures that developers can share ideas and technology easily, without being in the dark when it comes to the shared development process. Artificial intelligence is an ongoing innovation that may never cease to improve on itself.

    Conclusion

    In this article, we examined the best development practices in AI so that you and your team can create AI applications with the future in mind.

    In fact, the pursuit of humanoid AI, upon its completion, will most likely give us its own revolution in the tech industry as it slowly becomes pervasive in all industries. There is a beauty in contributing to grand goals. You and your team should not be limited or sidelined by a lack of knowledge about best practices when developing AI applications.

    There’s a wealth of resources for developing AI programs through the use of existing AI libraries. There’s plenty of help from the AI community, who are all pursuing a greater utopia with AI—and your team should not be left in the dust.

    — Anthony Coggine

  • Enhance DevOps Experience with AWS Smart Tools

    Enhance DevOps Experience with AWS Smart Tools

    DevOps has become the champion of business operations by fostering collaboration between disparate teams, providing a common work framework and paving way for continuous delivery that greatly boosted software development.

    Amazon Web Services (AWS) has become a leading provider of DevOps tools and services and has been instrumental in taking this experience to a higher level.

    So how does AWS elevate the DevOps experience?

    Automation

    DevOps not only eliminates the cultural disparities between two different environments but also eases the software development process by automating its tasks. This has made maintaining and looking after large-scale complex environments easier.

    Earlier, implementing automation in cloud environments was a painstaking process and was similar to implementation/usage in physical or virtual infrastructures. Today, however, leading cloud services providers offer DevOps automation tools as a part of their feature package, making automation a breeze.

    Continuous Integration and Delivery

    AWS CI/CD tools make building, testing and deploying application source—or just securely storing it—simple and organized.

    Continuous Integration and Delivery with AWS DevOps

    • AWS CodePipeline: This is a continuous integration/delivery tool that builds, tests and deploys code in the event of a code change. AWS CodePipeline helps developers introduce code quickly and reliably into the software life cycle.
    • AWS CodeBuild: AWS CodeBuild is a fully managed build service that compiles source code, runs tests and produces deployable software packages that are ready for use. CodeBuild is expandable and processes multiple builds simultaneously, propelling the purpose of continuous integration and delivery.
    • AWS CodeDeploy: AWS CodeDeploy automates code deployments to instances or on-premises servers. This tool helps users to release new features rapidly, avoid downtime during application deployment and manages updates easily.

      Special Features:

      • Automatic deployment
      • Integration with third-party tools
      • Centralized management
      • Integration with other AWS services
    • AWS CodeStar: AWS CodeStar helps users to rapidly develop, build and deploy applications while providing them with a common interface for managing software development activities. It allows users to set up their continuous delivery tool-chain in minutes for faster code release.

    Microservices

    Microservices allows users to build and deploy microservices architecture with the help of containers or serverless computing.

    • Amazon Elastic Container Service: Amazon EC2 services enables users to manage large groups of containerized applications with the help of Docker containers.
    • AWS Lambda: AWS Lambda relieves users from the burden of constantly administering and managing the system while running code for virtually any type of application or back-end service. This Amazon service just requires developers to upload code after, which the system takes care of running and scaling code with high availability.

    Platform as a Service

    • AWS Elastic Beanstalk: AWS Elastic Beanstalk is used to deploy and scale web applications and services developed with Docker, Java and Python on servers such as Nginx. All users have to do is upload the code and the service will handle deployment, including capacity provisioning, load balancing, auto-scaling and app health monitoring.Special Features:
      • Quick Deployment
      • Integration with other AWS Services
      • Application Health Monitoring
      • Easy Access to Application and System Logs
      • Customized Software and Applications

    Infrastructure as Code

    • Chef: This is an infrastructure automation framework that enables easy configuration, deploying and management of servers and applications on a cloud, physical or virtual environment. It sets up the infrastructure by using recipes.
    • Puppet: It can be tedious to tend to each server individually should you need to make configuration and content changes to multiple servers. In such a scenario, Puppet helps to set up each server as an agent that relays information to the AWS Puppet Master Machine about any changes to be executed on that server, paving way for uniformity across all servers.
    • Ansible: Ansible is another configuration management, software provisioning and application deployment tool. Designed for multi-tier deployments, Ansible enables continuous delivery. It designs your IT infrastructure by describing how all your systems can work as a network.

    Amazon Web Services has a number of DevOps tools, all designed to help professionals work more efficiently in the AWS cloud environment. Are you using the AWS tools? If so, what are your thoughts about them? Let us know your thoughts in the comments section below.

    — Veritis

  • Kemp Adds Predictive Analytics to ADC to Advance DevOps

    Kemp Adds Predictive Analytics to ADC to Advance DevOps

    Kemp this week enhanced the automation and predictive analytics capabilities it makes available within its application developer controller (ADC) as part of an effort to ease deployment of applications across multi-cloud computing environments.

    Company CEO Ray Downes said the goal is to make it easier for DevOps teams to avoid overprovisioning IT infrastructure, at a time when applications are more distributed than ever.

    The Kemp ADC offerings are comprised of a mix of physical and virtual appliances that have now been deployed more than 60,000 times. The volume of data generated by those deployments now makes it possible for Kemp to apply predictive analytics via a 360 Central monitoring tool that, for example, can now make suggestions concerning where to deploy a workload based on current utilization rates, Downes said.

    Kemp also now can provide comparative analytics, he noted. For example, the company revealed that its analytics show 61 percent of application experience issues are related to events caused by capacity issues such as failing or degrading application servers. Kemp also revealed that 48 percent of organizations see as many as nine application incidents per week.

    Now that Kemp has begun to apply predictive analytics to its ADC platforms, Downes said the next logical step will be to apply machine learning algorithms to help further automate application deployments.

    While ADCs provide critical load balancing capabilities, they are often overlooked as a source of actionable intelligence for DevOps teams. That data is more critical than ever because as IT organizations modernize their application portfolios by embracing more complex microservices, many of them are discovering every application will soon require its own load balancing capability. Previously, the primary role of an ADC had been to enable as many applications as possible to share the same IT infrastructure efficiently. Now the goal is becoming to orchestrate and optimize the allocation of IT infrastructure resources across a range of loosely coupled microservices. The Kemp ADC is designed to enable DevOps teams to define a desired state of all the load balancers in the distributed IT environment, including F5 Big-IP, AWS Elastic Load Balancer, Nginx, and HAproxy load balancers. That capability then makes it easier to roll out distributed application services.

    Over time, Downes said Kemp will extend that capability to open source load balancers such as Envoy, which are starting to be deployed on top of Kubernetes clusters. Both Kubernetes and Envoy are being developed under the auspices of the Cloud Native Computing Foundation (CNCF). As critical as load balancing will be within a Kubernetes cluster, however, Downes noted distributed applications will span cloud-native and legacy IT infrastructure environments as well as multiple Kubernetes clusters.

    It may take a while for DevOps teams to fully sort out what form of ADC platform and load balancing capability to employ when and where. But as IT becomes more distributed, there’s rising interest in making sure IT infrastructure utilization rates for those applications remain as high as possible regardless of how they have been developed.

    — Mike Vizard

  • New Relic Accelerates AIOps with SignifAI Acquisition

    New Relic Accelerates AIOps with SignifAI Acquisition

    New Relic, following its acquisition of SignifAI, is in the process of accelerating its investments in machine learning algorithms and other forms of artificial intelligence (AI) as part of an effort to make it easier to separate the signal from the noise created by all the alerts in an IT environment.

    Aaron Johnson, senior vice president of product management at New Relic, said SignifAI represents an opportunity for New Relic to create a superset platform that can apply advanced analytics to a much wider range of data sources. SignifAI has already created more than 60 integrations spanning open source and commercial monitoring tools that are widely used across DevOps toolchains, he noted, adding that as New Relic moves to add other data sources, there’s an opportunity for the company to distinguish itself beyond providing software-as-a-service (SaaS) tools for monitoring applications and infrastructure.

    It’s obviously still early days for AI in the realm of DevOps. But it’s also clear that with the rise of microservices and containers, soon it will be impracticable for IT organizations to manually manage their IT environments. Various forms of automation based on AIOps platforms infused with machine and deep learning algorithms will be required. As a provider of SaaS-based tools for monitoring applications and infrastructure, New Relic already has access to vast amounts of data required to train AI models on optimizing a specific IT environment.

    Of course, there’s lots of competition across the IT monitoring category, so it remains to be seen which vendors will have the resources required to drive continuing investments in AIOps.

    In the meantime, DevOps teams will need to adjust their processes to take advantage of AIOps. It’s unlikely AIOps platforms will eliminate the need for DevOps teams, but the number of applications and platforms any DevOps team must manage effectively will increase substantially. Rather than replacing humans, AIOps platforms will reduce the pressure to hire additional IT staff when professionals with DevOps skills are already in short supply. The AIOps platform, for all intents and purposes, acts like a co-pilot.

    The biggest issue IT organizations are likely to encounter along that journey is establishing trust with any AIOps platform they implement. It takes a while for most AI models to learn the IT environment before that platform makes any reliable recommendations. In most cases, DevOps teams will have to dedicate staff to train and update AI models continuously as the IT environment changes. It may take years, however, before DevOps teams are comfortable enough to move beyond trusting a recommendation and enable an AIOps platform to automate processes on its own. After all, the only thing worse about being wrong about any IT decision is being wrong about it at scale.

    AI at this point is all but inevitable in DevOps environments. But it doesn’t necessarily follow that just because something is based on AI it always will be smarter than experienced DevOps professionals.

    — Mike Vizard

  • Open Mainframe Project: Zowe Ready for Prime Time

    Open Mainframe Project: Zowe Ready for Prime Time

    There is a lot of interest in updating mainframe technology/interfaces across traditional enterprises. As development environments and toolsets have evolved outside the mainframe, there is a struggle to keep up—partially because backward compatibility requirements make wild changes difficult and partly because the very architecture of mainframes is different.

    There have been several fragmented efforts over the last few years—some of them quite good—to update how a mainframe is accessed from external source and the ways that developers can code for the mainframe. After all, the number of developers proficient in mainframe toolsets continues to decline while the number of workloads does not, so something has to change.

    The Open Mainframe Project’s Zowe attempts to address these issues in ways that are both more widely applicable and more technologically advanced. It takes advantage of Open Source REST systems to front-end hardcore mainframe functionality, so developers who are accustomed to application server development can call things such as Spring Boot-based interfaces and use languages including Node.Js to access their mainframe systems.

    This week, OMP announced that Zowe 1.0.0 is production-ready. That means serious experimentation can be started at your organization to see if it addresses some or all of your mainframe modernization needs.

    There will likely always be some (at least operational) differences in mainframe systems usage because the software infrastructure is designed a certain way, but increasing modern tool usage makes learning those different parts easier across the board. By implementing a vendor-independent architecture that has guidelines for users and vendors to add functionality from anywhere, Zowe is a powerful and expandable tool for getting the job done.

    I sound a bit like a fanboy, but for most verticals, this is an issue that will continue to be a pressure point. It’s been more than a decade since companies started bringing back retirees to work on mainframe projects because new developers did not have the skills or interest to complete those projects. As more and more skilled CICS/RPG/PLI/etc. developers and mainframe operations specialists retire, this pressure will increase until it is resolved or unbearable. So I am a fanboy of any company/solution that is addressing this space instead of flocking off to the coolest new DevOps tool du jour. I’ve not yet used Zowe, so can’t directly recommend it, but reading over their documentation, I believe it’s a good idea to use tools we’re familiar with. So I’m rooting for it.

    If you test it out, drop a comment and let the rest of us know what you think.

    And keep rocking it. Whether in VS-2019 or VT-70, you are making the company engines hum.

    — Don Macvittie