The term DevOps is used in multiple ways, but in its broadest meaning, DevOps is an operational culture that aims at continuous development and integration, and rapid IT service delivery by promoting better communication and improved collaboration between developers and operators. It has become an integral part of different industry sectors, from startups to large enterprises are leveraging DevOps tools to support their business processes, and project planning until delivery.

With the increasing use of cloud computing and virtualization platforms, the need for new services has increased. The DevOps helps organizations respond in a more agile manner to changing business requirements by:

Automating and monitoring the process of software creation -from integration, testing, releasing to deploying and managing it.
Reducing development cycles.
Increasing the frequency of deployment.
Streamlining the development and release pipeline.
Thus, using agile DevOps, the development and operations team can work together more efficiently and deliver applications and services at a faster pace. Also, they can roll out machine level changes in the multi-server environments by using DevOps automation/configuration management tools.

Get 30% Off on Cloud VPS

IT industry is flooded with many new DevOps tools which come with various features and this makes embracing the right DevOps platform or configuration management tool a bit difficult.

Related read: Top 5 collaboration tools for DevOps teams
Comparison of top DevOps automation tools: Ansible vs Chef vs Docker vs Kubernetes vs Puppet
Walk through this post where we have compared top 5 best DevOps automation tools – Docker vs Kubernetes vs Puppet vs Chef vs Ansible to make things simpler for you.

1. Ansible
Ansible is another simple but powerful DevOps continuous delivery tool. This server and configuration management tool makes IT automation simple as it ends repetitive tasks and enables faster application deployments, thus allowing DevOps teams to perform more strategic work. It automates configuration management, orchestration, application deployment, cloud provisioning, and a number of other IT requirements.

The ecosystem of Ansible comes with the option to write custom applications. It can be used to make changes in newly-deployed machines and to reconfigure them.

Ansible Tower, powered by Red Hat, enables secure management and control of multi-tier complex deployments and boosts productivity.

The difference between Ansible and the above configuration management tools (Puppet, Chef) is that Ansible is mostly used for configuration deployment and is simpler in comparison to other DevOps tools.

Suggested read: Top 4 AI engines to look out for in 2020
2. Chef
Chef, the configuration management tool, delivers fast, scalable, and flexible automation of web-scale IT. Chef automation tool uses ‘recipes’ for web-server configuration, databases, and load balancers. The recipes, which Chef uses to automate infrastructure tasks are in the form of instructions. They help in defining the infrastructure components and how those components can be easily deployed, configured and managed.

Below diagram shows you how Chef code is developed, tested, and deployed.

DevOps automation tools chef

Chef’s configuration policy enables users to define infrastructure as code, test configuration updates, development infrastructure and cloud instance with its development tools.

Chef, the most notable Infrastructure as Code (IAC) tool, runs the software in client-server mode (Chef-server) and ‘Chef-solo’, the standalone configuration, packages the configurations into JSON files called ‘cookbooks’.

Suggested read: Cloud DNS management comparison: Alibaba, Amazon, Google, IBM, Microsoft
3. Dockerdocker DevOps automation tools
Docker is a software container technology platform that enables its users to create, deploy, run, and manage applications within the containers. Build on Linux Containers (LxC), it gives freedom to application/infrastructure developers and IT operation teams to create virtual environments and provides a platform for improved innovation and collaboration.

Docker’s design is modular which allows its users to build applications securely, both on-premises and in the cloud – it integrates well with the existing environments.

Docker containers run within the kernel of the host machine and they don’t require additional hypervisor load, so they are lightweight. Docker Engine, the client-server application, includes a daemon process (the dockerd command), a REST API to specify the interfaces that programs use to interact to the daemon, and a command line interface (CLI) client.

Docker’s client-server architecture enables the client to work with daemon – which helps the clients build, pull and run along with the distribution of containers.

Its standardization feature enables developers to analyze and fix bugs in the applications, as well as change Docker images, more efficiently. The users can build a single image and use it across every step during the deployment.

Related read: What are the Career Opportunities in DevOps?

4. Kubernetes

Updating and migrating of servers were the two serious issues that enterprises experienced traditionally, as different websites use specific software versions. But today, containerization has solved this problem, successfully. There is a shift underway, the DevOps focus has shifted to writing scalable applications that can be distributed, deployed and run effectively anywhere.

DevOps automation tools

As a first step, Docker helped developers to build, ship and run software easily but Kubernetes has helped DevOps to run containers in a cluster, manage applications across different containers while monitoring them effectively. Built on a modular API core, it allows vendors to build systems using core Kubernetes technology.

Designed by Google, Kubernetes is an open source system that provides mechanisms to deploy maintain, and scale containerized applications with automation. Kubernetes is currently maintained by the Cloud Native Computing Foundation (CNCF).

Kubernetes allows DevOps to efficiently fulfill customers’ demands by deploying applications predictably and quickly, scaling them, launching new features and limiting hardware usage to only the needed resources.

Being open source, Kubernetes can be run anywhere and can be used with the public, private, hybrid, multi-cloud environments. It is self-healing and offers load balancing and service delivery features along with batch execution and storage orchestration. It also offers features like auto-replication, auto-placement, auto-scaling, and auto-restart.

5. Puppet
This flexible, cross-platform and open source DevOps configuration management tool, automates the delivery and operation of software during its entire lifecycle. Using Puppet, development, and operations teams are able to deliver and operate software (infrastructure, applications) securely and from anywhere.

Puppet increases manageability and productivity. With it, users can understand the changes taking place in applications and act on them accordingly with the help of in-depth reports and real-time alerts. Users can identify those changes, and remediate the issues.

DevOps automation tools puppet

Puppet contains a daemon called Puppet Agent that runs on the client servers and its another component, the Puppet Master contains configuration for all the hosts. Both Puppet agent and Puppet master use SSL for secure encryption.

This model-driven software requires limited programming knowledge to use. It treats infrastructure as code and thus, helps in easier configuration testing & reviewing across all the environments- be it development, test or production.

Tabular comparison of top automation tools for DevOps (with list)
Ansible Chef Docker Kubernetes Puppet
Automated configuration management tool Automated configuration management tool Container technology based Linux platform Automated configuration management tool for containers Automated configuration management tool
It uses Python It is written in Erlang &Ruby It is written in Go programming language Just like Docker, it is also written in Go programming language. Ruby-DSL (domain-specific language) language
Easy for configuration management Complex from the development perspective Easy to manage, understand and isolate. Kubernetes set up requires well-planned efforts when it comes to defining nodes and manual installation. Difficult for beginners
Better for front-end developers, where some programming might be needed It’s similar to Puppet Docker comes with several powerful functionalities and components For developers of modern applications More targeted towards operations – not requiring development background
Produces files in a similar manner as Puppet does Builds a pipeline of processes Docker allows configuration for a single process at a time, thus making Docker files simpler than bash script for process configuration Kubernetes brings a lot of complexity as it is a larger project with more moving parts than any other DevOps tool, but that also leads to latency in executing commands, making troubleshooting and monitoring cumbersome. It may make dependencies complex- may configure more than one process at a time.
Besides the above-mentioned DevOps automation testing tools, there are a number of other tools as well, like Papertrail, Nagios, Jenkins, Prometheus, and Splunk that make the lives of DevOps teams easier.

Papertrail is a frustration-free log management tool that allows you to instantly manage logs from different servers.

Get 30% Off on Cloud VPS

With Papertrail, you can consolidate your logs in one place with a cloud-hosted log management service that takes typically only minutes to set up. Quickly diagnose and fix customer problems, error messages, app server errors, and slow DB queries with full visibility across all logs.

In this episode, host Jon Collins speaks with Christina Noren about her experience running Agile organizations and how DevOps can be implemented at various stages in an organizations life.

Christina has more than 20 years of experience in product, services and operations at successful, venture-backed companies, such as Splunk, Zuora, Portal and Sonic Solutions. She has a particular strength in identifying and refining product offerings in evolving markets. At Splunk, she was employee #12 in 2005 and remained on the senior leadership team through its 2012 IPO. She played a critical role in bringing Splunk’s 1.0 product to market, overseeing requirements definition, product delivery and the beta program. She went on to guide key technical innovations, including search-time knowledge and the Splunk search language. Christina is a co-inventor on the Splunk patent for Machine Data Web.

Transcript

Jon Collins: Hello and welcome to this week’s edition of Voices in DevOps. I’m here to speak to Christina Noren of CloudBees. Now, am I going to get your title right? What do I say?

Christina Noren: I’m the chief product officer, the CPO, and the key thing is that for us as CPO, I’m responsible for all of engineering and product management and product marketing and design and documentation. So I run a whole software organization and we’re building a product to bring a whole software organization together, so I am our internal… first customer of how do we do we do Agile and DevOps and continuous delivery better; and how do we run a software organization in as professional a way, as my peer running our field organization runs his.

Thank you very much for joining us Christina. What we’re trying to get out of this is: organizations out there are struggling with DevOps. They may have started on the DevOps route and they’re finding it more complicated than they thought. So I’m really, really interested already in the fact that you’re not only kind of a purveyor of DevOps products if you like, but you’re also the internal person who makes this stuff happen and therefore you’ve got to ‘walk the talk’ essentially.

Yeah. Exactly. That’s the term we use.

Good. How did you get here? If I may ask, what enabled you to end up being the CPO of one of the world’s foremost… (I mean I don’t want to blow smoke but essentially CloudBees, everyone’s using Jenkins) everyone in the cloud space has heard of CloudBees, so how did you get here?

Yeah well it’s been a funny journey.So CloudBees, you know I’ve been here just a just over a year and my team is responsible for product management, engineering, product marketing, design, documentation as a holistic function in the company. And I’ve been in software for 25 years. Like a lot of people, especially women of my generation, I came in through the back door and got technical [experience] on the job and held a whole variety of roles in my early career.

But starting in the early 2000s, I started running product management organizations just as engineering organizations were starting to move towards Agile, and I ran product for a few different companies in the log management space, but most notably I ran the product, I was the founding VP of product management and also started a lot of other surrounding functions for Splunk, from stealth mode when I was employee #12 in 2005 through our IPO in 2012. In that experience and previous jobs and jobs since, I’ve really found myself trying to figure out how product management and product marketing, the business, support, everything can align with engineering practices that are moving away from waterfall and into Agile; and then being responsible for product at Splunk, as really revolutionary way of looking at what was happening in production.

The sys admins using Splunk were often the ones that started becoming SREs and a lot of DevOps started to happen amongst our customers in those mid-2000s, so the products that I was responsible for… we’re a big part of the Ops side of DevOps. So and then in the most recent CPO job I had at a company called Interana, prior to CloudBees, I really saw how implementing CICD completely transformed the rhythms between product management and design and engineering and our outcomes.

So I was kind of primed when CloudBees came calling and why a historically product leader is running a product engineering organization that’s building a product primarily used by engineering organizations… that was my first objection. But what they really want is a product mindset, and moving from technology and sales driven to being product driven is something that not only a lot of historically technology companies are doing, but is actually one of the things that companies with traditional IT organizations are doing. They’re trying to become product organizations and that’s the core of becoming software companies.

Well I’m literally trying to draw pictures as you speak. I’ve got a mesh is appearing, we’ve got the Ops side, we’ve got the engineering side, we’ve got the product side. And then we’ve got the Agile thing and I think what’s really interesting about what you’re saying there is: seeing Agile from an Ops perspective and from a product perspective. And then how that feeds back into development, that’s pretty much the reverse of what other people are talking about.

Yeah. And you can find a slide show that’s still up (from 2008) under my name of [me] talking about automating product management in an Agile world, which was kind of my fledgling stage of making peace with engineering doing Agile, which was an early stage of development. But these days you know we really talk about ‘continuous’ and not just continuous integration, continuous delivery, its technical practices, but I’ve been talking a lot about ‘continuous everything’ as a way of looking at every process in the business that touches software delivery, or that software delivery touches, and realizing that if it doesn’t change to be compatible with continuous approaches, it’s going to be an impedance mismatch that robs the organization of much of the value of continuous software delivery.

So take me back to 2008 if you will, and I’m wondering about which came first: the chicken or the egg on this one? Is it that the product mindset works better in an Agile way or is it that the Agile ‘continuous everything’ mindset enables better products?

Well I think it’s both, but I think… Agile came out of engineers revolting against how ineffective, you know the waterfall methodologies were. And a lot of very simplistic views of what a product manager is doing is maintaining the roadmap, and it’s damn hard to maintain a roadmap when engineering is iterating and changing sprint to sprint.

I think today’s generation of product managers have really embraced Agile, even if they’re still quixotically trying to produce roadmaps. There’s a real disconnect there. But I think in the day to day work, good product managers, good young product managers who aren’t tainted by the early bad experiences, like they really see their job as supporting that voice of the customer, taking early iterations quite rapidly to customers, a learning mindset, an experimental mindset and so forth.

So now I think Agile is very much at the heart of what a healthy contemporary product mindset is about. But you know as a second time young BPO product manager I was still in this, “Oh my God, my board members expect and my customers, my enterprise customers expect these roadmaps and if they change, it’s a big deal and how the hell do I produce these roadmaps?” Engineering is just all over the place doing this Agile thing. Right? That was my very early like “Oh my God I’ve got to make peace with Agile as a product manager, and what’s expected of me is a mismatch with what engineering is now delivering.”

You were stuck right in the middle of a dilemma. And I’m thinking—correct me if I’m wrong and I’m going to ask about 17 questions all at the same time. I’ll try and distill it down as best I can. But essentially you’re talking about the world of product if you like, so that’s the vendors, the software creation from a vendor perspective space.

