devopsy.kinsta.cloud

Author: Don Macvittie

Best of 2024: DevOps: What’s the End Goal?

In high tech, we have a penchant for not actually having an end goal. We have interim goals but no grand “this is what we need to do.” And yet, every space inevitably has a “this is the reason” attached. So what should the overarching goal of DevOps be?

We started out with streamlining processes as the goal, and quickly morphed into efficiency and being more responsive–all worthy goals, but it is the nature of both technologists and business people (for very different reasons) to not stop when the goal is reached. We went through several more iterations that all basically pulled more under the DevOps umbrella, and then settled on automation. AI will continue this automation trend, but to what end?

Where, exactly, do we want to go? Theoretically, we could make AI write the code, build the code, test the code and deploy the code with only a small contingent of actual people involved in the process. Seriously, if the idea is to let business people crank things out a la the promises of 4GLs, then we are closer than we have ever been to achieving that goal.

But, much like calculators, someone will still have to create these systems, and we are faced with a different conundrum: If no one is writing new code, learning-based AI will struggle to solve new problems. That challenge can, in theory, be overcome by teaching AI to disassemble and abstract existing solutions, but that will take time.

The other thing that business people and technologists share in the modern world is a lack of actual philosophers. I am a technologist, but much of my immediate family enjoys philosophy. So, I dug into philosophy with regard to science many years ago, and philosophers, being esoteric, ruined their ability to influence scientific thought. Focusing on questions like, “What if tomorrow, we found aluminum that wasn’t really aluminum?” was dumb and undermined the core idea of “Science will tell us what we can do, philosophy will tell us what we should do.”

So we’re on our own in that regard, and given a worldwide development community, we can assume that just because you can, someone will. Our question then is, “What does a given enterprise want and need from their DevOps processes?” The rate of change is about to accelerate again, so knowing what is important to your organization will matter in the next five years. A company that uses technology in support roles has wildly different needs than one that uses technology to develop products, and they have very different needs than a company for whom technology is the product.

Is the goal to eliminate the bulk of IT? Or is it to streamline IT even further and make it even more responsive to business needs? Perhaps the goal is to develop entirely new products or markets with the time that AI has freed up. The difference is huge in terms of planning. And these are the types of questions coming. The idea that any given technology can make things (or make them happen) faster and more efficiently without changing staffing is naïve and ignores the history of the auto industry.

Get together, IT and business leaders. Develop a plan. Do you want to do more with less, or do you want to reduce overhead? Do you want to have IT specialize while AI does the mass of generic work? Level one help desk can be taken over by chatbots today. Is that the type of direction the organization wants to go? Tell IT management that change is coming; the question is, how the organization wants to leverage it and conscious decision is far better than accidental results.

devopsy.kinsta.cloud · No No-Shift, DevOps Jobs, AI Tests Your Code, DevOps End Goal

January 2, 2025
Your AI Might be Lying to You

Simple tests can demonstrate how an AI can respond to and modify responses — a useful exercise for developers and DevOps who want to use these tools for activities like code or script generation.

While I was playing with generative AI for a hobby project – as most of us have – I discovered that in a few cases, it was stubbornly against following my explicit instructions. It wasn’t anything controversial. It was just that I was using a system that used math one way, and the AI was insistent in presenting results of the same category from a different subsystem. Even when told the steps to generate valid results, the AI tool got hung up on the name of the subsystem and “substituted” an invalid subsystem of the same name. It would say “Oh yeah, got you. Here: “ and then present what I’d just told it was factually incorrect. So I started pushing the edges and found a large number of instances where this type of confusion occurred.

In my hobby, I can take the time and calculate the bit I need separately, then insert it. In a professional setting, that is less than optimal. I mean, if we cut a dozen hours off a project and have to invest an hour fixing bits like this, it is still a massive win. The problem is that we have to know about the issue in order to fix it. But the system – where most of these issues are concerned – blindly does it, and doesn’t tell you. That’s so even where it knows it is not obeying your instructions.

