The following is an excerpt from my AnsibleFest keynote at Red Hat Summit today.
Automation is nothing if it’s not solving a problem.
One of the best parts of our jobs is getting to see what our customers are doing, because the ingenuity they apply when using our product to solve their technology and business challenges never ceases to inspire. Our customers have pushed boundaries, and pushed us to continue to improve Red Hat Ansible Automation Platform, and deliver new capabilities. And sure enough, our customers have used Ansible Automation Platform to achieve remarkable gains in how quickly they are able to provision and configure their infrastructure, deploy applications, manage networks, security, cloud and more.
But we automators find ourselves at an inflection point. We’ve built a strong foundation. But how can automation help us solve the next set of problems, to get to the next level of operational efficiency?
- How do we enable app teams to access our increasingly complex and sprawling infrastructure?
- How do we ensure consistent, reliable configuration?
- How do we make sure that the right policy securities are applied?
- And how do we do all this as widely as possible, for as many people as possible?
Then, importantly, execute securely and be able to prove what we did or are going to do.
Employing an Ops as Code approach
So what do I mean by “Ops as Code?” It’s a simple enough idea in theory. Ops as Code is built on the same promise as Infrastructure as Code or Config as Code; to allow known sequences of tasks to be executed in a repeatable, scalable way - and by doing so, reduce toil and help teams move faster.
But we view Ops as Code as an elevated progression from those other two terms. We’re talking about taking the accumulated knowledge of Ops, infra and app teams - all the context they’ve learned by working through problems - and codifying it in Ansible Playbooks and in our new Event-Driven Ansible solution, which uses Ansible Rulebooks. These rulebooks are also supplying your team with great documentation. The same approach we’ve been promoting with Ansible from the start.
Doing so means that operational knowledge doesn’t just live with individuals on teams. The “how to” of Day 2 is converted into code - into something tangible that can be executed as systems become increasingly intelligent and complex, and importantly connected. And that’s always been the goal, right? As more and more tasks get automated, a larger variety of problems can be identified and addressed more quickly - freeing up people to focus on tackling new challenges.
Ops as Code isn’t about replacing people or processes, it’s about how we extend and move further to completing the automation story we’ve been advancing over the past decade. So that the same benefits and lessons from automating one stage of our systems lifecycle can be applied to more of that end-to-end. We are building on our foundation and applying those learnings to other areas where there is a problem that needs fixing.
This is where we really need to level up our thinking and expand our conception of automation across the entire lifecycle. We have our existing systems, our cloud systems and many of us will have edge systems. This goes back to the power of “and” ⎯ whatever your teams are planning and doing, they should be thinking “... and automation, too.” Infusing your automation strategy into the very DNA of all your operations is the path to achieving truly transformative end-to-end automation.
So, Ops as Code is the approach that we think offers the best chance to deal with your tech sprawl, with pressured resources, in the places you need to be, taming the complexity.
But there are two other factors to consider as well:
- How does automation content get created and shared? This is where Ansible Lightspeed with IBM Watson Code Assistant comes in. An Ops as Code approach can help organizations really get more from AI. As SMEs use generative AI as a tool to help them create automation content, they are training data models with invaluable contextual expertise. This context is then codified, goes back into the model and makes everything stronger. A virtuous cycle that is our end goal for bespoke, customer trained data models. This is why “as Code” is so important.
- How does all the automation you’re creating get triggered? With Event-Driven Ansible. You were already introduced to Event-Driven Ansible, but let me tell you why it’s going to change how you think about automation.
Why the next wave of automation is event-driven
Event-Driven Ansible represents an exciting next step for organizations and teams to take their automation to the next level, which has been the driving force of our product roadmap for a while.
You’ve got a variety of solutions and tools collecting data and identifying problems. When they find a problem, they raise a ticket and send an alert. What happens when you get that alert? You call it out to someone whom you hope is the right person. In the meantime, time is money. If the issue is mission critical, you have pressure building and dependencies at risk while you wait to get things sorted out.
All of these steps, and the real irony is this: How many problems do we have that are fixed by a known solutions pattern? We may know the answer, but someone has to log on and fix it. This takes a lot of time while there is an issue or outage.
Event-Driven Ansible offers a better way. It builds on what makes Ansible so popular ⎯ broad applicability and ease of use ⎯ and expands to tackle the problems we’ve discussed here today. Event-Driven Ansible introduces some new concepts, but in a very familiar architecture with sources, rules and actions.
For individual Ansible users, they can use their existing skills and experience from day one. They’ll be able to use Event-Driven Ansible to translate thought processes for common problems ⎯ and their solutions ⎯ into Ansible Rulebooks, which function in a similar way to Ansible Playbooks.
And at an organizational level, Event-Driven Ansible, as part of Ansible Automation Platform, helps scale these solutions to extend efficiency across all of your existing investments. We integrate Ansible into sources of information - things that normally trigger a manual response, then we can run the automation you’ve already built.
Because ultimately, you can write all the automation you want for operational activity, but you have to be able to run it when and where you need to run it. And that’s what Event-Driven Ansible is designed to help you do: Receive, decide and respond.
This model is great for issue remediation, but it has many additional applications – like controlling configuration drift, responding to changing conditions, ticket approvals, and response to security incidents. There are many places in your lifecycle you can respond to a known event without manual activity.
If you’re ready to learn more about Event-Driven Ansible, we have a ton of great content for you to explore.
저자 소개
Richard is responsible for the Ansible Automation Platform strategy. With more than 16 years of experience in Financial Services IT across a range or operational, design and Architecture roles. As well as being an Ansible customer before joining the Red Hat team, he brings a customer focused viewpoint to compliment the strong engineering capabilities of one of the most popular open source projects.
채널별 검색
오토메이션
기술, 팀, 인프라를 위한 IT 자동화 최신 동향
인공지능
고객이 어디서나 AI 워크로드를 실행할 수 있도록 지원하는 플랫폼 업데이트
오픈 하이브리드 클라우드
하이브리드 클라우드로 더욱 유연한 미래를 구축하는 방법을 알아보세요
보안
환경과 기술 전반에 걸쳐 리스크를 감소하는 방법에 대한 최신 정보
엣지 컴퓨팅
엣지에서의 운영을 단순화하는 플랫폼 업데이트
인프라
세계적으로 인정받은 기업용 Linux 플랫폼에 대한 최신 정보
애플리케이션
복잡한 애플리케이션에 대한 솔루션 더 보기
오리지널 쇼
엔터프라이즈 기술 분야의 제작자와 리더가 전하는 흥미로운 스토리
제품
- Red Hat Enterprise Linux
- Red Hat OpenShift Enterprise
- Red Hat Ansible Automation Platform
- 클라우드 서비스
- 모든 제품 보기
툴
체험, 구매 & 영업
커뮤니케이션
Red Hat 소개
Red Hat은 Linux, 클라우드, 컨테이너, 쿠버네티스 등을 포함한 글로벌 엔터프라이즈 오픈소스 솔루션 공급업체입니다. Red Hat은 코어 데이터센터에서 네트워크 엣지에 이르기까지 다양한 플랫폼과 환경에서 기업의 업무 편의성을 높여 주는 강화된 기능의 솔루션을 제공합니다.