So one of the questions is around how does that map into what you’re seeing with your customers? But another part of it is: a lot of the conversations around DevOps that I’m having and hearing and so on, certainly the more traditional ones, it’s about CICD. So it’s right in the middle of the development cycle as opposed to where product management fits, which is overarching. What are we going to do next? et cetera et cetera. So there’s all these questions milling around in my head.

Yes. So let me jump into that because the interesting thing is that most, and some other analysts have been writing about this for a few years or just like the rise of product management in I.T., but so if every company is becoming a software company, then IT departments are becoming software development organizations and whether the titles change or not, the mindset is changing and those who are ‘getting it’ are actually realizing that even if you’re an insurance provider or a financial services company or supply chain or whatever, the idea that IT is serving the business with projects is giving way to a product mindset. And the difference being that a product is a long running, ever evolving, thing that is being provided to a market segment, and we’re seeing that product mindset.

We’re seeing IT organizations that are really committed to their Agile and DevOps transformations and the cultural part are hiring or turning people into product managers, and they’re creating product teams whether or not the CIO’s title changes or IT changes as an department/organization name, but they are changing themselves into being product companies whether or not the consumers of those products appear to be their internal users. But increasingly because of mobile and apps and self-service and products like cars that are more vehicles for software than anything else.

Increasingly their end customers are consuming a software product from them. So this is to me very relevant and it’s not just for a narrow set of ISVs like ourselves that are producing enterprise software for a living and some consumer tech companies that have software product managers and software products. Every company that is believing that it is becoming a software company in their industry rather than that industry type company where an IT department is serving them, that’s the heart of these transformations.

And companies that are just thinking, to go to the second part of your question, that DevOps is just a technology and process adoption of CICD for the build-test-deploy lifecycle; and even more, early stage, just CI for build, test, get your artifacts, and then there’s some separate system to serve Ops PNs [or] whatever, deploying that to a complex development environment. If they see it as just that, they’re not going to see the full benefit.

But you know it’s a good starting place, and it often leads to these kinds of realizations because once you start doing that, then you start realizing that there’s not just other problems but there’s other opportunities. And if the team starts getting infected with DevOps culture and Agile culture from the ground up, they start saying “We’re no longer IT serving the business, we are empowered cross-functional teams delivering products that are constantly growing and getting better and serving our customers better over time.” And that’s really the engine of innovation and value in companies today.

So my experience of enterprise software delivery is a bit stale. It’s a couple of decades gone and largely it’s through the usual analytical research that I keep up to date, but I’m not doing it anymore. Back in the day when I was within this kind of thing, there were requirements teams, and they tended to have every requirement under the sun.

So what I was doing as the precursor of Agile and XP, a DSM consultant, was going in and saying you only need 60 use cases, you don’t need 500 requirements in this massive catalog. But so they were doing the kind of product thing, but they weren’t phrasing it in that way. And they were doing it wrong as far as Agile was concerned.

I mean 20+ years ago I was in MSN operations at Microsoft, carved out from Microsoft corporate IT to run our online services. And I produced requirements documents just like that and I managed teams of consultants from Deloitte and Andersen Consulting before it was Accenture. You know there were requirements analysts producing these things and nothing was ever on time. When it was delivered, it was never anything that was actually useful. So yeah I’m reformed from that stage too.

It’s okay, I’ve sat through the counseling now. Hi I’m John Collins, and I’ve done requirements management… So fast forward to the present day and how does it translate into, I’ll call it ‘the modern enterprise,’ which could be an oxymoron for some organizations. But when you are working with organizations today that, as you say, every enterprise should be an ISV, how are they actually managing their product orientation, their requirements, how would they frame this?

They’re all in transition. And you know I haven’t met a lot of leaders in IT or technology in companies in any industry that are at that level or realization of what they need to do with DevOps or CICD that when I sit down with them that I can’t have the conversation we’re having now and that they’re not already working on the cultural change. Their understanding of how far beyond engineering, beyond you know software delivery functions that extends varies. But this is coming from our customers’ experience of trying to get you out of Agile and DevOps to continuous practices, and expectations in the marketplace of becoming software or technology companies and understanding what that means.

And then what we’re also seeing is a lot of cross pollination where traditional companies in traditional industries, their IT teams are starting to staff people that have worked previously in the digital native companies: the Facebooks, the Googles, whatever, and they’re coming into more traditional companies. You’re seeing that more traditional banks are hiring people out of like a Capital One that understands themselves [more] as a technology company that happens to be in banking and it’s really good. And so you’re seeing the cross pollination, you’re seeing these ideas come in. You’re seeing people you know that are in the process of reform from what we just described, embrace these new ways.

There’s so much maturity around these new ways, and then you start to see sometimes individual pockets of teams that just sort of revolt or do their own thing and start working this way and start learning from outside and showing their organizations the results of a different way of doing things. So it’s changing. I think there’s differences in how much visibility is at like a C-level leadership outside of the CIO, of what the implications are for the business as a whole. Sometimes it’s a new CEO coming in because a board and the overall company sees they need to make this transformation and they’re fired up and driving it. Sometimes it’s within the IT organization, CIO organization that these new practices are coming and the CIO is explaining to their peers what the meaning of all this change is and why it benefits the organization.

I’d really like to pick you up in a positive way on the fact that you said the process of reform i.e. it is this kind of an evolutionary adaptation to the new world. And then you also used the term ‘transformation.’ And my disdain of the term ‘digital transformation’ is [from] the fact that it’s a bit like “we can get you a six pack in six weeks or beach body” or whatever. It’s all about this kind of ‘top down’ notion that all you’re going to do is just change and everything will be brilliant. Whereas if we do sit more in the process of reform kind of way that makes a lot more sense to me.

Yeah I mean it has to become grassroots whether or not it starts that way. You have to start having these pockets of people who want to do things in a different way. And start spreading that message. And it needs sponsorship and support from an executive level.

We do these CloudBees Days and we just had one in Madrid and in Zurich and San Francisco and Dallas and various places, and there’s a number of them and our customers that present tend to be the leaders of, (I know you hate the term) the “digital transformation” efforts or DevOps transformation efforts in their respective companies. They’re usually at a mid level of management where they’re close to the people on the ground and they’re responsible directly to people in senior levels and they’re translating between them, and that’s universally what they say on stage. They universally talk about how they have to overcome religious ideas at all levels. They have to overcome a lot of existing processes and so forth. T

The only way it works is when the people who are doing the work start finding their own way, their own flavor of doing this. There’s the executive support to understand that the SLA, if you will, from an organization working this way is going to be different—that the needs of that organization and the outputs of that organization are going to be different. There’s going to be a transition but they need support in terms of budget to invest in the tools, the training, the infrastructure that is new.

So one thing we have to talk about by the way, is just the cloud part of this, which is sometimes… coming in because people want to get the benefits of running the cloud and not running their own infrastructure anymore, and ‘cloud native’ and so forth, That starts to unravel and the people doing application development start thinking about converting legacy applications, microservices, and when you start to get into that culture, you can’t hire a bunch of people to work in that culture who don’t carry with them the seed of Agile and DevOps practices. All these things are sort of mutually supporting in terms of how these things are coming.

Actually to me amazingly, my year in CloudBees like a year ago, talking to the same customer as this year, the rate of change in organizations that we would consider to be very traditional enterprises with very traditional IT departments, it’s just been dramatic in terms of the rate of change and it’s been amazingly organic in the ones that are being very successful and management has let that organic process happen.

And I think you’ve hit on exactly… I don’t have a problem with things changing but I think it was this digital transformation as an epiphany. It’s a kind of overnight flick as soon as you brought in the term ‘organic.’ I’m thinking about it’s a bit like spring. You know it’s that kind of transition from nothing growing to suddenly you start seeing green shoots and everything, and it just kind of starts heading in the right direction because everyone’s getting it, and I’m much more comfortable with it…

I actually use a lot of garden and organic metaphors when I talk about this, but you know again a lot of people who have been speaking at our events talk this way, and if you think your digital transformation has an end date or has ended, you’re not getting it, which is digital transformation is constant, it’s a continuous process. And it’s a process of constantly adapting new tools and practices and culture. And evolving the culture to be able to be more effective and it doesn’t mean you can’t get a small start wherever you want. Start with one small team. Go ahead and start trying to drive nightly continuous delivery to internal servers across a set of projects and see how… and let the behaviors on the teams change as these practices enable them to change.

I’d love to be a fly on the wall of some of those sessions because these are what make the world go ‘round. Picking up on something you said there, it’s the difference between… I hear a lot of organizations need a cultural shift. What you’re actually talking about is enabling that cultural shift, so kind of getting out of the way of a cultural shift that would be inevitable if you just stop trying so hard to make it happen.

And again I’ve learned this the hard way, over and over and over again. So just in terms of some internal projects, we’ve actually been pretty transparent on the blogs and the blogs on CloudBees. We’re going through a digital transformation, we’re learning from it but we’re never going to end that digital transformation. But when I’m trying to drive change, often I end up having to do a reset and instead do different things to get the little seeds of change to flower and grow with at the doer level in the teams.

That’s brilliant. So essentially I think I’m gonna have to start wrapping up,not that I think we couldn’t carry on for a few hours. This is through necessity not through desire, but we started talking about a product mindset, [then] moved on to talking about that kind of leadership approach and then we somehow segued into digital transformation approaches and what’s going to make a real difference to the organization from a groundswell perspective.

So if you were talking to an organization now and you want to kick off some of these conversations and you want to enable some of that stuff to happen, what would be the first things that you advise? How would you start that conversation?

Well I think if it’s… let’s just pretend it’s an organization that is in a traditional industry with a long standing IT function serving the business. Start by asking if I can, the CEO or senior leadership, do you think that you are on a path to becoming… to where software creation is central to your business? And do you want to learn how to get on that path?

It’s one of those questions because they might say, “sure,” and then you’d go out, wouldn’t you?

Well then you start to unpack and then you start to say “OK well you know, what are the practices that the companies in the world that are most successful at delivering software, engage in? What’s the culture of those companies?” and then ”Do you have a part of your business that is maybe most greenfield, maybe you’re starting up a new digital service to replace a very human driven service? And can you staff that with a mix of people who come out of some of these organizations that are natively digital companies and can you cross pollinate that with the people that you find in your organization who are most excited about trying a new way?”

So can you start and get success with a few fresh pockets and learn how to do it, and figure out what are some of the core tools? Obviously, CICD is amongst them but tools like observability, and what does your tech stack look like and figure that out, figure out what is your day to day Agile process? What does DevOps mean? Are you really getting engineers to own production? And with continuous delivery the output of that?

How does the rest of the organization respond and start learning by doing and again get people in that can help coach you? Start but don’t bring in brand new teams from outside because the ultimate goal is that your teams and people transform and learn this new way, so you don’t lose what you have.

Excellent. Well, I’m gonna wrap up here. Thank you so much, Christina. [That was] Christina Noren who is CPO at CloudBees and that’s been highly informative. I know I would say I’ve learned a lot. That whole product mindset starting point has really influenced my thinking today. So thank you so much for that and thanks for joining me.

Ingram Micro’s Cloud Strategy: An Overview

Ingram Micro—one of the world’s largest technology distributors—has made cloud services a central pillar of its growth strategy. The company supplies a broad catalogue of products and services, from laptops and smartphones to IT infrastructure, serving customers across retail, telecommunications, and the value-added reseller (VAR) channel. Within that broad portfolio, its Cloud division has become one of its fastest-growing business units.

“As customers transform their businesses and start to adopt more cloud services, their dependence on the IT channel for guidance has become increasingly critical to their success,” said Greg Onoprijenko, Director of Cloud for Ingram Micro Canada. “This increase in demand has resulted in revenue growth as we develop more solutions in the portfolio and add a larger staff to support the demand.”

Three Business Units Driving Cloud Growth

Ingram Micro’s Cloud operations are organised into three distinct business units, each targeting a specific segment of enterprise technology needs:

• Microsoft Team: Focused primarily on Office 365 licensing models and associated Microsoft productivity services.
• Software-as-a-Service (SaaS) Team: Covers cloud security, backup and recovery, and communications and collaboration platforms.
• Infrastructure-as-a-Service (IaaS) Team: Dedicated to data centre transformation and public cloud infrastructure. The portfolio includes Microsoft Azure, Amazon Web Services (AWS), and IBM Cloud.

“The IaaS team is completely focused on data centre transformation and public cloud infrastructure,” Onoprijenko explained. This three-unit structure allows Ingram Micro to address the full spectrum of a partner’s cloud journey—from productivity tools to heavy infrastructure workloads.

A Globally Distributed Cloud Team

Onoprijenko identified the depth and breadth of Ingram Micro’s cloud workforce as a key competitive differentiator. According to his 2019 statements, the company employed over 1,500 dedicated cloud professionals globally. This team is available to channel partners who need technical guidance, strategic advice, or hands-on support as they migrate workloads or build cloud practices.

“One of the competitive advantages we have in the Cloud division is just the sheer breadth and depth of the team. We have over 1,500 dedicated cloud employees globally, with extensive industry experience,” Onoprijenko commented. “For our customers and channel partners who need guidance and advice, we have the industry’s best team to lean on.”

Internally, Ingram Micro’s Cloud team also provides ongoing education to align the broader organisation with its cloud-first direction—addressing the change management challenges that accompany any large-scale business model transformation.

Automated Platform for Channel Partners

Beyond personnel, Ingram Micro has invested in a purpose-built, fully automated platform designed to streamline cloud service transactions for channel partners. The platform provides centralised dashboards, reporting capabilities, and integrated support—removing friction from the process of reselling and managing cloud services.

“The platform covers any need that a partner may have when delivering cloud services,” Onoprijenko said. “As channel partners become mature and more successful in the cloud, they recognise that automation is critical to scale their businesses and that they need to have their eCommerce platform to transact cloud services. Our global cloud service offerings make us a logical option for these companies.”

