devopsy.kinsta.cloud

Tag: vendor

  • We Will Control the World!

    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.

  • Dear Vendor: Letter to Technology Vendors

    Dear Vendor: Letter to Technology Vendors

    While I was writing my “Dear Management …” post, something was going on behind the scenes that inspired me to write another. We all have things we wish to say to vendors; this open letter picks some of the big points that they seem to invariably struggle with.

    Dear Vendor,

    We want to use your products, otherwise we wouldn’t even be writing to you. But depending upon who you are, and what year it is, you are struggling to meet our needs.

    We understand that your insistence that your new product or acquisition will solve all of the problems we don’t have is probably executive-driven, but give us the benefit of the doubt. We know our environment, and just because we use you for one thing does not automatically imply we want you to constantly push this other thing at us. By all means, tell us about your entire product line, but then back off. We will let you know if anything appears to fulfill a need.

    While we’re chatting, can we discuss pricing? Not just cost, but the byzantine structures you create, time after time? If you are going to use 15 different charges and fees to jack up the price there, we’re paying the bill – we’ll see it. You’re far better served by being forthright. Do you have any idea how many stories like, “I am not funding your Ferrari with your commission,” stories (this was actually said; it was hilarious – we went with a competitor) are out there? And they keep occurring. Just this week, the phrase “Your pricing is bonkers!” was submitted to a company. We want a good product at a fair price, not a cheap price up front that will drain all of our budget over time.

    Speaking of good products, let’s talk about security. Security issues with your product are our issues more urgently than they are yours. Don’t mess around; when notified, quantify the threat and notify us immediately, with suggested remediations until you can get a patch ready. Holding off until you can patch puts us in the unenviable position of being vulnerable and, worse, not even knowing we’re vulnerable. Use good coding practices so we’re not all caught off guard, and waive those secure coding requirements for no one. Interns and C-level execs are not professional coders (interns aren’t yet, and C-levels no longer are), and any code by these two groups needs to be reviewed by someone that knows your systems before they are sent to us for deployment. Don’t force bad updates on us. Do your best not to give us bad updates at all.

    Finally, on the topic of forcing things on us – guess what? We have a need for a specific tool in a specific environment. Telling us that starting next month your services are all “moving to the cloud” does not suit all of our needs. We get it, you want that data. It’s all the rage right now. You should understand that, if you stop serving our needs in your quest for our data, we’ll go elsewhere, eventually, no matter how reluctantly. Cloud is a great platform, but most IT tools need the versatility to run where we need them, not just on one platform out of many.

    And, as a side note, your AIOps generally isn’t. We know it’s the buzzword du jour, but honestly, if it’s basically the same product with some logic or a dashboard strapped on, that’s not AIOps, it’s normal product improvement. When you have deep data collection and analysis that uses trained algorithms, then you can join the crowd screaming AIOps. Until then, hush. You sound silly, and it undermines the rest of your messaging.

    Just to reiterate: We have a need, show us how you fill it, and let us decide if that suits our requirements. Then tell us about your other offerings and back off. We’re smart enough to smell vaporware, stubborn enough to resist your desire to collect all of our data and wise enough to judge whether or not you and the product you’re pushing this week will be around in a year or two. You serve a purpose, and we’re grateful you are doing this stuff so we can focus on our business. But please, make life easier on us, not harder. And if one more of you sells a product we don’t need to the C-suite, we may explode. That Sword of Damocles that you raised over us will inevitably fall, and your company’s reputation will suffer for it. But we’ll pay the price for trying to implement something we didn’t need in the first place.