Sometimes it’s okay to agree with the forced decisions of the AI’s designers. But an employee wouldn’t have a job long if, when told, “Do this task in exactly this manner” came back and said, “Yeah, your instructions didn’t fit my world-view, so I did something else; look at this great solution!” AI only gets a little more patience as long as it allows you to correct it quickly. And so far in our tests (except for the hobbyist issue above), we could convince it to do what we said, not what the AI designers said was “better.”

So here is the minimum test you need to run on any code generator to determine if it is doing what you ask, or what its AI designers programmed it to do.

Ask your AI to generate a simple dynamic website, in your language of choice. In one iteration, ask it to optimize for lines of code. Most will not; they know better, they think. Then after code generation, ask the tool if this is the fewest lines of code that solve the problem in that language. It will then give you the answer you actually asked for. Now repeat this exercise for readability. Use specific languages, frameworks, and libraries you might have as standards.

For simple problems, generative AI does generate usable code. I see AI in coding as being like an extension of libraries: a quicker way to solve common problems. But we still need to be cautious. When one major generative AI tool was asked to generate that simple webpage, it gave us four source files and said this was “an” answer. I had asked for the most efficient answer, optimized for minimum lines of code. As you might guess, we laughed at four source files to throw up a webpage that accepts a name and spits out “Hello [[name]]”. (This was our simple, dynamic test case). When I asked it, “Is this the fewest lines of code?” the tool promptly presented me with the answer you would expect. It was a single file, and then it scolded me that this was not the most readable. I never once mentioned readability to this tool, I mentioned optimized for minimum lines of code. But on the third iteration, it gave me the optimal answer for the dynamic example, and on the second the optimum answer for a simple webpage to display “hello world” non-interactively.

As I alluded to above, getting bad answers is not a deal breaker with AI, but you should be aware of the weaknesses in your chosen tool, and which tool you choose should certainly be informed about what level of manipulation the designers are engaged in, so staff can be on the lookout for suboptimal solutions (suboptimal in terms of organizational needs, which is the only “optimal solution” that matters).

So run that test along with your more functional tests, and keep kicking rear. If we can use generative AI for development and testing streamlining, we absolutely should, but we need to remember that it is just another automation tool, and sometimes less trustworthy than other tools.

April 8, 2024
Our Infrastructure is Still Expanding

You would think that sooner or later, marketers and early adopters would take a rest, but it seems that if one group slows down for a bit, another picks up. Our infrastructure is expanding in almost every possible way, and this creates more of a burden on every aspect of DevOps, specifically in IT.

We have more security needs because we have a larger footprint, for example. We have long had APIs, but now we have massive API groups that are used and re-used, and while standard code scanning works with the source, the companies doing “API security” start with security of the interface, not the code. That is slowly changing, but API management is also impacted, and organizations that determined they didn’t need API management because adjacent markets were serving enough of their needs are slowly discovering that with proliferation comes the need to look at API management again.

I stay up to date on most new technology because, as an industry analyst, what is coming can inform my discussions of what a given technology space looks like today. But even for me—someone who is not spending a huge chunk of my day coding or working on the toolchain or perfecting the new deployment platform—it can be hard to stay abreast of everything. While one of the foundational tenets of DevOps was no specialization and a shared workload, I think everyone now agrees with what a few of us were saying from day one: Some specialized skills are still needed, except in corner cases. But we certainly are sharing workloads more broadly and far more responsive, so DevOps is absolutely a massive success. Site reliability engineering (SRE) extends that success but focuses more on Ops. I’m really not a huge fan. I like that DevOps wanted to merge the processes and make the management of applications more holistic; I don’t think re-dividing it is the best idea out there. Like every title, “SRE” is interpreted pretty broadly. Some roles really involve DevOps (but SRE sounds cooler), and other organizations are just replacing ‘developer’ with DevOps and ‘operations’ with SRE. However, most are using SRE to manage the entire environment in which the app runs.

Where are we going? Constant change. That’s the answer. I’ve waited for the breather for a couple of decades, but since VMs were popularized, it has been non-stop and will continue to be.