This platform approach is particularly important as partners move from occasional cloud transactions to managing recurring, subscription-based revenue streams at scale.

The Shift to Everything-as-a-Service

A fundamental change in how technology is consumed is reshaping the distributor and channel landscape. Customers are moving away from purchasing and owning IT assets outright, toward subscription and pay-as-you-go models where software and infrastructure are accessed as monthly services hosted in the cloud.

“Instead of customers buying and owning IT products, the evolution is towards everything-as-a-monthly-fee,” Onoprijenko explained. “That puts pressure on the IT channel partners to evolve and change to meet customer demands. It also puts pressure on IT distributors to change how they deliver solutions to the market.”

Traditional software licensing—where a customer purchases a perpetual licence and pays annual maintenance—is one of the clearest examples of this shift. Today, many of those same customers are moving to subscription-based SaaS alternatives, eliminating the upfront capital expenditure and ongoing maintenance overhead.

Enabling Channel Partners Through Education and Coaching

Not all channel partners are moving at the same pace. Onoprijenko acknowledged a spectrum of readiness—from partners actively transforming their business models to those who remain resistant to change and risk losing relevance.

To help partners navigate this transition, Ingram Micro offers:

• Seminars and workshops covering cloud strategy and technology adoption
• Educational programmes designed to build cloud competency within partner organisations
• One-on-one coaching for partners who need more tailored guidance

“We can surround our clients with resources which can guide them along and motivate them to change proactively,” Onoprijenko added. This wraparound support model is intended to lower the barrier to cloud adoption for partners who lack in-house expertise.

Ingram Micro’s Own Internal Cloud Transformation

Ingram Micro is not just advising others on cloud transformation—it has undertaken the same journey internally. The company migrated its own workforce from self-hosted email and productivity tools to Microsoft Office 365, and standardised on Microsoft Dynamics CRM rather than running its own CRM infrastructure. These moves reduced the operational burden of managing large on-premises data centres.

“We’re changing our business model and evolving to the cloud. We previously had large data centres with IT infrastructure that serviced the entire company,” Onoprijenko noted. This internal experience also strengthens the company’s credibility when advising customers on similar transformations.

Early Mover Advantage in Cloud Distribution

Onoprijenko argued that Ingram Micro’s most durable advantage is not simply its current scale, but its early commitment to cloud services. According to his 2019 remarks, Ingram Micro began delivering cloud services approximately 12 years prior—placing the start of that investment around 2007, well before cloud adoption became mainstream in the enterprise channel.

“Everybody understands the opportunity and is pursuing it. Ingram Micro envisioned this opportunity before our competitors and started delivering cloud services about 12 years ago. We certainly invested early,” he said.

That early investment translates into mature tooling, established vendor relationships, and a workforce with deep cloud expertise—assets that newer entrants to the cloud distribution market must build from scratch.

Key Takeaways for DevOps and IT Channel Professionals

• Large technology distributors like Ingram Micro are actively reshaping their role—from product fulfilment to cloud advisory and managed services enablement.
• Automation platforms that support billing, provisioning, reporting, and support are becoming a baseline requirement for cloud distributors.
• Channel partners who delay their cloud transformation risk losing customers to more cloud-native competitors.
• The shift to subscription and pay-as-you-go models changes cash flow dynamics for both vendors and resellers—a practical consideration for any organisation designing its go-to-market strategy.
• Internal cloud adoption by distributors strengthens credibility and generates genuine operational experience to share with customers.

This accelerated cadence lets organisations adapt to market shifts, respond to user feedback faster, and keep pace with competitors. Most importantly, it enables businesses to continuously deliver value to the people who use their products. The mechanism that makes this possible at scale is DevOps.

The Hidden Enemy: Wasted Time Between Phases

Ask most engineers which phase of the software development life cycle (SDLC) takes the longest, and they will name development, testing, or deployment. The honest answer is none of those. The greatest time sink is not inside any single phase — it is the gaps between phases.

• Developers wait on business analysts to deliver requirements.
• Testers wait on developers to finish code.
• Developers wait on testers to confirm whether the code works.
• Everyone waits on system administrators to provision environments or push releases.
• Sysadmins wait on everyone else to diagnose why a deployment failed.

In many organisations, a substantial portion of engineering effort goes into activities that produce no direct value for the customer. Waiting in queues delivers nothing. Manually re-running the same regression suite for every release delivers nothing new. Submitting a ticket to a separate deployment team when the application team could run a single command themselves delivers nothing that justifies the overhead. Yet all three practices are commonplace.

DevOps directly addresses this problem by compressing or eliminating idle time through automation and by collapsing the handoff points that create queues in the first place.

Breaking Down Silos: DevOps as a Cultural Shift

In a traditionally structured organisation, the answer to “who is responsible for this product?” is usually “nobody in particular.” Every department owns a slice — development, QA, operations, security — but no single team is accountable end-to-end. This fragmentation has predictable consequences:

• Developers may not know how their application is tested or deployed, and may not consider those concerns when writing code.
• Sysadmins may be unaware of how much friction their ticketing process creates for developers trying to ship code.
• QA teams may be disconnected from production monitoring, missing signals that would inform their test strategies.

No single team sees the complete life cycle of an application. Because responsibility is partitioned, empathy between teams erodes. Communication becomes transactional — a Jira ticket here, an email there — rather than collaborative.

DevOps tackles this disconnect head-on. Its core premise is cultural: unite the people involved in an application’s life cycle into a single, autonomous team that owns everything from requirements and development through testing, deployment, monitoring, and on-call response. When one team holds end-to-end accountability, several things change:

• Handoffs disappear. There is no separate department to hand a release to, so inefficient escalations are eliminated.
• Empathy grows. When developers are also on the pager when something breaks at 2 a.m., they write more resilient code. When testers pair with developers during feature work, defects are caught earlier.
• Ownership is clear. A single product owner for the team means priorities are aligned rather than negotiated across departmental boundaries.

What DevOps Is Not

A common misunderstanding is that DevOps means creating a new department labelled “DevOps” or hiring a set of engineers with “DevOps” in their job titles. This approach reproduces the very silo it claims to dissolve. A DevOps team sitting alongside separate development and operations teams still generates the same handoff friction — it just has a different name on the door.

DevOps is not a role, a tool, or an organisational layer. It is a set of cultural and engineering practices that allow cross-functional teams to own the full life cycle of the software they build. Tooling — CI/CD pipelines, infrastructure as code, automated testing, observability platforms — is essential, but it is in service of the cultural goal, not the goal itself.

Automation: Reclaiming Time for Work That Matters

Eliminating idle time and automating repetitive tasks does more than speed things up — it frees cognitive bandwidth. When engineers are not manually shepherding deployments or babysitting regression suites, they can direct that attention toward solving real problems and building new capabilities.

Key automation practices that underpin a DevOps approach include:

• Continuous Integration (CI): Automatically build and test every code change as it is committed, catching regressions within minutes rather than days.
• Continuous Delivery/Deployment (CD): Automate the path from a passing build to a production release, making deployments repeatable and low-risk.
• Infrastructure as Code (IaC): Define and provision environments programmatically, eliminating manual configuration and environment drift.
• Automated Testing: Replace repetitive manual test cycles with comprehensive automated suites that run on every change.
• Observability: Instrument applications for logging, metrics, and tracing so teams can detect and respond to issues without waiting for user reports.

The Three Ingredients for Continuous Customer Value

Taken together, the DevOps approach produces three compounding advantages:

1. Elimination of wasted time and resources. Automating repetitive tasks and removing unnecessary handoffs returns engineering hours to work that directly benefits the customer.
2. Improved collaboration. Cross-functional teams with shared accountability build better software because every member understands the downstream consequences of their decisions.
3. Decentralised innovation. When teams are empowered to own their full stack, experimentation happens closer to the problem. Good ideas do not have to travel through layers of management to reach production.

These three factors shift an organisation from a reactive posture — trying to keep up with competitors — to a proactive one, where teams have the capacity and confidence to tackle today’s challenges and anticipate tomorrow’s.

Summary

DevOps is fundamentally about reducing the distance between an idea and its delivery to the customer. It does this by eliminating the idle time that accumulates between SDLC phases, dismantling the organisational silos that create those gaps, and automating the repetitive work that consumes engineering capacity without producing customer value. When the cultural and technical foundations are in place, teams ship faster, systems are more reliable, and businesses can focus their energy on genuine innovation rather than internal coordination.

Original source: cloudcomputing-news.net (2019)

Overview

Red Hat released Ansible Engine 2.6 on July 17, 2018, delivering a range of enhancements focused on hybrid and multicloud automation, expanded network device support, deeper VMware integration, and an upgraded Ansible Galaxy community repository. The release continued Red Hat’s investment in Ansible since its acquisition of the project in October 2015.

Multicloud Automation Improvements

A central theme of Ansible Engine 2.6 is making it easier to automate workloads that span multiple cloud providers. According to Justin Nemmers, General Manager of Ansible at Red Hat:

“One of the highlights is the ability to pull native facts from additional AWS and Azure cloud services.”

Prior to 2.6, gathering facts from services such as AWS RDS instances or Azure generic resources was possible but required additional manual steps from the operator. Ansible Engine 2.6 streamlines this process with new modules that retrieve cloud-native facts directly, reducing the amount of custom scripting required in multicloud playbooks.

Expanded VMware Support

Ansible Engine 2.6 extended its VMware hypervisor and cloud environment support significantly. Between the 2.5 and 2.6 releases, Red Hat added 26 modules specifically targeting VMware infrastructure automation. These modules cover:

• Tag management and fact gathering for VMware resources
• Deployment and lifecycle management of virtual machines
• Network and configuration management within VMware-based environments
• Seamless automation of VMware Cloud on AWS, enabling teams to manage both on-premises and cloud infrastructure from a single Ansible workflow

The addition of these modules reflects a growing customer need to treat on-premises VMware infrastructure and public cloud resources as a single, unified automation target rather than managing them through separate toolchains.

Network Automation

Network automation remains a core pillar of the Ansible platform. Ansible Engine 2.6 includes vendor-agnostic modules and supported integrations for the following networking platforms:

• Arista – EOS
• Cisco – IOS, IOS XR, NX-OS
• Juniper – JunOS
• Open vSwitch
• VyOS

These integrations use a common language for network control, allowing teams to write playbooks that work consistently across heterogeneous network environments. Red Hat also introduced a role-based approach to network automation, enabling the distribution of Ansible Roles that address specific network use cases in a vendor-agnostic way.

An Ansible Role is a structured, portable Playbook format that makes reusable automation content easier to share and apply across different environments. Nemmers described the full network automation stack as:

“The Ansible Network Automation offering includes Ansible Tower and Ansible Engine, providing customers everything they need to automate their network environments at scale.”

In this model, Ansible Engine handles the execution of automation tasks directly against network devices, while Ansible Tower provides the management layer — including role-based access control, scheduling, and audit logging — needed to scale network automation across a large IT organization.

Ansible Galaxy 3.0

Alongside the Engine 2.6 release, Red Hat shipped Ansible Galaxy 3.0. Ansible Galaxy is the public-facing repository where community members and Red Hat partners publish Ansible Roles for others to consume and reuse.

Key changes in Galaxy 3.0 included:

• Improved user interface – A redesigned front end to make browsing and discovering Roles more intuitive
• Modernized code base – Internal refactoring to improve maintainability and performance
• Containerized infrastructure – The Galaxy platform itself was migrated to run on Red Hat OpenShift Dedicated
• OpenShift Ansible Broker support – New capability to define and distribute multi-container services on Red Hat OpenShift Dedicated using Ansible Automation

The OpenShift Ansible Broker integration allows platform teams to package complex, multi-container application deployments as Ansible content and make them available through Galaxy, further connecting the automation and container orchestration ecosystems.

Windows Environment Support

Ansible Engine 2.6 also included improvements to Microsoft Windows support. While the original source material does not enumerate specific Windows modules added in this release, Windows environment support was cited as one of the areas receiving focused attention in the 2.6 update, reflecting the heterogeneous nature of enterprise IT estates that Ansible targets.

What This Means for DevOps Teams

Ansible Engine 2.6 addresses several practical pain points for DevOps and infrastructure teams operating in modern hybrid environments:

• Reduced glue code – Native cloud fact-gathering modules eliminate custom scripts previously needed to collect resource information from AWS and Azure.
• Unified VMware and cloud management – The 26 new VMware modules allow a single automation workflow to span on-premises vSphere and VMware Cloud on AWS.
• Vendor-agnostic network automation – A common module language across Arista, Cisco, Juniper and open-source networking platforms reduces the need for platform-specific tooling.
• Improved content sharing – Galaxy 3.0 makes it easier for teams to discover, publish and consume reusable Ansible Roles, accelerating automation adoption across an organization.

Nemmers summarized the broader vision: “Ansible is more than just a really great automation platform. It’s a killer IT productivity tool — and one that can help IT orgs drive their organizational culture in open, collaborative and otherwise positive ways, which really is a must in order to succeed with their digital transformation initiatives.”

DevOps Is a Cultural Shift, Not Just a Technology Choice

A common misconception is that adopting DevOps is primarily a technical decision: deploy a pipeline, introduce containers, automate testing, and the transformation is complete. In practice, the tooling is the easier part. The harder — and more consequential — work is changing how development, operations, security, and business teams communicate, share responsibility, and make decisions together.

This is why organizational readiness must be assessed before committing to a DevOps roadmap. Understanding the current state of your culture, processes, and leadership alignment will surface the real obstacles to adoption and help you sequence the transformation more effectively.

Three Questions to Assess DevOps Readiness

Before designing a DevOps implementation plan, leadership teams should work through three foundational questions. Answering them honestly will expose gaps and guide prioritization.

1. Is There Genuine Management-to-Team Alignment?

