devopsy.kinsta.cloud

Tag: Red Hat Ansible

  • Red Hat and IBM Pledge to Bring NLP to Ansible

    Red Hat and IBM Pledge to Bring NLP to Ansible

    At the Ansiblefest 2022 conference today, Red Hat and its parent company IBM announced the Project Wisdom initiative to bring natural language processing (NLP) to the open source Ansible IT operations automation platform.

    At the same time, Red Hat announced that the curated instances of Ansible from Red Hat are now available in the marketplaces operated by Amazon Web Services (AWS) and Microsoft.

    Richard Henshall, senior manager of Ansible product management at Red Hat, said the goal is to make IT automation much more accessible to a broader range of end users and IT professionals that lack the declarative programming expertise to use YAML files to automate IT processes. Instead, Red Hat and IBM Research teams are pledging to combine their expertise to create an artificial intelligence (AI) model that would enable anyone to use natural language to automate an IT process.

    Ansible has emerged as the de facto open source standard for automating a wide range of IT processes, but the number of processes that could be automated still far exceeds the number of IT processes that are currently automated. In recent years, IT automation tools have become more accessible thanks in part to the rise of low-code and no-code tools, but some level of programming expertise is still required. Project Wisdom is being launched to eliminate the need to acquire those skills before being able to automate a process.

    Of course, there will still be complex processes that may require the ability to programmatically manipulate YAML files, but the number of trivial IT processes that could be automated is still incalculable. In theory, a natural language interface for Ansible would greatly reduce the time and effort required for anyone to automate an IT process regardless of their skill level.

    Interest in IT automation is rising once again as the global economy continues to soften. Organizations are looking to automate as many processes as possible in their efforts to keep IT staff size as small as possible. The more time IT teams spend on manual processes the less they will be able to manage IT environments that get more complex with each passing day.

    It’s not clear to what degree IT processes can be automated, but as businesses become more dependent on IT, the line between IT automation and business processes continues to blur. Natural language processing capabilities could make it simpler for organizations to greatly accelerate digital business transformation initiatives.

    Regardless of the level of IT automation achieved, it’s clear the way IT is managed is about to evolve once again. The days when IT teams configured and provisioned IT resources using fragile custom scripts are coming to an end as platforms like Ansible are more widely adopted. The only issue that remains to be seen is how quickly IT processes can be automated and whether the rate of automation can keep up with the volume of applications currently being developed.

  • Red Hat Adds Managed Ansible Service on Azure

    Red Hat Adds Managed Ansible Service on Azure

    Red Hat today announced general availability of a managed instance of the Red Hat Ansible Automation Platform on the Microsoft Azure cloud.

    Announced at the Red Hat Summit 2022 event, this offering makes it possible to deploy the control plane for Ansible on the Microsoft Azure cloud as an alternative to existing support for Amazon Web Services (AWS) or an on-premises IT environment.

    In addition, in version 2.2 of the Ansible Automation platform, Red Hat is previewing support for content signing technology that automatically validates content to improve overall security.

    Thomas Anderson, vice president of Ansible for Red Hat, said this managed service enables IT teams to take advantage of integrated Microsoft billing in addition to the latest features and content provided for the platform and other capabilities that have been added to optimize Microsoft Azure environments.

    The open source Ansible platform has been gaining traction as an automation framework that enables IT teams to declaratively automate tasks. It requires less programming expertise than rival automation frameworks, which Anderson said is the primary reason so many third-party vendors have adopted Ansible to automate a range of IT tasks.

    The challenge many organizations encounter today is managing multiple islands of automation across multiple clouds and on-premises IT environments. Ansible presents IT teams with the ability to begin unifying all those islands under a single framework, said Anderson.

    It’s not clear to what degree DevOps teams that have embraced rival automation frameworks might be willing to replace them with Ansible. However, as more IT teams embrace automation to make up for shortages of IT personnel, it’s apparent that Ansible is being used across a wide range of IT disciplines spanning everything from DevOps to network management.

    Regardless of the approach, the need to automate as many tasks as possible is becoming critical as IT environments grow increasingly more complex. Many of the scripts that IT teams created on their own simply don’t scale. More challenging still, they are not often documented, so every time the IT professional that created that script leaves the organization it becomes difficult to maintain that scripting code.

    In the longer term, of course, automation frameworks will be increasingly infused with machine learning algorithms capable of learning the unique nuances of individual IT environments. It’s not likely those algorithms will replace the need for IT professionals any time soon. However, rather than resisting automation, more IT professionals have concluded that the tasks required are simply too challenging to manually perform. Many will conclude they simply prefer to work for organizations that have a consistent approach to IT automation that makes it feasible for them to manage a wide range of IT tasks.

    One way or another, IT automation is becoming a standard capability that now goes well beyond the scope of a few isolated DevOps workflows. The issue is finding a way for IT professionals with varying skill levels to collaborate across a common framework that is both easily accessible and highly extensible.

  • Red Hat Extends Scope of Ansible Automation Ambitions

    Red Hat Extends Scope of Ansible Automation Ambitions

    During the online Ansiblefest, Red Hat announced the availability of a preview edition of Red Hat Ansible Automation Platform 2 that is intended to make it easier to automate IT processes at scale.

    Richard Henshall, senior manager for Ansible product management at Red Hat, said previously most IT teams have been automating individual processes, but as organizations become more adept at creating playbooks to automate processes, they now need to find ways to manage multiple automations that are often dependent on one another.

    Ansible Automation Platform 2 also enables IT teams to automate processes that span both monolithic as well as cloud-native applications based on containers using an automation controller, formerly known as Ansible Tower, that is more tightly integrated with Red Hat OpenShift, an application development and deployment platform based on Kubernetes, using Red Hat Operator tools. There is also an automation mesh capability that connects disparate automation components together and provides status checks.

    Ansible Automation Platform 2 also introduces automation execution environments within Ansible Engine that make it possible to create self-contained automation spaces that can be easily replicated and repeated across an organization.

    Red Hat also includes an automation content navigator to helps teams validate that automation content is working as it should across even the largest environments, along with updates to the Red Hat Insights analytics service that enable issues that might occur with automation controllers to be surfaced and eliminated by automatically applying policies.

    Henshall said going forward, IT teams should expect to see Red Hat focus more on enabling events to be the catalyst for triggering automation. Today, most automated processes begin with an IT administrator triggering the process. However, as digital business transformation initiatives mature, it’s become apparent there will be a need to trigger automation when specific events occur.

    Henshall said while there are still many organizations that are just starting to automate IT processes, there are also many that are entering the next phase of maturity. As such, they now require an automation platform that makes it simpler to manage automation at scale.

    In general, Ansible is designed to make it possible for developers and IT operations teams alike to declaratively create automation without much programming expertise required. However, creating a playbook that works reliably still requires a deep understanding of the processes that are being automated. Most IT teams would be well advised to closely monitor processes when they are first automated to make sure they are performing tasks as anticipated.

    Ultimately, it’s now a question of when rather than if most IT processes will be automated. DevOps teams, of course, have always been at the forefront of automation, but now it’s clear that as IT environments become more complex—with the rise of both the cloud and edge computing platforms—enterprise IT teams need to embrace automation more aggressively. The biggest barrier to automation is simply finding someone who has the passion to automate a process to lead the charge, said Henshall.

    Naturally, most of those efforts will initially focus on repetitive, tedious and manual IT tasks, but the potential to automate IT processes at levels of unprecedented scale has never been greater.

  • Knowledge Is Power

    Knowledge Is Power

    I was doing some research over the weekend, and it became abundantly clear that you can find an Ansible script to do pretty much any repetitive task in your infrastructure. This is good news for Ansible users, and the pool of available scripts will, no doubt, continue to grow as critical mass effect kicks in.

    My concern is for those that find a script that does what they want/need, and drop it into their infrastructure. This approach may be a good short-term fix, but is full of potential peril. Even a cursory read of a complex script is insufficient.

    We all know the watchwords of the day are “speed” and “agility,” but take some time to test and get to know those scripts. When (not if) they fail, you’re going to want a clue of what is going on in there to track it down, and you certainly want to understand what is being pulled into your infrastructure. While the community is likely to catch malicious scripts relatively quickly, the inclusion of questionable sources and cases where your infrastructure causes a script to have issues are more likely to make it to your desk.

    The easiest validation cycle is to:

    • Read it for understanding. Know what it is doing, why it is doing it and what it is including.
    • Run it in an isolated environment. A pod, a VPN, whatever, just somewhere that you can control ingress and egress.
    • Scan the results as you would anything in production. Make certain sources are valid for your organization, make certain inclusions are safe and validate that any vulnerabilities in the resulting systems are known and acceptable to your organization.
    • If you can, do runtime testing upon it to catch any real-time changes. Most “changes after install” type of software is either well known or not included, so this step is more peace of mind than mandatory.

    If your thought was “takes too long, not necessary,” the risk is on you. But on the list of weaknesses in DevOps, that mentality is definitely in the top three. “Takes too long” is an organizational concern that is different everywhere. “Not necessary” is only true until it isn’t. As an IT professional, having at least a passing familiarity with the environments you are creating is part of the job. Fail to do it at your own risk.

    Much like there are trusted sources for the various types of repo we access, trusted playbook developers are a list you can curate. I know of a few that, in a pinch, I’d be willing to drop a script from into my architecture with only a cursory review, then give it a more thorough going over later when there is more time. But I know that because I’ve read their scripts, and I get that they are also careful.

    While I have Ansible scripts on my mind because that’s what I was looking into, this advice applies to any and all automation scripts that pull from outside sources. Python and Node do a ton of this too, but only highly complex projects pull from a lot of disparate sources. Ansible and other infrastructure automation tools pull from a variety of sources almost by definition (because infrastructure is complex), so they deserve more attention.

    In the end, automating all the things changes nothing about responsibility. So, take the time to make certain you know what is going on in your environment, and why. If you are really motivated, take the time to sweep through and remove any references you are certain you don’t need — but nested dependencies make the ROI on this type of work minimal, in my experience.

    Meanwhile, you are keeping a ton of servers running and users happy. Keep rocking it, and keep looking for solutions like automation scripts to make you more responsive — just don’t relinquish your authority for the datacenter to random submitter on the internet — because responsibility will still be yours.

  • IBM and Red Hat: Now, That’s an Interesting Combination

    IBM and Red Hat: Now, That’s an Interesting Combination

    Like everyone else, Sunday night I got a surprise with the pre-announcement of IBM’s intent to acquire Red Hat (I might have seen it a little earlier than the rest of you, as a friend from IBM shared it as soon as it was public). I’ve been mulling this over and checking out the information being provided thus far, and have some early thoughts:

    • No matter what, some people aren’t going to like this.
    • Very much like Microsoft purchasing GitHub, you’ll see negative knee-jerk reactions.
    • Early indicators are that it is good for everyone.

    Of course, since the acquisition isn’t expected to close for about a year, all we have is early indications, but they do seem positive.

    Fear for Open Source

    IBM goes a long way to assuaging the instant fear that many will have. From the press release to the investor relations call, the company makes it very clear that Red Hat will operate on its own. IBM stops short of saying, “wholly owned subsidiary,” but is keeping all that makes Red Hat, well, Red Hat. That will likely change over time—it does for any acquisition—but for the near future, Red Hat’s strategies and values will continue. So those people who will inevitably equate this to the death of open source can be safely shushed or ignored.

    Customer Concerns

    Red Hat knows that there is an open source equivalent to everything it does, and as such it treats those willing to fork over money either for support or more polished products as if they could walk away tomorrow. There is nothing in any of the released documentation to suggest this will change. In fact, “keeping Red Hat’s strategy” specifically was mentioned to investors, and this world view informs all of their strategy. One Red Hat person I worked with years ago put it: “We need to give them a reason for paying us when they don’t have to. That’s where support and service come in.” In the short term, that does not appear to be changing.

    Cloud Boom!

    IBM is right, the future of cloud is in two narratives: one of cloud portability and another of on-premises for stuff that just isn’t that portable. IBM plus Red Hat is in a unique position to serve those two markets and offer up DevOps toolsets based on standards that will spin up whatever, wherever. Between them, they work with every major public cloud vendor, support containers and have fingers deep into the private cloud space. If their predictions that workloads will continue to move toward on-demand is accurate, it will be difficult to find a better solution set than the two can offer together.

    So Overall, it Looks Good

    I was in discussions on several social media platforms over the course of Sunday evening about this, and the consensus seems to be that it could be far worse. If Red Hat were for sale, think through all the companies that would see benefit in owning Red Hat, and could afford the price tag IBM paid. There are not a lot that could be counted on to “Let Red Hat be Red Hat.” Over the long term, IBM can’t either, but that is simply business. In the short term, it is reasonable to expect that not much will change except Red Hat customers get pitched more IBM software and gear, while IBM offers Red Hat standard with their other offerings. Other potential purchasers would likely completely fold Red Hat into their business, thereby destroying what makes the company unique. So if Red Hat was going to be sold, the face the two companies are putting on it is the best we could hope for.

    Ops Side Love

    Red Hat has done a good job of integrating containers as they came along, and Ansible provides decent configuration support for a variety of deployment targets. Merging that with IBM’s cloud work should offer a streamlined DevOps pipeline that can handle whatever target you want it to configure. Oh, certainly there will be speed bumps along the way—we do live in a time of change, which brings them along—but portability plus programmed configurability will (as IBM has hinted) equate to prequalified stacks that can then be dropped into deployment toolchains.

    Not too Long to Wait

    While the official merger will not be consummated until late next year, expect to see the two organizations use their longstanding partnership to begin exploring cross-company cooperation before that. We should see the first fruits of this arrangement relatively quickly, and unless Red Hat’s investors find some reason to vote down a HUGE raise of their per-share stock value, expect that the cooperation will continue to ramp up until the acquisition is completed.

    If Red Hat Stays the Same…

    Given that IBM has said Red Hat would stay the same for the foreseeable future, that means all you are doing with the company can keep going, and you can pick and choose which of the partnership options that are bound to come along pre-completion you wish to take advantage of. That’s a benefit to the customer. So grab what you like and keep making your DevOps environment better.

    — Don Macvittie

  • Itential Announces Integration with Red Hat Ansible Network Automation

    With Red Hat Ansible Network Automation, Itential to enable network engineering and IT operations teams to create and execute network automation capabilities without writing code

     

    AUSTIN – ANSIBLEFEST 2018, OCT 2, 2018 /PRWeb/ — ItentialÒ, the leader in intelligent network automation, today announced at AnsibleFest 2018, its integration with Red Hat Ansible Network Automation. The integration is intended to enable both network engineering and IT operations teams to create and execute network automation capabilities without writing code.

     

    Red Hat Ansible Network Automation is a powerful tool for automating network configuration changes and is an innovative tool for networking teams across the globe. By using common APIs to “handshake” Itential and Red Hat Ansible technologies, organizations can apply low-code methods and intelligent capabilities to networking automation. This can help teams to accelerate their organization’s movement toward a software-driven network operations practice.

     

    “Through the integration with Itential, we can extend Ansible automation deeper into organizations that may lack specific networking expertise,” said Justin Nemmers, general manager, Ansible, Red Hat. “Using Itential’s service orchestration capabilities with the powerful automation of Red Hat Ansible Tower helps to provide users an additional tool in automating within their organizations.”

     

    The Itential for Red Hat Ansible solution includes features that help enhance and expand Ansible’s network automation capabilities:

     

    • Network Automation Activities – Itential’s low-code development interface can allow network engineers and operators to create and execute network automation use cases without writing code.
    • Build Network Intelligent Workflows – Leverage Ansible modules, roles and playbooks, along with Itential’s integrations and adapters, for network automation.
    • Expand Ansible Use Cases – Itential’s network automation capabilities enable organizations to expand the types of network changes automated with Ansible to include orchestration changes crossing multiple, diverse automation domains.
    • Discover Ansible Modules & Roles – Itential dynamically discovers Ansible modules, roles and other network configuration actions in your environment, making them available for use within network intelligent workflows.
    • Federate & Decorate Ansible Playbooks, Roles and Modules – Itential enables Ansible users to enhance their playbooks, roles and modules for easier consumption, and dynamically identifies and leverages both certified and custom developed Ansible automations.
    • Leverages Red Hat Ansible Tower – Itential’s enhanced network automation supports Ansible Tower’s single pane of glass across DevOps, App Dev and NetOps teams, including a visual dashboard, job scheduling, integrated notification and graphical inventory management.
    • Itential Ansible Modules – Itential’s Ansible modules mean Itential can be called from playbooks and Ansible Tower job templates. Itential modules for Ansible are available on www.github.com/itential.

     

    “We have seen network engineers embrace Red Hat Ansible Network Automation,” said Chris Wade, co-founder and CTO of Itential. “Now with the integration of Itential’s federated and network intelligent workflow builder with Ansible Network Automation, organizations have a more comprehensive set of technologies that can help accelerate their journey toward network automation.”

     

    Itential simplifies and automates the journey toward the modern network and bridges the gap between IT and networking teams by enabling users to easily build, execute and visualize Network Intelligent Workflows. Itential’s low-code environment provides a vendor agnostic, turnkey solution, connecting network orchestrators and controllers with IT Service Management applications and configuration tools to accomplish closed-loop network automation. Itential’s products are in use today within some of the world’s largest networks, including many of the top service provider and financial services companies throughout the U.S. and abroad.

     

    To learn more about Itential for Red Hat Ansible Network Automation, click here or stop by booth #302 to see a live demo or to meet with a member of our team.

     

    About Itential

    Itential provides powerful network automation software to companies worldwide, from Fortune 500 telecommunications and financial service companies to enterprises of all sizes. We are committed to building world-class products that accelerate the move toward software-driven networks and next generation, agile network operations. We are exclusively focused on delivering network automation solutions that help our customers realize their vision of digital transformation. Our solutions leverage the latest thinking, open standards, open architectures, partners and best practices to drive network operations and maximize the impact of automation. Learn more at www.Itential.com