This means a lot to you, to your viability as an employee, and to hiring. With the glut of people on the market, we’re seeing a resurgence of “must know every tool in our toolchain” type position postings. Of course, you must not, in a world where the combination of languages, frameworks, CI/CD tools, alerting, and monitoring tools would make a great college-level combinatorics equation. You add value by being adaptable. Both to your current employer and to future ones. The key thing you should seek to demonstrate is your ability to pick up and master new technologies when required. Do it on your current job to show worth, and keep a record of it for your next job. I’ve been a hiring manager off and on forever, and when the market is flooded with good candidates, that is the type of differentiator that gets the team’s attention. Do it; make it something worth doing and document that you did it. You won’t regret it.

A group of us were helping a recent grad figure out what to do with their career a couple weeks ago, and the consensus was “avoid AI until it shakes out.” This is not the first time I’ve heard that advice—it’s not even the first group I was a part of giving that advice. And I agree in the general sense, but certainly in places where it is being implemented by all vendors in the space and it adds value, you do need to be aware of how it works and what you can do with it, and a project is one way to get that knowledge.

It is still a rolling opportunity, and you are still keeping the lights on. I’ve seen people who worry they’re not doing enough. Any employer worth working for wants you to keep the systems running first, and everything else after—so if you’re doing that, you’re doing enough. Now go beyond. And keep rocking it. This new technology hasn’t implemented itself, and it isn’t self-maintaining (yet) … That’s all you.

March 27, 2024
The IT-DevOps Life Cycle is Like a Pyramid That Keeps Growing

Don’t let anyone tell you how much easier IT life is these days. It is, in many ways, more fun and productive … but it is not easier. In fact, we’re doing more with less, cubed, at this point. My point is—think of the life cycle as a pyramid. The base is the build++ chain, from VCS to public-facing active protection; the height is the new technologies and systems being bolted on daily—like SaaS tools someone in accounting just signed up for or the new architectures a dev team in a subsidiary just decided to adopt (but which will eventually have to be maintained by IT). And the depth is the completely new capabilities that are required by market forces or regulation – SBOM is the poster child for this group; suddenly, just about every vendor is giving it to you as part of their product.

No matter which of these axes is growing, the workload is generally growing commensurately. Think about it: If a new product is implemented, it impacts IT’s workload. If a new technology that solves a problem is implemented, it, too, impacts workload. And if a new capability in an existing product is dictated by the compliance team for any reason, this, too, increases workload. This is just the business side, and doesn’t include the fact that most orgs are dropping newly developed applications on a pretty regular basis these days.

Automation has helped, but it hasn’t solved the problem yet. I believe it can, given time and focus, but for the most part, the demand for new technology to solve age-old problems (“We can’t effectively test” being met with “Here is automated test generation, execution and results filtering”) has been a net increase in workload. Though far smaller than it might have been, it is still increasing. This is true across IT. The test example above applies to app dev and security, with result sets that did not exist six years ago because the process was too expensive in staff hours. It also applies to ops because the processing power to get those tests done – and it is a lot with large test environments – is ops’ responsibility.

Painting a bleak picture? Nope. Making certain we’re realistic. Trying to ensure that we consider how much we are already doing, and take a chance to implement actual time savers. For example, applying that same test automation to testing (for most orgs, I’m thinking security testing) that was actually being done already will reduce the cost of getting it done. Using SBoM for SCA to contribute to existing compliance saves a lot of time generating that information. Using new coding assistants shortens coding time and (arguably at this point, but inevitably, given the fullness of time) improves code quality, reducing rework, which is costly, even in an agile environment.

We are growing our capabilities almost daily. I’m just suggesting that, in the process, we backward-apply the good stuff to reduce existing overhead. And as always, this big, complex beast exists and keeps clipping along because you’re there, keeping it fed and stable. Keep rocking it, and save yourself some time by using new technology smartly—there is plenty more to do than whatever you streamline.

Image source: Photo by Michael Dziedzic on Unsplash

March 20, 2024
Is it Time to Reconsider CI?