DevOps cannot be mandated by leadership and ignored in practice, nor can it emerge organically from engineering teams without executive support. Sustainable adoption requires both. Leadership must articulate a clear vision for why DevOps matters to the business — improved deployment frequency, faster incident recovery, higher product quality — and actively model the collaborative behaviors they expect from teams.

Equally important is that individual contributors, team leads, and middle managers understand the rationale and feel empowered to participate in shaping the change. When both layers are aligned, the organization has already overcome one of the biggest barriers to DevOps adoption: organizational resistance.

Signs of readiness at this level include visible executive sponsorship, budget allocated to DevOps initiatives, and teams that are actively involved in defining their own workflows rather than having processes imposed on them.

2. Is There a Concrete, Documented Strategy?

Enthusiasm for DevOps without a structured plan is a common failure pattern. Organizations that jump directly to tool selection — evaluating Jenkins versus GitHub Actions, or Ansible versus Terraform — before defining their goals and process flows often end up with disconnected automation that creates new complexity rather than reducing it.

A solid DevOps strategy should address at minimum:

• Goals and success metrics: What outcomes are you targeting? Deployment frequency, mean time to recovery (MTTR), change failure rate, and lead time for changes are widely used indicators.
• Current process mapping: Where do handoffs between teams introduce delays or errors today? Value stream mapping is a useful technique here.
• Tool selection aligned to process: Tools should be chosen to support documented workflows, not the other way around.
• Training and knowledge transfer: Development and operations teams often have distinct skill sets and assumptions. A plan for cross-functional learning helps bridge those gaps before they become friction points.
• Governance and compliance considerations: Especially in regulated industries, security, audit, and change management requirements must be incorporated into the DevOps model from the start.

Without this foundation, teams risk implementing automation that accelerates broken processes — a faster path to the wrong destination.

3. Is the Organization Prepared to Start Small and Iterate?

Even with strong leadership alignment and a solid strategy, organizations that attempt a full-scale DevOps transformation across all teams and products simultaneously tend to encounter overwhelming change fatigue and coordination problems. A more effective approach is to start with a pilot: a single team, a single service, or a single delivery pipeline.

A well-scoped pilot allows teams to:

• Validate assumptions about tooling and process before rolling out broadly.
• Identify cultural and technical obstacles in a controlled context.
• Build internal expertise and create advocates who can support adoption in other teams.
• Demonstrate measurable results to stakeholders, which builds confidence and continued investment.

The pilot results — both successes and failures — become the evidence base for refining the broader DevOps strategy before scaling. This iterative approach reduces risk and produces a more resilient organizational transformation over time.

Common Readiness Gaps to Watch For

Organizations conducting a readiness assessment frequently encounter the same categories of gaps. Being aware of them in advance helps prevent them from derailing adoption:

• Siloed team structures: When development and operations teams report to different leadership chains with conflicting incentives (ship fast vs. maintain stability), collaboration is structurally difficult. DevOps adoption often requires organizational redesign, not just new tooling.
• Lack of shared metrics: Teams that measure success differently will optimize for different outcomes. Agreeing on shared KPIs before implementation creates a common language for progress.
• Underestimating skill gaps: Effective DevOps practice requires skills that may not exist in current teams — infrastructure as code, security integration, observability engineering. Honest skills assessment and a training plan are essential.
• Neglecting psychological safety: DevOps depends on teams feeling safe enough to surface problems, admit failures, and experiment. Organizations with blame cultures will find DevOps practices superficially adopted but never genuinely effective.

Moving Forward After the Assessment

An organizational readiness assessment is not a one-time gate; it is a recurring checkpoint as your DevOps maturity evolves. The output should be a prioritized list of actions: cultural interventions, structural changes, skill development programs, and pilot project scopes.

Organizations that invest time in this diagnostic work before selecting tools and writing pipeline configurations consistently report smoother adoptions, faster time-to-value, and more durable cultural change. Those that skip it often find themselves revisiting the same problems — poor collaboration, deployment bottlenecks, incident response failures — after significant investment in automation infrastructure.

DevOps is not a destination that an organization reaches once. It is a continuous improvement practice, and readiness assessment is how you ensure that improvement is grounded in your organization’s actual context — not an idealized model borrowed wholesale from another company’s case study.

Key Takeaways

• Treat DevOps as a cultural and organizational transformation, not only a technical one.
• Confirm management-to-team alignment before committing to implementation.
• Build a strategy with defined goals, process maps, tool rationale, and training plans.
• Pilot DevOps practices in a limited scope before scaling across the organization.
• Use readiness assessments as a recurring practice, not a one-time pre-launch checklist.

We often talk about how DevOps and automation can help speed up release cycles and get the latest code changes and updates out in a quick, stable and efficient way. This DevOps mindset keeps developers and operations teams in sync and ensures that the software they produce is always on the cutting edge. But is this all too much?

With a continual focus on trimming the release cycle time and automating this process, do DevOps organizations put enough focus on the application itself? The DevOps mindset has fostered a more aggressive schedule of change. Is it always for the right reason? While this level of agility and change is often shown as a positive aspect for business, any change — large or small — affects customers.

When you make a change to your application, the customer may need to internally test and validate the app before it’s deployed into production. In fact, that is normally the case with production-level software. If the application in question is updated monthly or quarterly, that can be a serious drain on your customers’ resources for these internal processes. This is a piece of the puzzle can get missed in the DevOps mindset.

The Hidden Cost of High-Velocity Releases

Every time your team ships a change, your customers bear a cost. Production software doesn’t exist in a vacuum. Enterprises that depend on your application typically have their own change-management processes: internal regression testing, compliance reviews, staged rollouts, and sign-off procedures. A change that takes your team an afternoon to ship may require days of validation effort on the customer’s side.

If your team releases updates monthly or even weekly, that overhead compounds quickly. Customers may struggle to keep up, skip validations to save time, or grow frustrated with the constant churn. None of those outcomes serve the business goals DevOps is supposed to advance.

The key question every DevOps team should ask before shipping is not can we release this? but should we release this now, and are our customers ready for it?

Orient Your DevOps Mindset Around the User

High-velocity CI/CD pipelines are engineered to reduce friction for the development and operations teams. That’s genuinely valuable. But those pipelines accelerate the release process, not the adoption process. Automation helps your team get code out the door faster; it doesn’t automatically help your customers absorb, test, and deploy that code in their own environments.

Change for the sake of change imposes a real tax on customers. A stream of small, low-impact updates may keep developers busy and dashboards green, but if those updates don’t meaningfully improve the user experience, the net effect is churn without value. Frequent, minor changes accumulate into upgrade fatigue.

This is not an argument for returning to monolithic, infrequent releases. Waterfall-style delivery cycles have well-documented drawbacks: large batches increase risk, delays reduce responsiveness, and big-bang deployments are harder to roll back. The goal is deliberate cadence, not slowness.

Define and Publish a Predictable Release Cadence

One of the clearest signals that a DevOps organization has lost its customer focus is the absence of a defined release schedule. Shipping whenever a feature is ready — or whenever the pipeline goes green — makes it impossible for customers to plan. If your release cadence is unpredictable or undocumented, that is a serious process gap.

A well-managed release cadence should be:

• Predictable: Customers should know in advance when to expect updates so they can schedule their own validation work.
• Documented: Release notes, changelogs, and migration guides give customers the information they need to assess impact.
• Risk-categorized: Distinguish between patch-level bug fixes, minor feature additions, and breaking changes. Not every update warrants the same customer response.
• Communicated early: Advance notice — especially for changes that affect APIs, data schemas, or integrations — lets customers prepare rather than react.

Communicate Software Changes Clearly

Production systems fail in unexpected ways. The assumption that a minor change is safe has preceded many significant outages in the software industry. A small configuration tweak, a dependency version bump, or a subtle behavior change in a shared library can cascade into a major incident in a complex production environment. This doesn’t mean teams should be paralyzed by caution, but it does mean every change deserves deliberate communication.

Clear communication requires effort and time. It can’t happen effectively when changes are arriving faster than your team can document and explain them. If your release velocity prevents you from writing meaningful release notes or notifying customers of upcoming changes, that’s a signal to slow down and recalibrate.

Practical communication practices for DevOps teams include:

• Maintaining a public or customer-facing changelog with each release.
• Sending advance notifications for changes that affect integrations or workflows.
• Providing a deprecation timeline for features or APIs being retired.
• Offering a way for customers to opt into early releases or preview environments.
• Keeping a known-issues register that is updated alongside each release.

Finding the Right Balance

DevOps is ultimately about delivering value to users reliably and sustainably. Speed is an enabler of that goal, not the goal itself. A team that releases continuously but leaves customers overwhelmed, under-informed, or perpetually fire-fighting has optimized the wrong metric.

The right balance depends on your product, your customers, and the nature of the changes you’re shipping. Some SaaS products can sustain daily deployments because they control the end-user environment entirely. Others — particularly those integrated deeply into enterprise workflows — may need a more measured cadence with stronger communication support.

The discipline is in asking the question honestly: are we releasing at this pace because it genuinely serves our users, or because it’s what our pipeline makes easy? A mature DevOps mindset holds both technical efficiency and customer impact in view at the same time.

Slow down when the situation calls for it. Communicate proactively. Measure success by outcomes for users, not just throughput from the pipeline. That’s what a customer-centered DevOps practice looks like.

Partnership Overview

Agile Stacks announced its entry into the CloudBees Elevate Partner Program, a channel initiative designed to extend CloudBees’ enterprise DevOps capabilities through complementary technology and services partners. The partnership pairs CloudBees’ enterprise-grade continuous delivery platform — built on Jenkins — with Agile Stacks’ GitOps automation service, which is aimed at dramatically reducing the time and cost required to stand up production-ready DevOps environments in the cloud.

What Each Company Brings to the Table

CloudBees: Enterprise Jenkins and Continuous Delivery

CloudBees is built on top of Jenkins, one of the most widely used open-source automation servers in the DevOps ecosystem. CloudBees adds enterprise-critical capabilities on top of the upstream Jenkins project:

• Security and compliance controls for regulated industries
• Scalability to support large numbers of development teams and concurrent builds
• Centralized management of Jenkins masters across an organization
• Expert support backed by a dedicated customer success team

CloudBees also supports running Jenkins workloads on Kubernetes, enabling dynamic, containerized build agents that scale on demand — a critical requirement for organizations with variable CI/CD workloads.

Agile Stacks: GitOps Automation and DevOps Cloud Stacks

Agile Stacks describes its platform as a “non-opinionated” GitOps automation service — meaning it does not lock customers into a specific toolchain. Instead, it provides a framework for deploying full-function DevOps cloud stacks composed of pre-tested, integrated open-source tools. Key claims from the company include:

• Deployment of complete DevOps stacks within minutes, compared to typical enterprise rollout timelines that can stretch from six months to two years
• Application Templates that automatically create CI/CD pipelines binding development, test, and production environments to stacks
• A DevOps-first architecture delivered out of the box, reducing the custom integration work traditionally required

How the Integration Works

The combined offering targets enterprise teams that want to run CloudBees Jenkins at scale on Kubernetes without spending months on infrastructure setup. The integration works as follows:

1. An organization uses Agile Stacks Application Templates to provision a full DevOps cloud stack — including networking, storage, security, and tooling — on their chosen cloud provider.
2. CloudBees Jenkins is included within that stack, pre-configured with enterprise-grade settings rather than requiring manual setup.
3. Pipeline configuration is automated by Agile Stacks, linking source repositories, build environments, and deployment targets without requiring hand-crafted Jenkinsfiles from scratch.
4. Teams can scale builds horizontally across Kubernetes worker nodes, using the elastic compute capacity of their cloud provider.

Business Goals of the Partnership

Beyond the technical integration, the partnership involves joint go-to-market activities:

• Joint sales motions targeting enterprise accounts looking to accelerate DevOps adoption
• Co-marketing initiatives focused on educating organizations about GitOps practices and cloud resource management
• A shared emphasis on reducing operational expenditure by automating infrastructure provisioning and pipeline management

Industry Context: Why This Partnership Matters

By 2018, Kubernetes had become the dominant container orchestration platform, but running stateful enterprise tools like Jenkins reliably on Kubernetes remained a significant operational challenge for many teams. Separately, GitOps — the practice of using Git as the single source of truth for infrastructure and application state — was gaining traction as a way to apply software engineering discipline to infrastructure management.

Partnerships like this one reflected an emerging pattern: specialist automation vendors wrapping and extending core DevOps platforms (Jenkins, in this case) to lower the barrier of entry for enterprises that lacked the in-house expertise to build and maintain complex CI/CD infrastructure from scratch.

Quotes from Both Companies

“We empower enterprises in today’s global digital economy to innovate and adapt rapidly using our Agile Stacks automated agile software delivery service, which significantly streamlines the deployment and update management of the many tools they rely on. We are excited to partner with CloudBees in delivering enterprise Jenkins, the DevOps and continuous delivery solution of choice for many enterprises, with our service.”

— John Morada, Vice President of Global Business Development, Agile Stacks

“We pride ourselves on providing enterprise-grade continuous delivery functionality to DevOps teams and then complementing that with companies, such as Agile Stacks, to enable the success of non-opinionated enterprise-grade open source technologies. Working together, we are addressing our customers’ growing demand to run our platform on Kubernetes, while cost-effectively providing the security and compliance, flexibility, and scale capabilities they need to drive their businesses.”

— Aaron Morrison, Director of Worldwide Channel Sales, CloudBees

About Agile Stacks

Agile Stacks provides an all-in-one, non-opinionated GitOps automation service aimed at enterprises building cloud-native platforms. Its stacks incorporate pre-tested, integrated open-source tools that are ready to use from the moment they are deployed, targeting the performance, agility, and scalability requirements of modern digital businesses.

Overview