DevOps is old, in technology terms, at this point. Many of you have never developed under a waterfall and have no idea what tools like Visual Test were, and that’s actually very cool. While knowing other processes and tools does help make informed decisions, being immersed in the tools that matter today is more important. We have entire DevOps stacks built up that allow for the development, building, testing and, increasingly, deployment of apps in an agile environment.

As always happens, market leaders and those who compete with them, complement them or serve a subset of the market have grown up and become standards. Indeed, application release orchestration (ARO) was a phrase coined in the early days of DevOps that fell away completely; I heard it recently and thought, “Oh, are we bringing that name back?” Vendors have come and gone; some merged into other products, and some are just plain gone. Again, that is a good thing as the market, its needs and the customer base are all mature. While it is terribly painful to be the user of a product that just goes away one day, the prevalence of open source in the CI/CD landscape does buffer that pain a bit. And the market gets better as tools fall away and new ones take their place.

But sometimes, the movement is slow, just simply due to inertia. Most of us – and by us, I mean IT shops, and by most I mean a lot – use Jenkins. The number seems to be on a steady downward trend, and the tool’s maintainers have definitely taken steps to improve the parts that make organizations consider other solutions, but the trend is there.

And I, personally, think that is a good thing. Stagnation is what made waterfall such a weakness in enterprise IT. Everyone did it, so that makes it good. Same is true for the old phrases we’ve all heard at least one variant of – “No one ever got fired for buying IBM”, or “No one ever got fired for buying Oracle”, “…Cisco”, etc. The obvious answer to those statements then, as now, was, “Well, maybe they should have.”

The same is true for Jenkins. It is a great system that can do everything. And that’s part of the problem. If you have small projects or are a team using it standalone with light requirements that all revolve around getting a quality product out the door quickly, Jenkins just might be too much for you. In the early days, Jenkins wasn’t, but the plug-in architecture and years of competition and changing market needs have made it huge. And while there is arguably better documentation than any other CI, and inarguably the largest user base to ask questions of, it’s still weighty to use in place of a SaaS that comes pre-configured and you can just hand it a repository with build files in it.

There are a lot of enterprises that need what Jenkins has grown into–it did not expand in a vacuum. But there are many, particularly new, small, agile orgs or standalone teams that just don’t.

There are a lot of options out there, and it is worth taking stock of what you are trying to do with your build/test process, and build a list of things required, then look seriously at what’s available. For some, lightweight is good.

Of course, as much as one can be in our technological age, I am a minimalist. I like my D&D to be a rules-light variant, my dev tools to have enough functionality but not bury me in extraneous stuff, laugh at Excel for including abstract functions and then selling to consumers, etc.

At my company that does development, we do indeed use Jenkins. But our projects range from simple knock-it-out one-offs to complex systems with multiple servers and clients, so we feel it is best for that range of variation. And like many others, the investment to move old projects would be questionable without a driving need. Not that I get to do much development these days myself, but I do stay in it just enough to be dangerous. But we have asked the question and determined the answer. For now.

If you have issues with Jenkins, look around. There are options. They are not for everyone, but your org isn’t everyone. Find the best tool, not the most convenient, and keep kicking rear.

March 13, 2024
Google is Right to be Afraid

In the grand scheme of things, at least in relation to the evolution of AI, Google’s recent stumbles come at a rather inopportune time, but the concerns that made them actually address the controversy are worse than most know.

One of the things that generative AI can do really well is answer questions about information available on the internet. While that does not appear to have been the goal–or at least not the only goal–of those who brought us generative AI, it is one of the outcomes. Or, more specifically, replacing search does not seem to have been the goal.

But that is coming fast. While typing a couple of words and getting a list of results is quick and easy–enough so that searching the entire internet has a simple name these days—for many questions, typing a sentence, getting a response, typing some more and getting a refined response is faster. Oh, there is a ton of risk involved in trusting an AI to summarize things for you (as we’ve seen repeatedly, from several providers)—but that risk exists whether it’s AI or not, and is answered by insisting on source links for any fact-based answer. Telling you a story doesn’t need links; telling you about a product absolutely does.

We see that a bit in search engines now, with a short summary at the top that takes from some source the engine decided was authoritative, and the list of links that search engines have always returned below. AI can do this more thoroughly and, when managed responsibly (as opposed to what Google has been doing) can create higher-quality answers than simply quoting the top or “most authoritative” source.

The ability to search will be bolted onto a wide variety of products, meaning that the backend for such search will be what is left to products like Google and Bing. Each misstep by a vendor will drive product creators to want increasing control of their end of the AI, and failure to cater to those needs will drive both the product implementors and customers away from the backend vendors.

My advice? Watch and wait. Try using AI to search; it works really well at returning specific information and, when prompted, links also. This journey is going to be bumpy, and all indications are that the near-term economy won’t tolerate a lot of mistakes. Vendors will come and go, products will be better at one thing and less so at another. And to protect the org, don’t get carried away in the trend to invest in AI for every single product. That is the future, but there are a lot of twists and turns in the trail between here and there.

Note a specific thing that the organization needs help with and with which AI might be able to assist, then go looking for valid solutions. Don’t buy things just because it includes generative AI—have a purpose. And pay attention to what your existing vendors are doing.

Google isn’t even vaguely close to down-and-out; they have more money than most nations. But they are set back a long way, and will have to work to regain trust. For some, there is no path to regain trust, and Google will have to accept that.

And we need to be pragmatic. You work for a business, so make business decisions based on what is best for the business, no matter what others are doing. Keep knocking out astounding apps, and keep smiling—because AI is eventually going to make your job easier.

March 6, 2024
How Much Testing is Too Much?

We have reached an interesting point in the automation of IT in general and testing specifically. Our tooling now allows us to generate a list of all of the possible permutations of a given test set. This is interesting because we can generate all of the possible permutations of a given test. We can also automatically run all of the tests so generated. And we can automatically filter those results, only raising what needs greater attention to a human for evaluation.

And that’s not necessarily a good thing.

Nothing is free. Nothing. In the case of pervasive testing that goes beyond the wildest dreams of the most stringent QA manager, it costs a lot. The CPU cycles and storage space to create, execute, evaluate and notify the volume of tests we are talking about is exorbitant and unlikely to be adopted by your average organization. Truth is, it is unlikely to be adopted by any organization, but there is always some corner case, so I’m being a little vague to keep the conversation focused on the technical issues.

Testing vendors are already working on filtering tools to test only what has changed in the product, but this implies that, at a minimum, this level of testing should not be applied when testing is most needed–during initial development. I might be bringing my baggage along, but I personally prefer focused and curated testing to a firehose that is always on. It doesn’t take much imagination to see a scenario where a full-on automated test filtering tool is off just a little bit, and we get flooded with alerts that are not necessarily false positives but that include information we don’t want to see and consume man-hours needlessly.

Like everything in our recent past, this process will be rolled out too early and then will get tweaked and fixed on the fly, with you and I paying for the privilege of being beta testers, in fact, if not in name. So, I strongly advise caution in adopting new testing automation. I’m super excited by the possibility that all application testing can get the attention it deserves. Still, I am not at all interested in being the experiment on the way to that panacea. So watch the space, listen to other tech folks, and pay attention to how it is working out for them. We have had a tiny percentage of test coverage for so long that waiting for the early adopters to work out the kinks is not going to cause too much additional risk.

As a couple of glaring scenarios have recently reiterated, high-tech vendors are more than happy to do to you in the age of recurring revenue rather than for you. Use caution; make sure that any test automation tool you use aligns with your corporate goals and that the ones you hold subscriptions to are not rolling out massive test automation behind your back. Know your product, and pay attention to any changes in release or license—now more than ever.

And keep rocking it. Soon, we will have effective 100% or near 100% coverage in testing; just don’t rush it. Let the work mature and keep your eyes focused on serving your customers the best product you can without adopting bleeding-edge ideas that might create liability via technology or implementation immaturity. Your customers should thank you, but far too many won’t, so I will for them. Be they internal or external, those who use your systems owe you big thanks for the quality and massive uptime they take for granted.