Red Hat made Ansible Engine 2.6 generally available on July 17, 2018. The release focuses on three areas: deeper multicloud and hybrid cloud automation, expanded network automation with vendor-agnostic modules, and a major refresh of the Ansible Galaxy community content hub. Together these changes aim to reduce the manual overhead involved in managing infrastructure spread across on-premises data centers, AWS, Azure, and VMware-based clouds.

Red Hat acquired Ansible in October 2015 and has continued to ship regular Engine releases since then, progressively broadening the platform’s integration surface.

Multicloud and Hybrid Cloud Enhancements

A headline change in 2.6 is the ability to pull native facts directly from a wider set of AWS and Azure cloud services. Previous releases could interact with services such as AWS RDS or Azure generic resources, but doing so required users to write extra tasks to collect and normalise the returned data. Ansible Engine 2.6 surfaces this information through dedicated fact modules, reducing playbook complexity.

According to Justin Nemmers, General Manager of Ansible at Red Hat:

“One of the highlights is the ability to pull native facts from additional AWS and Azure cloud services.”

VMware Support

Ansible Engine 2.6 also deepens VMware integration. Between the 2.5 and 2.6 releases, Red Hat added 26 new VMware modules covering areas such as:

• Tag management and fact gathering for VMware objects
• Deployment and lifecycle management of virtual machines
• Network and configuration management within VMware-based infrastructure
• Seamless automation of VMware Cloud on AWS, allowing teams to manage both on-premises vSphere and cloud-hosted VMware infrastructure from a single set of playbooks

This is particularly relevant for organisations running hybrid environments where workloads span on-premises VMware clusters and public cloud services simultaneously.

Network Automation

Network automation has become a core pillar of the Ansible platform. Engine 2.6 ships supported integrations with the following vendors and operating systems:

• Arista – EOS
• Cisco – IOS, IOS XR, NX-OS
• Juniper – JunOS
• Open vSwitch
• VyOS

These integrations are delivered through vendor-agnostic modules that share a common declarative language. Rather than requiring engineers to learn device-specific CLI syntax for each vendor, teams can write playbooks that express the desired network state in consistent terms.

Red Hat has also introduced a Role-based distribution model for network automation content. An Ansible Role is a structured, portable Playbook that packages tasks, variables, handlers, and templates in a reusable format. By publishing vendor-specific network Roles, Red Hat and its partners can address common customer use cases without locking users into proprietary tooling.

The full Ansible Network Automation offering combines Ansible Engine with Ansible Tower. Engine performs the actual automation work against devices; Tower provides the scheduling, RBAC, audit logging, and API surface needed to scale that automation across an IT organisation.

Ansible Galaxy 3.0

Concurrent with the Engine 2.6 release, Red Hat shipped Ansible Galaxy 3.0. Galaxy is the public repository where the Ansible community and Red Hat partners publish reusable Roles. Key changes in version 3.0 include:

• Improved user interface – a modernised browsing and search experience for discovering community content
• Modernised code base – internal refactoring to improve performance and maintainability of the Galaxy service itself
• Containerised infrastructure – Galaxy 3.0 runs on Red Hat OpenShift Dedicated, replacing the previous hosting model
• OpenShift Ansible Broker support – Galaxy 3.0 can host and distribute Ansible Service Broker content, enabling teams to define and provision multi-container services on Red Hat OpenShift Dedicated using Ansible automation

Roles remain the preferred unit of sharing Ansible content between teams precisely because of their portability: a Role developed against one environment can be consumed in another with minimal modification.

Windows Environment Support

The original reporting notes that Red Hat also boosted support for Microsoft Windows environments in Engine 2.6, though specific module additions or WinRM improvements were not detailed in the source material. Windows has been a supported Ansible target since the 1.x era, with management performed over WinRM rather than SSH.

What This Means for DevOps Teams

Ansible Engine 2.6 consolidates several trends that were already visible in the 2.x series: broader cloud coverage, more out-of-the-box network vendor support, and a richer content-sharing ecosystem. Practically speaking, teams working across mixed AWS, Azure, and VMware environments should find fewer gaps that require custom scripting to fill, and network engineers gain a more consistent abstraction layer across major switch and router vendors.

For organisations evaluating whether to standardise on Ansible for infrastructure automation, the Galaxy 3.0 content ecosystem reduces the time needed to reach a working baseline configuration for common platforms, since community and partner Roles can be consumed directly rather than built from scratch.

Key Takeaways

• Ansible Engine 2.6 became generally available on 17 July 2018.
• Native fact gathering is now simpler for AWS and Azure services such as RDS and Azure generic resources.
• 26 new VMware modules were added between Engine 2.5 and 2.6, covering VMs, networks, tags, and facts.
• Network automation modules cover Arista EOS, Cisco IOS/IOS XR/NX-OS, Juniper JunOS, Open vSwitch, and VyOS.
• Ansible Galaxy 3.0 ships alongside Engine 2.6 with a new UI, modernised codebase, and OpenShift-hosted infrastructure.
• Galaxy 3.0 adds Ansible Service Broker content support for multi-container OpenShift service provisioning.

Source: eWeek reporting, July 2018.

The reason for this imbalance lies in DevOps’ origin story. The narrative centers on developer frustration with risk-averse operations procedures that prevented rapid, frequent deployments. There is truth in that account, but it is more complicated than the myth suggests. Operations professionals are risk-averse for good reason: when things go wrong in production, Ops bears highly visible, public blame with little safety net.

That said, a reasonable aversion to risk can be taken too far. Combine it with a professional identity built around individual servers and manual procedures, and you get people becoming bottlenecks for huge processes—reaching for the keyboard for tasks that should long since have been automated away.

What Does DevOps Actually Mean for Ops?

The most significant benefit DevOps has delivered to operations teams is forcing a hard conversation about moving from artisanal, handcrafted IT infrastructure to industrial, scalable models that do not require a human in the loop for routine tasks. This cultural shift was crystallised in the well-known pets versus cattle analogy—treating servers as interchangeable units rather than irreplaceable individuals—but the transition is far from complete.

There is still a meaningful gap between the rhetoric of software-defined infrastructure and desired-state automation and practical, day-to-day operational uptake of those frameworks. Filling that gap requires a genuine transition away from traditional Ops models, with pervasive, intelligent automation augmenting—rather than replacing—the capabilities of experienced sysadmins.

This is not the automation of cron jobs and shell scripts, which experienced sysadmins have used for decades. Modern serverless and cloud-native frameworks remove the persistent coupling of infrastructure components to individual business services. Workloads now move, grow, and shrink in response to user demand, and infrastructure reconfigures itself top to bottom automatically. The promise of dynamic resource management that earlier virtualisation technologies hinted at is now becoming operational reality.

Why “Set It and Forget It” Automation No Longer Works

In a dynamic, cloud-native environment, operational automation can no longer operate on a static “set it and forget it” model. Every automated process needs real-time contextual awareness of its surroundings and how they are constantly changing. Without that visibility, you get situations like:

• Backup scripts faithfully backing up a server that has become a peripheral part of the application infrastructure, while the cloud services running the bulk of application logic are not meaningfully integrated into the disaster recovery plan.
• OS patching pipelines running against ephemeral instances whose average lifespan is shorter than the patch cycle—work that could be eliminated entirely by patching the base image templates instead.
• Automation that continues to run simply because no one is sure what might break if it stops—a signal that it is time for deliberate chaos engineering to find out.

To keep operational automation aligned with business reality, every automated process should be reviewed regularly across three dimensions: need, function, and ownership.

Three Questions Every Ops Team Should Ask About Their Automation

1. Who Needs This Automation?

Every piece of automation that runs should be traceable—however indirectly—to a business requirement. Useful questions to ask include:

• Does this serve a clear operational goal? “This ensures our infrastructure scales seamlessly in response to user demand” is a solid justification.
• Is the goal still valid given current architecture? “This keeps operating systems patched” is a legitimate aim, but if provisioned OS instances are replaced faster than the patch cycle, patching the base image template may be all that is needed.
• Is inertia the only reason this still runs? “We’ve always done it this way and aren’t sure what would happen if we stopped” is a prompt to run a controlled experiment—deliberately disable the process in a non-production environment and observe.

2. What Is the Function of This Automation?

The technology landscape continues to shift rapidly. Virtualisation was barely settled when cloud computing arrived; cloud computing was still maturing when containerisation accelerated; containerisation is still evolving alongside serverless architectures. Automation written for one era can carry hidden assumptions that make it fragile or redundant in the next.

Ops teams should borrow a practice from software development: refactoring. Review automation regularly to remove outdated assumptions, eliminate technical debt, and take advantage of newer capabilities. The function of a script or workflow that made sense in a bare-metal or early-virtualisation context may need to be redesigned completely for a container-native or serverless environment.

3. Who Owns This Automation?

Every piece of automation needs a named owner—someone responsible for maintaining it over time and accountable when it breaks. Developers have long discussed the concept of technical debt: the compounding cost of unmaintained code. Operational automation accumulates the same kind of debt when no one maintains it.

Historically, sysadmins took pride in the uptime of individual servers. That sense of ownership needs to migrate: from the individual server to the overall infrastructure, and to the automation and management tooling that ensures its availability and performance over time. The cattle-not-pets principle applies to the infrastructure; the ownership and craftsmanship principle applies to the automation that manages it.

Ops Is the Other DevOps

As Ops becomes increasingly about building and managing automation rather than administering individual systems, the boundary between Dev and Ops begins to dissolve. Development teams are taking on production responsibility—”picking up the pager”—while operations teams are writing progressively more sophisticated code to fulfil the infrastructure promises that applications depend on.

Traditional Ops tasks are evolving or disappearing, and new roles are emerging in their place. The role of automation architect—someone who designs, maintains, and governs the systems that keep infrastructure running—is becoming more strategically important than any role that primarily involves logging into individual servers or network devices. Operations professionals navigating this transition have a great deal to learn from the software engineering practices that developers have refined over the past decade: version control for infrastructure code, code review, testing, refactoring, and clear ownership models.

In the long run, the term “DevOps” may come to describe not developers versus non-developers, but two distinct types of software engineer: one focused on business logic and user-facing features, and one focused on the architectural foundations and automation that make reliable delivery possible at scale. Getting there requires Ops to be taken as seriously as Dev in the tools, practices, and culture that organisations build around continuous delivery.

This article is adapted from a piece originally published on DevOps.com. The original author was affiliated with Moogsoft, which at the time of writing had a strategic partnership with Microsoft.

The Afterthought Problem: Why Security and DevOps Have Always Clashed

Consider the automotive industry for a moment. Safety engineers don’t bolt airbags onto a finished car as an afterthought. They design crash protection into the vehicle from the first sketch on the drawing board. The result is a vehicle that looks seamless, feels comfortable, and meets rigorous safety standards—without the manufacturing line grinding to a halt every time a new model ships.

Application security has historically worked nothing like this. For decades, development teams built software, handed it to a security team at the end of the cycle, and waited while that team attempted to retrofit controls onto a finished product. Under the old six-month release cadence, this friction was inconvenient. Under modern continuous delivery, it is a fundamental blocker.

DevOps is engineered for constant, rapid change. Traditional security practices treat change as an inherent threat. The result is a painful trade-off: either slow down the pipeline so security can catch up, or keep shipping and ask the security team to sort things out later—possibly after a vulnerability is already in production.

DevSecOps: Embedding Security as a First-Class Citizen

The DevSecOps model addresses this by integrating security teams, tooling, and controls directly into the DevOps workflow. Rather than acting as a gate at the end of the pipeline, security functions are distributed across every phase: planning, development, testing, deployment, and operations.

When security is embedded this way, it stops being a speed bump and becomes part of the standard build process—analogous to unit tests or linting checks that run automatically on every commit.

However, team integration alone is not sufficient. One persistent bottleneck has been the manual writing of security rules for each new application deployment. When a release is ready to ship, security engineers have historically needed to hand-craft policy rules from scratch—a slow, error-prone, and frustrating process that undermines the speed gains DevOps promises.

Intent-Based Security: Moving Beyond Manual Rule Writing

A newer approach called intent-based security reframes the problem. Instead of writing individual rules for every asset or deployment, security teams define the intent behind their policies—what assets exist, how they should communicate, and what risk posture is acceptable. From that intent, rules can be automatically generated and applied to any new deployment.

This approach acts as an abstraction layer. Both security professionals and non-security stakeholders (application owners, line-of-business leaders) can participate in policy enforcement without needing to write syntactical rule strings by hand. Machine learning and automation handle the translation from human-readable intent to machine-enforceable policy.

Establishing Security Intent: A Three-Step Framework

Before rules can be auto-generated, security teams must first establish a clear picture of security intent. This involves three steps:

1. Inventory and Analyze Assets

You cannot protect what you cannot see. Recursive network indexing builds a comprehensive inventory of assets on the network. Traffic flow analysis and access path analysis then reveal how those assets actually behave—what they communicate with, what protocols they use, and what access patterns are normal versus anomalous.

2. Classify Communications Protocols

Not all protocols are appropriate in all contexts. For example, protocols such as SMB (Server Message Block) or Telnet may be entirely inappropriate between certain asset classes in a modern environment. By classifying protocols and pairing them with asset types, security teams can create meaningful profiles: for instance, “this asset class is never permitted to initiate a Telnet connection.” If a deviation from this intent appears on the network, it signals a policy violation immediately.

3. Overlay Business Context

Raw network data and protocol classifications are meaningless without business context. A database server communicating with an internal analytics platform is very different from that same server communicating with an external IP address at 3 AM. Business context—what applications do, who owns them, what data they handle, and what regulatory requirements apply—transforms data points into actionable security intelligence.

Translating Intent into Policy: Key Considerations

Once security intent is established, the next challenge is translating that intent into enforceable policy. Three categories of input must be considered:

Compliance Requirements

Regulatory frameworks such as PCI DSS, HIPAA, or SOC 2 impose specific controls on specific asset types. These compliance requirements must be mapped to concrete access controls and rules. Intent-based security makes this mapping explicit and auditable, rather than buried in tribal knowledge.

Business Requirements

Business goals are typically expressed in plain English—”only authorized sales staff should access customer PII” or “the payment service must never communicate directly with the public internet.” With traditional approaches, engineering teams translate these goals manually into rule syntax specific to each enforcement device or platform. Intent-based security uses automation to perform that translation, allowing rules to be dynamically generated as business requirements evolve.

Security Mandates

Security mandates change as new vulnerabilities are discovered or threat landscapes shift. When a mandate changes—such as deprecating a weak cipher suite or blocking a newly identified attack vector—intent-based systems propagate that change automatically across all relevant rules and deployments, rather than requiring a manual update across dozens of individual policies.

The Practical Impact on DevOps Pipelines

When rules are automatically generated from templates derived from security intent, the DevOps pipeline gains several concrete advantages:

• Faster deployments: Application teams no longer wait for security engineers to hand-craft rules before a release can proceed.
• Consistency: Automatically generated rules are applied uniformly, eliminating the human error that accompanies manual rule writing.
• Auditability: Intent is documented and traceable, making compliance audits significantly less painful.
• Self-service policy application: Application owners can apply pre-approved security templates themselves, with security teams retaining oversight through template governance rather than direct rule authorship.
• Rapid response to change: When security mandates shift, policy updates propagate automatically rather than requiring a manual review of every existing ruleset.

Security by Design, Not by Bolt-On

The automobile analogy is instructive precisely because it illustrates what good looks like. When safety is designed in from the start, it becomes invisible to the end user—it just works, and it doesn’t slow down the factory floor. Intent-based security automation aims to achieve the same outcome for software delivery: security controls that are integrated so smoothly into the pipeline that they add negligible friction while providing robust protection.

Eliminating the friction between DevOps velocity and security rigor is no longer optional for most organizations. Automated rules generation—grounded in clearly defined, context-aware security intent—is one of the most promising mechanisms available to make that happen. As DevSecOps matures from a buzzword into a standard operating model, teams that invest in intent-based approaches will be better positioned to ship fast and ship securely.

The State of DevOps Automation

Adoption is uneven. A significant share of DevOps teams report having no structured automation program in place, and even among those that do, only a minority have self-service capabilities for R&D and dev/test workflows. That gap matters: without meaningful automation, DevOps cannot deliver the agility required to support modern application development and deployment cycles.

One concrete symptom is infrastructure wait time. Less mature organizations commonly report waiting up to a month to get access to provisioned infrastructure, while leading teams have reduced that to hours. The difference is almost always automation.

Why Today’s Automation Is Different

Automation is not new in IT operations, but the current wave is qualitatively different from earlier iterations. Legacy automation tends to be siloed — scripts or runbooks that solve narrow problems in isolation. The result is that it rarely has a meaningful impact on overall delivery performance.

What has changed is the rise of virtualization and software-defined infrastructure. When compute, networking, and storage can be expressed and managed as code, automation can operate at a systemic level rather than touching individual components one at a time. Infrastructure as Code (IaC) tools such as Terraform, Ansible, and Pulumi are the practical expression of this shift. Organizations that have adopted integrated automation toolchains report meaningful gains in both deployment frequency and time-to-delivery.

Six Areas Ripe for Automation

When deciding where to direct automation investment, it helps to work from a prioritized list of domains rather than automating opportunistically. The following six areas are widely recognized as high-value targets:

• Networking — Network configuration management has historically been manual and change-averse. Software-defined networking and tools like Ansible network modules now make declarative, repeatable network automation practical.
• Infrastructure provisioning — Modern automation stacks can provision hundreds or thousands of servers (or cloud instances) in a single operation. IaC tools remove the bottleneck of manual server builds.
• Operating environment management — Configuration management tools enable centralized, consistent control over OS-level settings, patching, and compliance baselines across large fleets.
• Security — Security checks, policy enforcement, and vulnerability scanning should be embedded in the pipeline rather than applied after the fact. Automating security gates prevents them from becoming delivery bottlenecks.
• Orchestration — Coordinating the interaction between services, deployments, and environments requires a layer of orchestration automation, from container scheduling (Kubernetes) to workflow engines.
• Testing and quality gates — Automated test suites, linting, and static analysis integrated into CI pipelines catch regressions early and remove the need for manual sign-off on routine changes.

Governance: The Non-Technical Half of Automation

Technology alone does not make automation succeed. Without a governance model, automated systems can drift, accumulate unchecked costs, introduce compliance gaps, or create new single points of failure. A practical DevOps automation governance model should address at least six areas:

• Compliance by Design — Security and data-handling requirements must be encoded into automation templates and pipelines from the start, not bolted on after deployment. This is especially important when workloads span multiple cloud environments.
• Insights and cost visibility — When resource consumption is dynamic and automated, you need instrumentation and dashboards that show exactly what your systems are doing and what it costs in real time.
• Continuous Monitoring — Monitoring in an automated environment should be proactive, not reactive. Alerting and remediation logic should identify risk and compliance drift early enough to address it automatically or with minimal human intervention.
• Automated Provisioning — Applications should be able to move through dev, test, staging, and production environments quickly, with infrastructure spun up and torn down on demand to avoid resource waste.
• Integrated CI/CD — Script- and template-based pipelines reduce deployment time and create an auditable trail of every change. An integrated audit log is essential for regulated industries and post-incident analysis.
• Team Support and Shared Responsibility — Governance is not the job of a single platform team. It requires buy-in and participation across development, operations, security, and management. Automation often creates new roles — platform engineers, SREs, automation architects — that need explicit definition.

Avoiding the Autopilot Trap

A critical misconception about DevOps automation is that its goal is to remove humans from the loop. It is not. Over-reliance on automation — deploying it without adequate monitoring, governance, or human judgment — can be just as damaging as under-reliance.

The real value of automation is to amplify human decision-making: freeing engineers from repetitive, low-value tasks so they can focus on designing resilient systems, responding to novel incidents, and pursuing new product and market opportunities. Automated systems still need to be observed, tuned, and periodically rethought as the business evolves.

Put differently, automation raises the ceiling on what a DevOps team can accomplish — but it does not lower the bar for engineering judgment. The teams that get the most out of automation are those that treat it as a discipline, not a destination.

Getting Started: A Practical Approach

• Audit first. Map your current manual processes before automating anything. Understand where time is actually lost.
• Automate the most painful bottleneck first. Infrastructure provisioning and environment setup are common early wins with high ROI.
• Build governance in from day one. Establish tagging standards, cost alerts, and compliance checks before your automated footprint grows.
• Measure outcomes. Track deployment frequency, lead time for changes, mean time to recovery (MTTR), and change failure rate before and after automation efforts.
• Iterate. No automation program is complete. Treat it as a product with a roadmap, not a project with an end date.

GitLab 11.0 Ships Kubernetes-Native Auto DevOps

In June 2018, GitLab released version 11.0 of its platform, centering the update on a Kubernetes-backed feature called Auto DevOps. The goal was straightforward: a developer pushes code, and the platform handles every subsequent step automatically — no manual plugin configuration, no endpoint wiring.

According to GitLab CEO and co-founder Sid Sijbrandij, the 11.0 pipeline covers the following stages automatically when Auto DevOps is enabled:

• Build – containerising the application automatically
• Test – running the project’s test suite
• Code quality scanning – static analysis of source code
• Security scanning – vulnerability detection in dependencies and code
• License scanning – identifying open-source license obligations
• Packaging – producing a deployable artefact
• Performance testing – load and response-time checks
• Deployment – releasing to a target Kubernetes cluster
• Application monitoring – runtime metrics and alerting

“These things are normally a time sink in that there are plugins that need to be added and endpoints need to be set,” Sijbrandij explained. “Now with this update those things just happen.”

Why Kubernetes Is Central to Auto DevOps

Sijbrandij was explicit that the feature’s automation would not have been achievable without Kubernetes as the underlying orchestration layer. “Auto DevOps would not be possible without Kubernetes,” he said. “The ability to spin up new processes is the real superpower and is what we get from the integration.”

Kubernetes provides several capabilities that Auto DevOps depends on:

• On-demand pod scheduling – each pipeline stage can spin up an isolated container, run its job, and terminate, keeping resource usage proportional to actual work.
• Declarative deployments – rolling updates and rollbacks are managed by the cluster, not by custom shell scripts.
• Namespace isolation – review apps and staging environments can be created per branch without interfering with production.
• Secrets management – Kubernetes secrets can be injected into pipeline jobs and running pods without hardcoding credentials.

Native Google Kubernetes Engine Integration

In April 2018 — two months before the 11.0 release — GitLab announced a partnership with Google to support automated container cluster deployments. The deal added native Google Kubernetes Engine (GKE) integration, letting users connect an existing managed Google container account directly to GitLab.

Once connected, GitLab can automatically create Kubernetes clusters that are fully managed by Google and run on Google Cloud Platform (GCP). This removed a significant barrier to adoption: teams that had no existing Kubernetes expertise could still take advantage of Auto DevOps by letting GKE handle cluster lifecycle management.

“It’s been everything we had hoped for,” Sijbrandij said of the Kubernetes integration at the time of the 11.0 announcement.

Container Idling: Serverless-Style Efficiency on Kubernetes

At the time of the 11.0 release, GitLab was also exploring an idling feature that would take non-running containers offline automatically, preventing them from consuming compute or cloud spend when idle. Sijbrandij drew a direct comparison to the economics of serverless platforms, which only consume resources when actively handling requests.

This kind of idle-container management on Kubernetes mirrors patterns later popularised by projects such as KEDA (Kubernetes Event-Driven Autoscaling) and Knative’s scale-to-zero capability, though GitLab’s 2018 implementation details were not publicly specified at the time.

GitLab’s Serverless Ambitions

Sijbrandij also signalled that GitLab was increasing its investment in the serverless space, including work with an unnamed partner on a platform that could integrate with open-source serverless frameworks such as OpenFaaS and Kubeless.

He acknowledged two persistent pain points developers faced with serverless at the time:

• Lack of observability – limited visibility into function execution, latency, and failure rates compared to traditional long-running services.
• Revision control – difficulty tracking and rolling back individual function deployments in the same way as versioned application releases.

“There is not really a clear leader yet in open source serverless, but we think with a partner we can make something that is useful,” Sijbrandij said, while declining to name the partner or provide a release timeline.

The GitHub Effect: 100,000 Repository Imports

The 11.0 announcement came against the backdrop of Microsoft’s planned $7.5 billion acquisition of GitHub, which generated significant concern within parts of the open-source community. GitLab reported that in the days immediately following the Microsoft announcement it had:

• Imported more than 100,000 repositories
• Seen a 7× increase in orders

GitLab moved quickly to capitalise on the moment by offering discounts on its top-tier plans.

However, Sijbrandij was candid about the long-term picture. “There are users that were concerned with the Microsoft deal and moved to GitLab, but I think that will be temporary,” he said. His more considered argument for sustained GitLab adoption rested on platform differentiation rather than Microsoft anxiety: “Many were satisfied with GitHub, but see that they can do more with GitLab. This will create more opportunities and open some doors for us.”

Financial Context: Series C and Market Valuation

At the time of the 11.0 release, GitLab had closed a $20 million Series C funding round from Google Ventures (now GV). Sijbrandij described the company as “well financed” and noted that Microsoft’s $7.5 billion valuation of GitHub “puts a valuation out there, and it was high” — implying that the acquisition price set a favourable reference point for how the market values developer platform businesses.

Key Takeaways for DevOps Teams

The 11.0 release illustrated several principles that remain relevant to platform engineering teams today:

• Kubernetes as a CI/CD substrate — using the cluster as the execution environment for pipelines (not just as a deployment target) unlocks per-job isolation, resource limits, and horizontal scaling of build workloads.
• Convention over configuration — Auto DevOps demonstrated that sensible defaults can dramatically reduce the time-to-first-working-pipeline for new projects.
• Integrated security scanning — embedding SAST, dependency scanning, and license checks into the standard pipeline — rather than bolt-on tools — makes security a routine step rather than a gate at release time.
• Managed Kubernetes lowers the barrier — pairing a CI/CD platform with a managed Kubernetes offering removes the need for teams to maintain cluster infrastructure before they can benefit from container-native pipelines.

This article reflects the state of GitLab and the broader ecosystem as of June 2018. Some features described were roadmap items at the time and may have shipped, changed scope, or been superseded in subsequent releases.

Puppet Buys Reflect Technologies to Expand Analytics Capabilities

DevOps automation vendor Puppet Inc. announced in June 2018 that it had acquired Reflect Technologies Inc., a Portland, Oregon-based startup that specializes in embedded data visualization. The move signaled Puppet’s intent to layer richer analytics and reporting directly into its infrastructure automation platform.

About Reflect Technologies

Founded in 2015 and headquartered in Portland — the same city as Puppet — Reflect built its product as an analytics-as-a-service offering rather than a standalone end-user tool. Its core value proposition was enabling software companies to embed data visualization and analytics directly into their own products, so those companies could in turn offer reporting capabilities to their customers. This embedded analytics model set Reflect apart from conventional business intelligence tools aimed at internal analysts.

Prior to the acquisition, Reflect had raised $2.5 million in a seed funding round in 2016. The company employed fewer than ten people at the time of the deal. Financial terms of the acquisition were not disclosed.

Integration into Puppet’s Leadership and Product Line