February 28, 2024
DevOps: What’s the End Goal?

In high tech, we have a penchant for not actually having an end goal. We have interim goals but no grand “this is what we need to do.” And yet, every space inevitably has a “this is the reason” attached. So what should the overarching goal of DevOps be?

We started out with streamlining processes as the goal, and quickly morphed into efficiency and being more responsive–all worthy goals, but it is the nature of both technologists and business people (for very different reasons) to not stop when the goal is reached. We went through several more iterations that all basically pulled more under the DevOps umbrella, and then settled on automation. AI will continue this automation trend, but to what end?

Where, exactly, do we want to go? Theoretically, we could make AI write the code, build the code, test the code and deploy the code with only a small contingent of actual people involved in the process. Seriously, if the idea is to let business people crank things out a la the promises of 4GLs, then we are closer than we have ever been to achieving that goal.

But, much like calculators, someone will still have to create these systems, and we are faced with a different conundrum: If no one is writing new code, learning-based AI will struggle to solve new problems. That challenge can, in theory, be overcome by teaching AI to disassemble and abstract existing solutions, but that will take time.

The other thing that business people and technologists share in the modern world is a lack of actual philosophers. I am a technologist, but much of my immediate family enjoys philosophy. So, I dug into philosophy with regard to science many years ago, and philosophers, being esoteric, ruined their ability to influence scientific thought. Focusing on questions like, “What if tomorrow, we found aluminum that wasn’t really aluminum?” was dumb and undermined the core idea of “Science will tell us what we can do, philosophy will tell us what we should do.”

So we’re on our own in that regard, and given a worldwide development community, we can assume that just because you can, someone will. Our question then is, “What does a given enterprise want and need from their DevOps processes?” The rate of change is about to accelerate again, so knowing what is important to your organization will matter in the next five years. A company that uses technology in support roles has wildly different needs than one that uses technology to develop products, and they have very different needs than a company for whom technology is the product.

Is the goal to eliminate the bulk of IT? Or is it to streamline IT even further and make it even more responsive to business needs? Perhaps the goal is to develop entirely new products or markets with the time that AI has freed up. The difference is huge in terms of planning. And these are the types of questions coming. The idea that any given technology can make things (or make them happen) faster and more efficiently without changing staffing is naïve and ignores the history of the auto industry.

Get together, IT and business leaders. Develop a plan. Do you want to do more with less, or do you want to reduce overhead? Do you want to have IT specialize while AI does the mass of generic work? Level one help desk can be taken over by chatbots today. Is that the type of direction the organization wants to go? Tell IT management that change is coming; the question is, how the organization wants to leverage it and conscious decision is far better than accidental results.

devopsy.kinsta.cloud · No No-Shift, DevOps Jobs, AI Tests Your Code, DevOps End Goal

February 21, 2024
Data Gravity Will Remain an Issue

Things are improving for IT at a rate we haven’t seen since the first wave of container adoption. We have massive automation in the entire SDLC—with AI-based plug-ins for IDEs to help developers write code that is both higher quality and more secure, security deeply integrated into the DevOps toolchain and the unification of testing/security tools across the SDLC. We are once again turning out more code of higher quality faster than we were just a year ago.

And what is finally starting to catch up is data. I love the current iteration of data virtualization technology, where it can be set to move from region to region or cloud to cloud at leisure in the background. At the same time, data that is accessed in the interim can be instantly transferred. I used to cover storage and data, and frankly, this is the dream world.

But it doesn’t change the fact that data location matters. While bulk moving data to its final destination will be useful, separating data from applications that access it is simply adding another weak link in the application infrastructure chain.

This is where the true strength of containers and Kubernetes come in. With Kubernetes, we can put containers with the entirety of our apps into the environment where our data resides. And that means that our application infrastructure is consolidated and that, in a pinch, both application and data can be moved anywhere–because Kubernetes is truly portable (as long as you don’t use customization features of some vendors/platforms anyway).