Following the acquisition, Reflect was absorbed fully into Puppet. Reflect’s CEO Alex Bilmes transitioned into the Puppet organization reporting directly to Chief Product Officer Omri Gazitt, indicating that Reflect’s technology would be guided by Puppet’s core product strategy rather than operated as an independent business unit.

Puppet CEO Sanjay Mirchandani explained the rationale for the deal in comments to ZDNet:

“We generate so much data, and we’ve got different visualization and reporting capabilities… but it’s never enough.”

Sanjay Mirchandani, CEO, Puppet Inc.

While Puppet already offered some data analytics functionality within its products, the company viewed Reflect’s embedded visualization technology as a way to significantly deepen those capabilities and surface actionable insights from the infrastructure data its platform already collected.

How Reflect’s Technology Fits Puppet Enterprise

The primary integration target was Puppet Enterprise, Puppet’s flagship commercial product. Puppet Enterprise allows operations and development teams to manage infrastructure and applications across the full software delivery pipeline using code-driven configuration. It automates the provisioning and configuration of servers and virtual machines, and supports functions such as code review, testing, continuous integration, and deployment.

By integrating Reflect’s visualization layer, Puppet aimed to give teams clearer, real-time insight into the state of their infrastructure and the performance of their delivery pipelines — moving beyond raw log and report data toward interactive, visual dashboards. Puppet also offered a free, open-source edition of its platform referred to at the time as Puppet 5.

Context: Puppet’s Broader Acquisition Strategy

The Reflect deal was not Puppet’s first acquisition aimed at expanding its platform scope. In September 2017, Puppet acquired Distelli Inc., a continuous delivery automation software company. Puppet subsequently released three products built on Distelli’s technology:

• Puppet Pipelines for Applications — continuous integration and delivery for application workloads.
• Puppet Pipelines for Containers — CI/CD pipelines targeting Kubernetes clusters.
• Puppet Container Registry — an open-source registry for Docker images, providing a unified view of container images across environments.

Together, the Distelli and Reflect acquisitions illustrated Puppet’s strategy of expanding from its configuration management roots into a broader DevOps platform covering continuous delivery, container orchestration, and now data visualization.

Why This Acquisition Matters for DevOps Teams

For DevOps practitioners, the significance of the Puppet–Reflect deal goes beyond a typical tool acquisition. Infrastructure automation platforms generate substantial volumes of operational data — configuration drift events, deployment frequency, failure rates, compliance states — but that data is often difficult to consume without purpose-built visualization layers.

Embedding analytics directly into an automation platform, rather than requiring teams to export data to a separate BI tool, reduces friction and can help engineering and operations teams make faster, data-informed decisions about infrastructure health and delivery performance. The embedded model that Reflect pioneered is also increasingly relevant as organizations look to expose operational metrics not just internally but to development teams and, in some cases, to end customers of their platforms.

Summary

Why Infrastructure Automation Matters

Infrastructure automation enables organizations to build operating environments that are consistent, repeatable, and auditable. By codifying environment configuration and deployment steps, teams eliminate the manual, error-prone processes that slow down delivery and create production inconsistencies. The practical results are faster deployment cycles, lower failure rates, and a reduced operational burden on both development and operations staff.

The drive toward automation did not emerge in a vacuum. As businesses faced pressure to ship software faster and compete more effectively, the cost of manual deployments — measured in bugs, outages, and missed market windows — became impossible to ignore. Bridging the gap between development and operations became a strategic necessity, not just a technical preference.

The Challenges That Made DevOps Necessary

Before DevOps practices became mainstream, organizations routinely encountered a set of structural problems that limited their ability to deliver reliable software quickly:

1. Cultural silos between development and operations. Development teams optimized for speed and feature output; operations teams prioritized stability and change control. These competing incentives created friction, blame cycles, and slow handoffs.
2. Database administrators excluded from release cycles. DBAs were often brought in only at the end of a release, making schema changes a bottleneck and a common source of deployment failures.
3. Inconsistent, error-prone deployments. Without automated testing and standardized deployment pipelines, code that worked in development frequently broke in staging or production due to environment differences.

The Emergence of DevOps Practices

DevOps emerged as both a cultural philosophy and a set of engineering practices designed to break down these silos. By establishing shared ownership of the software delivery lifecycle, DevOps gave development and operations teams a common framework for collaboration, measurement, and continuous improvement.

Adopting DevOps in practice typically involves three phases:

1. Define measurable outcomes. DevOps engineers and architects establish traceable metrics — deployment frequency, mean time to recovery (MTTR), change failure rate — that anchor the roadmap to business value rather than subjective goals.
2. Build a pilot integration framework. Teams identify existing development and operations tools and begin integrating them into a unified pipeline. This avoids a “rip and replace” approach and builds organizational confidence incrementally.
3. Automate and iterate. Based on the metrics and available resources, teams automate network provisioning, testing, deployment, and monitoring — continuously refining the pipeline as they learn.

Core DevOps Infrastructure Tools

DevOps infrastructure automation relies on a layered toolchain. The following tools represent some of the most widely adopted options at each layer of the pipeline. Tool choice depends on team skills, existing infrastructure, and workload characteristics — there is no single correct combination.

Jenkins — Continuous Integration and Pipeline Orchestration

Jenkins is an open-source, Java-based automation server that has become a foundational CI tool in many DevOps pipelines. It integrates with version control systems such as GitHub, GitLab, and SVN. When new code is pushed to a repository, Jenkins triggers a build-and-test cycle and reports results back to the team.

Over time, Jenkins has evolved well beyond basic CI. Its plugin ecosystem and Pipeline-as-Code support (via Jenkinsfiles) allow teams to define complex multi-stage deployment pipelines, including provisioning, testing, security scanning, and production rollout, all in version-controlled code.

Chef — Code-Driven Configuration Management

Chef is a Ruby-based configuration management tool that models infrastructure as code using “cookbooks” written in Chef’s domain-specific language (DSL). A Chef server acts as the source of truth for configuration policies; lightweight agents (Chef Client) running on managed nodes periodically pull and apply the relevant cookbooks. Chef is particularly strong in environments where infrastructure is complex and configuration logic requires the expressiveness of a real programming language.

Puppet — Declarative Infrastructure for Operations Teams

Puppet takes a declarative approach to configuration management: engineers describe the desired state of a system using Puppet’s DSL, and Puppet handles convergence to that state. Puppet agents run on managed nodes, retrieve compiled catalogs from the Puppet server, and enforce the specified configuration. Puppet was originally designed with system administrators in mind, making it a natural fit for operations-heavy organizations managing large fleets of servers.

While Chef and Puppet solve similar problems, the practical difference often comes down to team background. Chef favors developers comfortable with Ruby; Puppet’s declarative model tends to suit operations engineers who think in terms of system state rather than procedural code.

Ansible — Agentless Automation and Orchestration

Ansible is an agentless automation tool that communicates with managed nodes over SSH (or WinRM for Windows). Configuration and orchestration logic is written in YAML-based “Playbooks,” which are widely regarded as more approachable for teams new to infrastructure-as-code. Because Ansible requires no agent installation, it has a lower barrier to adoption and is commonly used for cloud provisioning, application deployment, and ad hoc operational tasks alongside its configuration management role.

Docker — Container-Based Application Isolation

Docker introduced process-level virtualization through Linux containers, allowing applications and their dependencies to be packaged into portable, self-contained images. A Docker container runs identically regardless of the underlying host environment, which directly addresses the “works on my machine” problem that historically plagued deployments across development, staging, and production environments.

Docker has become a foundational element of modern DevOps pipelines, enabling microservices architectures and serving as the runtime layer beneath container orchestration platforms such as Kubernetes.

The Future of DevOps Infrastructure Automation

DevOps infrastructure automation continues to mature rapidly. Several trends are shaping where the practice is heading:

• GitOps. Treating Git as the single source of truth for both application code and infrastructure configuration, with automated reconciliation loops ensuring production state matches repository state.
• Policy as Code. Embedding compliance and security policies directly into the pipeline using tools such as Open Policy Agent (OPA), so governance is enforced automatically rather than audited manually after deployment.
• AI-assisted operations (AIOps). Using machine learning to detect anomalies, predict failures, and surface actionable insights from observability data at a scale that exceeds human capacity to monitor directly.
• Platform engineering. Building internal developer platforms (IDPs) that abstract infrastructure complexity behind self-service interfaces, enabling product teams to provision and deploy without deep infrastructure expertise.
• FinOps integration. Coupling infrastructure automation with cloud cost visibility so that provisioning decisions are informed by real-time cost data, not just performance and reliability requirements.

Organizations that invest in automation infrastructure now are building the operational leverage needed to scale their engineering capacity without proportionally scaling their headcount. As the tooling and practices continue to mature, the gap between high-performing DevOps teams and those still relying on manual processes will only widen.

Iteration Was Never a New Idea

When Barry Boehm formulated the Spiral Model of software development in 1986, he was not inventing iteration from scratch. Faster, incremental development cycles had existed in practice long before his paper. What Boehm did was present iterative delivery as a credible, formalised alternative to the exhaustive, sequential approaches — most notably the Waterfall model — that dominated thinking at the time.

The Spiral Model placed risk analysis at the centre of each development cycle, combining elements of both iterative development and the structured discipline of traditional engineering. In doing so, it set the intellectual groundwork for what would eventually become Agile methodologies, and later DevOps.

The Persistent Stigma of Moving Fast

Despite decades of evidence, fast and iterative approaches to software delivery still encounter resistance in many organisations. The perception — however unfounded — is that speed comes at the cost of quality or discipline. This prejudice is as logical as judging a developer’s competence by their dress code: it says more about the observer than the observed.

Boehm himself addressed this tension directly in his 2004 book, Balancing Agility and Discipline: A Guide for the Perplexed. The title alone captures the dilemma that engineering organisations continue to wrestle with today: how to move quickly without sacrificing reliability, security, or maintainability.

From Development Speed to Operational Bottlenecks

Over several decades, faster delivery has proven itself as a sound business strategy — not just an engineering preference. As development pipelines accelerated through Agile adoption, organisations began to notice that the bottleneck had shifted. Development teams could ship code faster than operations teams could safely absorb and run it.

This is the precise problem DevOps was designed to solve. By aligning development and operations around shared goals, shared tooling, and shared accountability, teams can eliminate the handoff friction that slows delivery and increases operational risk.

Anyone who has worked on both the development and operations sides of a production system understands how difficult it is simply to keep services running in a fast-moving technical environment — let alone to improve them continuously. The operational burden is real, and it is not going away. What can change is how much of that burden is carried manually.

The Two Pillars of Effective DevOps

Sustainable DevOps rests on two interdependent foundations:

• Cultural and process alignment: Development and operations teams must agree on a shared approach, a shared mindset, and a set of formalised controls. Without this alignment, automation simply accelerates dysfunction.
• Automation of those controls: Once the right controls are defined, automating them removes friction, reduces human error, and frees engineers to focus on higher-value work. Automation is how teams get the benefit of rigorous process without being paralysed by it.

Neither pillar is sufficient on its own. Excellent tooling applied to a broken process produces broken results faster. Equally, the right culture without supporting automation places unsustainable demands on individual engineers.

What the DevOps Automation Toolchain Needs to Deliver

Despite rapid growth in the DevOps tooling ecosystem, the market was still maturing at the time this analysis was written, and in many respects it continues to do so. Major platform vendors — including Microsoft, AWS, and IBM — had articulated a clear shared vision even where their implementations remained incomplete.

That vision describes a closed-loop delivery cycle:

1. Requirements management — capturing and prioritising what needs to be built, informed by real operational data.
2. Development and testing automation — continuous integration pipelines that validate code quality, security, and correctness at every commit.
3. Rapid, reliable deployment — infrastructure-as-code, containerisation, and orchestration tools that make releasing to production a routine, low-risk event.
4. Observability and feedback — monitoring, logging, and tracing that surface performance data and feed it back into the requirements process.

When these four stages are connected and automated, the result is a self-improving system: live performance data informs the next cycle of development, which is tested and deployed safely, generating more data. Intelligence flows around the loop rather than being trapped in siloed teams.

Should Your Organisation Adopt DevOps?

The question of whether DevOps is right for a given enterprise often reduces to a simpler question: does your business need to respond to change quickly? If the answer is yes — and in a technology-driven competitive landscape, it almost certainly is — then the follow-up question is not whether to adopt DevOps practices, but how to do so without introducing new risk.

The answer to the how question involves:

• Defining quality gates that are non-negotiable regardless of delivery speed.
• Investing in automation that enforces those gates consistently.
• Building observability in from the start, so that problems surface quickly and can be resolved before they compound.
• Treating DevOps adoption as an iterative process in itself — start with the highest-friction points and improve incrementally.

DevOps Will Keep Evolving

DevOps is a means to an end, not a fixed destination. Just as the Spiral Model gave way to Agile, and Agile created the conditions for DevOps, the practices that constitute DevOps today will continue to evolve. Emerging capabilities in analytics, machine learning, and AI-assisted operations (sometimes called AIOps) have the potential to further accelerate delivery pipelines and increase the sophistication of operational feedback loops.

What will not change are the underlying principles: iterate quickly, validate continuously, automate relentlessly, and use operational intelligence to drive the next cycle of improvement. Boehm’s spiral is not just alive and well — it has become a structural requirement for any organisation that expects to remain competitive in the digital age.

Original analysis sourced from gigaom.com (2017). This article has been expanded and updated for a DevOps engineering audience.

The Four Stages of DevOps Maturity

This model has many parallels to how I see large organizations embracing DevOps over the course of last several years. The following stages are not based on scientific analysis or modeling, but rather on how I have seen organizations mature as they progress through the learning curve.

Stage 1 – DevOps Denial and Misinterpretation

At the Unconscious Incompetence stage, the lack of understanding of what DevOps is and what its business benefits are causes organizations to deny the usefulness of DevOps and write it off as a kind of fad or bad marketing term. Some call this resistance to change, but it’s really a lack of understanding of the core value proposition. The same people who complain about painful deployments, excessive on-call support issues, constant firefighting and poor work-life balance defend this way of life over the DevOps way, because they simply don’t understand what DevOps is and how it will improve their current state.

They think of DevOps as operators having to learn how to code, or developers eliminating operation jobs, so they fight it with all their might. In reality, DevOps came about from operators partnering with developers to improve the deployments, stability, reliability and their quality of life.

Kishore Jalleda, Sr. Director of Production Engineering at Yahoo describes DevOps best in this slide.

Kishore Jalleda

Figure 2: A Definition of DevOps

At stage one, this message is lost, and organizations proceed with a “business as usual” attitude, waiting for this shiny object to pass in the night like many buzzwords before. The age-old silo operating model lives on.

Figure 3: Anti-pattern – Dev and Ops Silos

Stage 2 – Automation for the Sake of Automation

The Conscious Incompetence stage is usually present in the first 12 to 18 months of an organization’s DevOps journey. Many organizations grab onto the automation aspects of DevOps and start madly writing Chef scripts to automate everything and anything. Although some value is derived from these efforts (automated builds, automated infrastructure), much of this work is still being performed in silos, with limited to no improvement in collaboration between groups. Three common anti-patterns are implemented in stage 2.

Anti-pattern 1 – The DevOps Silo

http://web.devopstopologies.com/

Figure 4: Anti-pattern – DevOps Silo

What is the best way to fix your silo problem? Create a new silo called DevOps, and hire a bunch of DevOps Engineers (see my No you are not a DevOps Engineer rant). Welcome to your new bottleneck. In this model, a new element of separation is inserted between Dev and Ops and a “build it and they will come” mindset leads to more shadow IT as the Dev’s needs continue to go unmet.

Anti-pattern 2 – Dev Don’t Need No Stinkin’ Ops

http://web.devopstopologies.com/

Figure 5: Anti-pattern – Dev/No Ops

In this model, development teams script away the ops team and provision all of their own infrastructure as code. After all, infrastructure provisioning is their biggest bottleneck. The downside to this approach is that Devs are not experts at networking, security, compliance, support and many other capabilities that have been provided for them by various shared service groups. So although the Dev groups can now move much faster, they drastically increase risks for their company that can have catastrophic consequences.

Anti-pattern 3 – Rebranding Sysadmins as DevOps Engineers

http://web.devopstopologies.com/

Figure 6: Anti-pattern – DevOps Engineers

In this model, nothing really changes other than the sysadmins’ titles and resumes. All of the bottlenecks that keep work from flowing left to right remain, but some really cool scripts get built. Often, too many scripts are built, and now Ops is buried in script hell trying to manage thousands of lines of scripts, sometimes not checked into a repository. This “build it and they will come” approach often either backfires or just creates new bottlenecks. The Ops team often sees efficiency in their day-to-day tasks, but at the expense of newly wasted time in the Dev’s day-to-day tasks.

This may all sound like doom and gloom, but you have to start somewhere. A lot of learning occurs in this stage. Both Dev and Ops get familiar with the tooling and start to have a better understanding of each other’s needs. Some processes are improved, but usually those improvements are departmental and not system-wide.

Stage 3 – Collaboration and Reorganization

The Conscious Competence stage usually exists from years two to four. At this stage, the organization understands that DevOps is more than engineers and scripts, and is all about improving the entire software development lifecycle (SDLC), from business idea inception to business idea running in production.

By the time a company has entered stage 3, they have had pockets of success from grassroots efforts within the company. (Note: sometimes success is driven top-down, but more often than not a grassroots effort starts the journey.) Certain products or services within the portfolio have seen massive benefits from early DevOps efforts, and management has taken notice. Now the organization is open to doing the really hard stuff–people and process change.

At stage 3, collaboration expands beyond Dev and Ops to security, legal, compliance, audit and all those other bottleneck areas for Dev. In fact, the pattern we see from stage 3 to 4 is the shifting left of bottlenecks. First it was infrastructure. Then QA (automated testing in the pipeline). Then security (security scans in the pipeline, security and controls baked into the infrastructure, etc.).

In stage 3 we see the birth of platforms. Whether companies are using public or private cloud, or no clouds at all, platform teams build a layer of enterprise guard rails on top of the infrastructure layer, and provide self-service capabilities for the Dev teams. These platforms take the requirements from GRC (governance, risk, compliance), security, etc., and provide APIs and abstractions so that the Dev teams can inherit these controls and policies as they consume the platform services. This operating model often looks like this:

http://web.devopstopologies.com/

Figure 8: Platform as a Service (PaaS) Operating Model

In this model the Ops team is responsible for providing and operating the platform, and the developers are responsible for operating their applications, which are built on top of the enterprise guard rails. In stage 3 we finally get to “you build it, you run it.”

As organizations mature through Stage 3, we see improved collaboration across departments, and value stream mapping exercises being performed to aid in process improvement activities. A learning organization begins to emerge, and activities like blameless post mortems, gameday exercises, adoption of lean concepts, and others take root.

Stage 4 – A High Performing Organization

At the Unconscious Competence stage, organizations have the ability to deploy multiple times a day with certainty and minimal risk. Removing bottlenecks becomes a way of life. What I saw over and over at DOES17 were large organizations shifting everything left. In stage 3 we saw QA and security shifting left. In stage 4 we see Ops, GRC, and even tier 1 through tier 3 support shifting to the business units (BUs).

Each BU becomes a self-sufficient organization with full stack teams (squads) made up of experts across all the necessary technology and process domains. The classic security, Ops and GRC teams still exist, but their role is to establish policy and standards, not implement them. The BUs implement them in the way that’s optimal for their products or services.

Summary

DevOps is real, and is not a fad or another fancy buzzword. As companies move through the stages of learning, each stage provides more business value to the company. The speed at which business moves is increasing exponentially, and the companies that can deploy at the prevailing speed of business will win. As we look at the technologies that are driving the future–such as AI, machine learning, block chain and IoT–the companies that have entered Stage 4 maturity will be able to bring solutions using these technologies faster than their competition, creating even more separation in marketplace. My advice is to either embrace DevOps and start transforming your organization, or go out of business.

CA Technologies Bets Big on DevOps, AI, and Analytics at CA World 2017

At its annual CA World 2017 conference, CA Technologies announced more than 20 new and updated products spanning multiple business verticals. The release wave concentrated on DevOps tooling, automation, security testing, microservices management, and machine-learning-powered analytics—areas the company collectively frames as the foundation of a modern software factory.

CA president and chief product officer Ayman Sayed delivered the keynote, emphasising that the release cycle was driven by a focus on usability and faster time-to-value:

“I am particularly happy and pleased, and very excited, about our ability to make the products easier, more intuitive to use, and simpler. This speeds up time-to-value, the time it takes you to get a POC going. We’ve invested heavily in try-and-buy, in quick time-to-value, and if you look at the number of enhancements we’ve offered, several of them are in this category.”

Ayman Sayed, President & Chief Product Officer, CA Technologies (speaking to Channel Pro)

DevOps Tooling: New and Updated Products

DevOps was the most prominent theme of the release, accounting for three entirely new products and four significant updates. Key highlights include:

• API Testing for BlazeMeter: New API testing capabilities integrated into CA’s cloud-based continuous testing platform, extending BlazeMeter beyond its load-testing origins.
• SaaS-Based Application Performance Management (APM) Console: A new customer experience and APM dashboard delivered as a SaaS offering, aimed at giving teams a unified view of application health.
• DevSecOps IDE Integration: New tooling for testing code security directly inside the integrated development environment (IDE), enabling teams to shift security checks left into the development workflow rather than treating them as a release-gate activity.

The new capabilities build on strategic acquisitions CA completed in the preceding year, including Veracode (application security testing), BlazeMeter (continuous performance testing), and Automic (IT automation and release orchestration).

Microgateway: Rapid Microservices Deployment for Legacy Modernisation

CA also highlighted its Microgateway product, which the company described as award-winning at the time of the announcement. The Microgateway is designed to let organisations rapidly deploy and manage microservices alongside existing legacy systems—providing a route to incremental modernisation without requiring a full rewrite of established infrastructure.

For DevOps teams working in enterprises with significant legacy footprints, tooling that bridges microservices architectures with monolithic backends is practically significant: it allows independent deployability and scalability of new capabilities while preserving existing investments.

Machine Learning and Analytics: The ‘Modern Software Factory’ Vision

A recurring theme across the new portfolio was the embedding of machine learning and data-driven analytics into existing product lines. CA positioned these capabilities as the intelligence layer that differentiates a traditional IT organisation from what it calls a modern software factory—a highly agile, software-driven business capable of adapting rapidly to market change.

“Every business can be a modern software factory and achieve better business outcomes faster with the right intelligence. Today our portfolio is comprised of the tools and technologies that inject analytics and machine learning into our customers’ existing technology investments to compete and win in today’s fast-moving marketplace.”

Ayman Sayed, CA Technologies

Context: CA Technologies’ Acquisition-Led Portfolio Expansion

The CA World 2017 announcements reflected a broader strategy of growth through acquisition followed by deep product integration. By absorbing BlazeMeter’s continuous testing expertise, Veracode’s application security capabilities, and Automic’s automation and orchestration tooling, CA was positioning itself as an end-to-end platform vendor across the software delivery lifecycle—from development and testing through deployment, monitoring, and security.

For DevOps practitioners evaluating enterprise toolchains, the key takeaways from the 2017 announcement were:

• Shift-left security tooling (DevSecOps IDE integration) was becoming a first-class citizen in CA’s DevOps portfolio.
• SaaS delivery models were being prioritised to reduce time-to-value for enterprise teams.
• Microservices and API management tooling was being treated as essential infrastructure for legacy modernisation, not just greenfield projects.
• ML-assisted analytics were being embedded across product lines rather than offered as standalone add-ons.

Note: CA Technologies was subsequently acquired by Broadcom in 2018. Many of the products mentioned here are now part of the Broadcom Software portfolio. Readers should verify current product availability and naming directly with Broadcom.

CA Doubles Down on the Modern Software Factory

At its annual CA World 2017 conference in Las Vegas, CA Technologies used the stage to announce 20 new products and enhancements—what the company described as the largest single release in recent history. The announcements were framed around CEO Mike Gregoire’s long-running strategic vision: the Modern Software Factory, a model for building intelligent, secure, and automated software at enterprise scale.

Gregoire, who has championed the Modern Software Factory concept since joining CA roughly five years before the 2017 conference, addressed customers about the need to connect “ideas and execution”—using software to build on an organisation’s unique strengths before competitive pressures force the issue.

“We’ve long passed the point where enterprise software is used merely to drive efficiencies. The focus today is on innovating the next big shift for your company.”

Mike Gregoire, CEO, CA Technologies — CA World 2017

Key Announcement Areas

CA grouped its announcements into several capability pillars, each targeting a different layer of the software delivery lifecycle:

DevOps Automation at Scale

A new automation platform was introduced to help enterprises scale their DevOps practices using analytics-driven insights. The goal is to move beyond tool adoption and give teams the operational intelligence needed to continuously improve pipeline performance and throughput.

Microservices Management with CA Microgateway

CA announced CA Microgateway, a tool designed to deploy and manage microservices in minutes. As organisations decompose monolithic applications into smaller, independently deployable services, tooling that handles service discovery, policy enforcement, and API management at the microservice layer becomes essential. CA Microgateway was positioned to address exactly that gap.

DevSecOps: Security Built In From the Start

Several of the 20 announcements targeted the growing DevSecOps discipline—the practice of integrating security controls into development pipelines from the first commit, rather than bolting them on before release. CA’s new security products were presented as a way to improve security posture without creating friction that slows development velocity.

This reflects an industry-wide shift: traditional security gate reviews at the end of a release cycle are increasingly incompatible with high-frequency delivery models like continuous deployment. Shifting security left—earlier in the pipeline—distributes responsibility across development, security, and operations teams.

AI-Powered Mainframe Management

Despite the industry’s sustained migration toward cloud-native infrastructure, CA made a point of addressing its substantial mainframe customer base. New AI-powered tooling was announced to help mainframe operators proactively detect and resolve potential issues before they cause downtime, while also strengthening security on those platforms.

Mainframes continue to underpin critical workloads in financial services, insurance, and government sectors. Integrating AI-driven observability into mainframe operations aligns with broader AIOps trends playing out across the infrastructure management market.

The Modern Software Factory Framework

Across its announcements, CA consistently returned to the pillars of the Modern Software Factory: velocity, security, and performance. The framework positions software delivery not as an IT function, but as a core business capability—one that determines whether a company can respond to market changes faster than competitors.

“The ability to manage change, respond to new inputs or insights and pivot has never been more important. Our entire portfolio is designed around the pillars of the Modern Software Factory to increase the velocity, security and performance of the solutions and the apps that are critical to our customers’ businesses.”

Mike Gregoire, CEO, CA Technologies

Why This Matters for DevOps Teams

• Integrated toolchains: A vendor releasing 20 coordinated updates signals an effort to reduce integration overhead across the SDLC—relevant for teams managing complex tool sprawl.
• DevSecOps adoption: Security tooling designed to fit inside pipelines, rather than interrupt them, lowers the barrier to compliance for teams practicing CI/CD.
• Microservices governance: As microservice counts grow, API gateway tooling at the service level (not just the edge) becomes operationally necessary.
• Mainframe parity: AI-assisted operations for mainframes acknowledge that cloud transformation is incremental—many enterprises run hybrid estates for years during migration.

CA Technologies was subsequently acquired by Broadcom in 2018. Teams evaluating products announced at CA World 2017 should verify current product names, roadmaps, and licensing under Broadcom’s portfolio.