The environments we currently choose to use for enterprise applications–from mainframe to public cloud and everything in between–all are capable of running containers, and while there are still deployment differences, customizing a bit to move an entire application is far better than rewriting entire apps to target a new host environment. And the amount of retargeting required is constantly going down.

So, decide where you would like to host your solution, use data virtualization to move the datasets there, spin up your apps in Kubernetes at that location and enjoy the fruits of your labors. Mergers, acquisitions, moves from one architecture to another, moving from public cloud vendor A to public cloud vendor B … All made far easier by data and Kubernetes portability.

While people like to call it “cloud,” what we really should be calling it is “portable.” Whichever marketing person decided that cloud included Kubernetes is my sworn enemy, btw. Because the cloud is used without including Kubernetes, so of course, that just confuses the issue. Portable programming is a far better description of data mobility and Kubernetes architecture used in tandem. Doesn’t need a cloud at all.

And we’re headed there for even more productivity. Just pick where to move it and carry on. We do indeed live in pretty cool times, and you all are the ones making it real. Keep up the good work.

Image source: https://vecteezy_businessman-holding-social-planet-showing-networking-skills_1268342.jpg

February 14, 2024
We Will Control the World!

One thing about centralizing control is that there always has to be someone in charge. That can be a very good thing or a very bad thing. In IT, it doesn’t even get far enough to be a terrible thing.

Generative AI and increasing integrations have renewed the insistence from the crowd that it is certain they should control every little thing in your (virtual) data center. The idea that a given vendor should be the configuration and management point for a wide variety of tools – their own, competitors and nearby market tools – has been around forever. Vendors love the idea that they have that level of input into your infrastructure and, let’s be honest, many of us love the idea of having it taken care of for us.

But there are several questions to ask here. First, what is the likelihood that vendor X will have a great level of support for the tools from other vendors in your infrastructure? I mean, before we even get into the idea that this desire for control is not at all altruistic (we’re not talking Stalin here, but we certainly aren’t talking Washington, either), there is the question of how AI will be able to learn about and configure/manage a competitor’s products. Watching wire traffic? Well, if the competitor’s systems are super-well-known and the format of configuration APIs/files are well known—maybe? But this leads us to the real problem.

My advice to vendors would be to get their own products under control first. We work in a high-complexity field where the tools require a lot of specific domain knowledge to manage, and even more to manage well. Vendors have generally taken for granted that this level of knowledge would be available. Before making that level of knowledge unnecessary for competitors or spiderwebbing into competitor installs, make your tool(s) damn simple to use. That doesn’t mean you have to simplify it—you have the power of AI and are going to focus on configuration and management. So nearly eliminate configuration issues with your own products.

Example: “Great Security Tool, I just added an API at https://devopsy.kinsta.cloud/rocks. Please lock it down so it is accessible only to users in the WeRule group, then generate a WAF rule to keep it from being used to access more than three records a day, and only allow GET and POST calls.” Most vendors across the industry aren’t even close to this level of simplicity, so why in the world would you trust them to configure/control other vendor’s products?

There is a trend to make products cover more of the space they are in. This is very big in security right now, but you also see it in DevOps. CI/CD/CDD/VC/kitchen sink (KS)—I’m okay with that, as it does offer us simplified configuration and better cross-app communication. I think this is a better route than trying to serve as command-and-control for an entire tech stack that the vendor does not own. I still want point products and best-of-breed available, but a lot of us just don’t have the time and resources to implement five different products to get the job done—even if they’re “free,” as we all know, they are not free—so one vendor doing an entire chain is great for that use case, and often the shared information about the app, security, the network, etc. can work together better than the sum of its parts. So let’s stay in the “umbrella app” lane and not get carried away with trying to drive in the “manager of the entire world” lane.

We’re busy, we’re tired and many of us are jaded. So don’t tell us how you can manage other vendors’ tools, tell us how you’re making it easier to manage yours. Thanks, from all of us in IT.

February 7, 2024