devopsy.kinsta.cloud

Author: Don Macvittie

  • Training and Certifications: Get It, Don’t Sweat It

    Training and Certifications: Get It, Don’t Sweat It

    At my company, we’re pretty big on continuous learning. It’s not so much which corner of tech you are learning about, as that you are expanding your professional horizons. Knowing that many of you are the same way, I thought I’d offer some insight into the state of online education and online certification in the wake of COVID-19.

    As luck would have it, just as COVID-19 was gearing up, my company purchased a CBTNuggets subscription for me. This is a sweet benefit if you like to learn about areas of IT that you don’t normally work in, or brush up on bits you do work in but want to get more out of. The only reason I prefixed this with “as luck would have it” is because COVID-19 has brought a lot of change to the training and certification market—most of it for the good of users.

    Pearson Vue is now offering online proctored exams. For those who sponsor the certifications, they have a choice about whether to participate with online examinations or not. Some do, some don’t, both for good reasons. Check if the exam you’ve been waiting for is available online now. Considering CompTIA testing is included in Pearson’s options, this is worth checking out. Note that Microsoft is also a VUE client, so an increasing number of MS exams are available online. This was in-process before, but is accelerated due to the current situation.

    DevOps Institute has long done online exams, and offers a worthy collection of certifications to look into. In fact, there is a lot of free (or registration-only) training on the DevOps Institute’s sight, not just certifications. It is definitely worth checking out.

    Cisco has expanded online testing for many of its exams. Now might be a good time to take that exam you just couldn’t get to a testing center for.

    We paid a fair amount for CBTNuggets, but if learning (as opposed to certification) is your goal, it’s worth the money if you/your employer are willing to shell it out. To the point, the fee is one-off. Use all the training you want for the annual fee, so the value is limited only by your available time and motivation.

    Some of us in IT really don’t have that much free time right now, as supporting a suddenly huge remote workforce is a surprise burden, but if you are one of the lucky ones that isn’t struggling with an unexpected expansion, now is definitely a good time to enhance your skills and learn some new things. The CompTIA Linux courses are a good place for Windows fans to start, and the introductory Windows Admin courses are a good place for Penguins to start. But you all know that.

    Note that there are a few organizations out there that do not want to participate in online proctoring or testing because they worry about cheapening the exam because leaks of exact questions are far easier in an online setting. Don’t be too hard on them, they want to preserve the value of their certifications for those who have earned them–a worthy goal, whether you think it wise in the current environment or not. I know of two organizations that fit this category, so I thought I’d mention it.

    Stay safe, keep rocking it and hopefully you have some time to pick up some training or certifications.

    Note: This list is just things I am aware of. Please leave any other training options as a comment and help your fellows out.

  • Keys to the Kingdom: Protect Your Server from Hackers

    Keys to the Kingdom: Protect Your Server from Hackers

    Automation and DevOps undeniably improve the agility and responsiveness of IT. Most of us have taken up at least a bit of the wave of automation that DevOps and Agile have brought to our door, and many are far along on their DevOps journey.

    But every once in a while, we need to look back and lend a hand to those still coming. The fact of the matter is that sometimes we forget to warn those who are new to massive automation about some serious issues.

    It is intuitively obvious, if you think about security at all, that putting together a command and control server—we’ll use Ansible in this blog, but any tool that can roll out applications to a collection of servers—creates a big screaming target for any hacker that gets into your infrastructure. You cannot assume that will never happen, so organizations need to think about protective systems/architectures early, or spend more time patching things up. Remember, the more you build, the more weight there is to making major changes.

    For starters, severely limit access to the command and control machine. It belongs on a management subnet/VLAN with only a few access points. The servers it is managing absolutely should not have access back to the command and control server. If they do, any one of them getting controlled will provide a pathway to all of them getting controlled.

    Next up, early on there were quite a few debates/discussions about which user accounts should be able to run command and control scripts (Playbooks in Ansible). Eventually, the bulk of the community settled on each individual running them, not a single generic user with a name like “ansibledeploy.” Some still use a central user, but the majority wants the ability to track down the leak that individuals running commands allow—searching for strange/uncommon command execution in logs will cough up which account got compromised and allow for rapid response—which outweighs centralization.

    Third, learn and use the security features available in your application. Ansible offers Ansible Vault to allow encryption of playbooks. Since many playbooks require root access, encryption allows those playbooks to hide root access. Use of Ansible Vault has grown over time, and there are excellent tutorials out there to help use it to lock down command and control. Your product will have a similar tool, because putting root passwords in plain text, all over the disk, is just not acceptable.

    In the Ansible Galaxy/Github repositories, you can find excellent roles to help in your quest to lock things down. Geerlingguy is one of the most popular, and his Ansible Role – Security is excellent if you follow the caveats he provides in the readme.

    This is simply an advisory, not a step-by-step solution set. Overall, just remember that putting together a command and control server makes a tempting target. And like Geerlingguy points out in his readme, your security is your concern.

    Look at where the server can be accessed from, who can access it, where sensitive data bits such as passwords are stored—hint: plain text passwords in files went out of fashion when mainframes were hooked up to LANs—and how to protect all of the above. It’s been done, there are plenty of resources to help in your given environment. Take the time to look them up and implement relevant suggestions.

    After all, I won’t get a call in the dead of night if your servers are all taken over, you will. Do everything you can to avoid getting that call. And keep rocking. Everyone remote working has made many organizations more susceptible to all forms of attack, don’t let your guard down.

  • In IT, Purity Is Not Necessarily a Virtue

    In IT, Purity Is Not Necessarily a Virtue

    Throughout the history of IT, we’ve had our share of purists. OS purists, language purists, etc. The stark one was the “That is not Object Oriented Programming” crowd. While the poster-children of IT purity, we don’t really hear from them anymore—and thank goodness for that.

    But a new crowd has reared its head in DevOps specifically, development more generally. They don’t believe there is ever a reason to modify a running container. Call them deployment purists, though maybe one of you has a better term.

    Like OO purists, this approach ignores the reality of the environment we work in. Yes, the best option most of the time is to fix an issue and roll out a replacement container. But, the fact is that claiming anything else is not using containers “correctly” is patently wrong. My go-to example for why I say this is the easy one, because explaining complex infrastructures while trying to make your point is a waste of time.

    Rolling feature releases in most organizations that do them regularly are achieved with environment variables on feature tags. But changing an environment variable is changing an instance. So, are all these organizations wrong, or perhaps the idea of purity is the problem when it comes to IT? Certainly, the driver for DevOps in many organizations was that purity had created islands of toolsets with varying delivery timelines and quality controls.

    I contend it is past time to let purity be a guideline instead of a mantra. Yes, in most situations rolling out a new instance is the correct response, but in many–live applications that will drop connections and lack enough redundancy to bleed users off, for example–the correct solution is to modify the instance. “Never change production” is a good mantra, but it is a terrible purity test. We should avoid it, while acknowledging that not all situations allow us to make that choice.

    Keep on rocking it. We’re weeks into COVID, and I can hear the stress in my operations friends’ voices. Know that the rest of us are grateful to have you keeping things running for us and bending over backward to make certain we have the access we need. Thank you, from me, for all of the people relying upon you.

    — Don Macvittie

  • DevOps Institute Upskilling the Enterprise

    DevOps Institute Upskilling the Enterprise

    DevOps Institute released its annual Upskilling the Enterprise survey and the results are as interesting as last year. The organization of DevOps teams and its interaction with speed/success was one area that intrigued me, and sent me off looking for more information on the topic. This led me to this interesting site that does a great job of delving deeper than “We’ve all heard of Conway’s law.”  Good descriptions there on what works and why that will be useful to many organizations. The only true weakness in the content that I found was the “vacuum syndrome” that doesn’t delve deeply enough into what’s right for your organization, which certainly impacts your choices.

    DevOps Institute’s discussion of soft skills and DevOps roles being hybrid is also interesting. It creates a bit of a conundrum. We all wish the technical genius was also a charming personality, but often that is not the case. In the end, our job is technical, and we need to deliver technical solutions. There is a balance between making the genius more personable and finding personable people capable of achieving the goals. Considering that hiring is currently a struggle, we often do not get to choose. Training can help a lot, and in the end, finding a balance that works for a given organization is going to be a bit of work for management.

    What comes as no surprise is the finding that CI/CD are the entry level required skills for DevOps. No matter how far along on your DevOps journey you are, CI and CD are core to the job at this point. Expect that to change over time as deployment and security become more core and commonplace. In the end, great CI/CD is not much help if deployment and monitoring are weak, so the tools that win these battles will rise in importance over time without taking away from CI/CD.

    Their idea of the E-shaped human is interesting, but in diagramming, some detail is lost in the abstraction.

    I once worked with a super-genius DBA that could do anything with the database. We (managers) met with him on issues and let him tell us how impossible it was and that we were destroying the enterprise’s data integrity. Then gave him a day and let him tell us how it would get done effectively without major disruptions. Only after we’d met with him the second time did we move forward with the project, talking to business owners. Essentially, we became the wall between him and anyone who would be put-off by his face going red and his angered declarations. It was an acceptable arrangement, and he never let us down. I worked with him on dozens of projects, and only once did I see him exposed to outside consultants (against the wishes of several of us), it was ugly, and they pegged him as a stone-waller. He wasn’t, just needed to vent first.

    This person was responsible for the stability of our data, for upping the volume of throughput when needed and for making sure SQL didn’t get past DBAs without being safe. Would we have liked him but with a sunny disposition? Sure, but given a choice, I for one was happy with him and an angry disposition. I worked other places I wished I had someone with his unparalleled skills on the DBA side. So, all of IT needs to get better at interpersonal communications in a DevOps world, but “better” is relative. I’d still keep him in the back, making sure our systems got what they needed.

    The survey head-nods to this reality where soft-skills came in third as important skills. Still high on the list because it is important, but it shows that technical skills are why we have the job. Soft skills are how we do the job with less friction.

    Considering that I am the communicator/negotiator, it might sound strange for me to stand for tech skills first, but that is who we are–technicians. Highly skilled and highly compensated, but technicians. There are few (as a percentage) people who can handle both technical and communications, but by the same token, there are few people who can be an absolute boss at their technical responsibilities and see each unexpected event as a challenge to be overcome. I love to learn new things, and at that job I learned a ton of Oracle stuff from our tech genius. But I would be foolish to believe I’d ever match him in both domain and tech knowledge when it came to databases and our employers’ needs.

    Anyway, I picked three of the points that interested me to expound upon. The entirety of the report is definitely worth a read to get a feel for where others are on their DevOps journey and offer some ideas for yours.

    Meanwhile, keep kicking it. We’re in the midst of COVID-19, and I hear you, some of you are simply buried in organizations that weren’t prepared, others are suddenly looking for work because your previous employer is suddenly not a viable business. Here’s hoping it gets better for each of you, while the rest of us struggle on.

    — Don Macvittie

  • We All Have to Have Standards

    We All Have to Have Standards

    I was working on an e-book recently about the state of the market for certain DevOps toolsets, and got really interested in how standardized organizations are becoming. We have been on this roller coaster of changing technology and different teams making different choices in language, libraries, platforms and toolchains. We all knew that couldn’t go on forever, but I started to really get into the idea of “How much standardization is being introduced?” While talking with vendors about their experience, it seems that enterprises are finally attempting to standardize, at least in the platform and toolchain areas.

    Not the type of “technology by edict” standardization we used to see, but a checklist of “If your project fits these criteria, use this platform. If it fits those criteria, use this toolset for your build chain.” Which is a good compromise between the days of “We’re a Cisco shop” or “We’re an Oracle shop,” and the days of “Yeah, first developer on a project chooses the language, database, etc.” You limit the amount of technical debt and vendor/OSS project dependency, while offering teams options for how best to get the job done.

    I’m excited about the change, and it is one of the things driving much-needed consolidation in core DevOps markets. I won’t go beyond that, as you’re supposed to read the e-book when it gets released, but it’s an exciting time to be in DevOps. We’re getting more and more tools, better integrations and even some full lifecycle toolsets starting to become clear.

    Our shop is small, and we’ve exercised standards all along, just because we don’t have the time for everyone to train on five different CI products, so we use one. But for larger organizations with more diverse needs, standardization will offer savings in both maintenance and cross-training.

    Consider that at one point there was no standardization on vehicles–everything from tires to engine oil was custom to the brand you owned. Now, it is quite often the case that the engine in your vehicle is the same engine as in a competitors’ vehicle (VW using Saab engines for years is a good example), and that means maintenance is streamlined. Tooling with onboard computers makes maintenance even faster, much like tooling monitoring/reporting is doing for the DevOps iteration. It’s a good time to be in the field, watching as things unfold.

    Stay aware of what your vendors are doing, and what their competitors are doing. One of the reasons DevOps exploded is because tools and processes became static and weren’t as productive as they could have been. Don’t repeat that mistake, keep an eye on rapidly changing developments and adopt what suits your organization. You’re rocking it now, take a bit of time to make sure it stays that way.

    And consider standardizing some of your toolset. The fewer tools to maintain, the more time to work on productive issues. And the fewer toolchains a DevOps team member has to know to be productive on multiple projects, the more productive they can be. Agility applies here also.

    — Don Macvittie

  • How to Properly Approach Automation

    How to Properly Approach Automation

    Imagine if you backed out of your driveway, tapped the gas and BAM! You are at work. Nothing to worry about along the way, no traffic congestion, no other cars to worry about, etc.

    That is, unfortunately, how many of us approach automation. “Fire and forget” is real, until a problem crops up. I could talk about some complex environments, such as ARA, in a containerized environment with multiple languages, accessing mobility-limited databases and targeting several client platforms, for example.

    But we’ll keep it simple, and I’ll make an admission. Backup was one area where we at Ingrained Tech fell into the fire-and-forget trap. One part of our backup system runs desktops out to a server, the server (and other servers) out to a NAS and the NAS out to the cloud. I don’t think our security peeps will freak out if I mention we use duplicity for this backup and Backblaze for our backup cloud. Backblaze is a dream to use compared to others we’ve looked at, and the pricing is competitive, so it suits our needs well.

    A few weeks ago, we realized that while backups were completing successfully and verification was fine, it was taking nearly the entire week to do our weeklies. That’s bad news. We back up terabytes of data, but this is 2020, and our drive IO/Network can handle it. We started by looking at both of those things, and sure enough, it was drive IO causing our problems.

    Unsurprisingly, reading the disk and creating a collection of encrypted tarballs (a super-simplification of what duplicity does, but gets the point across) on those same disks was causing problems. After investigating, the one build that occurs on that server was suffering from backups stretching out, too. We had seen occasional issues with the build, but nothing jumped out as the source, and it was only one night every month or two. It was on our list. You know, the same prioritized list you have. And this build wasn’t nightly-critical. You get the idea.

    This was a relatively urgent problem, as soon as last week’s backup would not be complete when this week’s tried to start. Not good.

    We took our DevOps mentality to the problem and discovered a simple solution that solves the issues. The backup NAS is RAID 50, so it can handle a lot more abuse than the server that was slowing down backups. So, we took the simple expedient of rsyncing the source server to the NAS, then using duplicity to tar and encrypt before sending it on to the cloud buckets. Internally, we do not believe we need to encrypt backups because if someone is in our network, all of that data is laying around. By putting duplicity and both the tar function and the encryption function onto the backup NAS, we moved it to a far less busy system. Backup times dropped from days to hours instantly, and our unrelated build problems went away.

    We have to rework the automation somewhat to make sure validation is, well, actually validating the data is correct. But we’re well on our way to having a stable, faster system.

    How does this fit with DevOps? We see the same thing happening often in the automation rush of DevOps. Yesterday’s best solution is not necessarily tomorrow’s best solution. “Automate and watch” should be the catch-phrase. Improvement comes from both DevOps culture and paying attention to changes in the tools market.

    As Alan pointed out, someone will eventually win the end-to-end DevOps rush—since I feel the urge to inject my opinion on who stands the best chances, expect a blog on this topic soon. Until then, knowing what your options are and how to best achieve your goals–even on problems that were “solved” last year–is your best path for continued improvement. Yes, it means rework, but just like reworking your code, the point is to streamline things, get closer to your organization’s goals and keep improving after the low-hanging fruits of DevOps have been gathered. The rate of improvement in several areas of DevOps is stunning, so you may find you actually like a new tool better than the one you chose a couple years ago. And remember, knowledge is power.

    — Don Macvittie

  • COVID-19: Don’t Sacrifice DevOps

    COVID-19: Don’t Sacrifice DevOps

    Like everyone else, I’ve been following COVID-19/Coronavirus issues. My focus is more on the IT impact of the disease and its status as a pandemic.

    Let’s start by saying it isn’t the end of the world. Yes, it’s serious. Yes, it will be disruptive. Yes, those impacted by the worst aspects of the disease will leave a hole. But when it is over, and the tide has swept by, the vast majority of people will still be here, still trying to do what they need to do.

    That includes ITOps/DevOps maintaining whatever you put in during the rush to work remotely. Some organizations will be happy to throw something up and then rip it back down, but most will not. Once they’ve worked out how to work remotely, they’ll want to keep that as an option. Some to offer more work/life balance to employees, others to have a backup plan in case of emergency. Ask any company in Katrina’s path, remote work plans born in emergencies tend to hang around.

    It is the nature of DevOps to be nimble and reactive, planning on improving things as time goes on. That’s a good feature of both DevOps and modern IT teams. But some things are less nimble than others, and the rush to remote work is going to show that in a hard way.

    The VPN chosen or expanded to enable remote workers is not likely to be swapped out easily or quickly. While there is a sense of urgency—if you follow /r/sysadmin or to a lesser extent, /r/DevOps on Reddit, you know that urgency may even be too gentle a word. Some management teams seem to be in panic mode—you are going to have to live with some of these choices for a while, don’t make them knee-jerk.

    Normally, an MSP is your friend when moving like this, offering expertise and knowledge your organization doesn’t have internally, and shortening both deployment and the learning curve. But consensus is that MSPs, laptop manufacturers and VPN vendors are going to be booked solid for the near term.

    So, choose software when you can. Not because software is better (truly for some functions it is worse), but because it is generally easier to replace. A software VPN can be expensive, but you’re not buying hardware that is a sunk cost. Consider short-term solutions such as Amazon Workspaces or possibly  Chrome Remote Desktop, old standbys like VNC or RDP (likely with VPN in both cases), file sharing with things such as Sharepoint or OneDrive. Later on, you can look at a Cloud NAS such as Nasuni, or a more solid remote access plan.

    Yes, all the suggestions above have things you need to worry about. No, not everything will be within your control. However, these things are easier to rectify on iteration than “We bought big solution X, and it doesn’t do Y, so we need to replace it.” Start with short-term solutions and improve them as you go–this is truly the DevOps way, but it is easy to lose as you’re looking for high-volume, perfect and urgent.

    IT workloads (particularly operations workloads) are going to increase for any organization that wasn’t already set up for broad remote work. There is no way around this fact. As someone suggested online, “Kiss your family, tell them you’ll see them in a couple months and get to it.”

    You’ve got this. The internet is loaded with information to help, places such as Spiceworks and Reddit have people willing to offer advice all day. Smaller MSPs are likely happy to talk with you as they attempt to grow their business. Determine what you need, how fast you need it and implement the best solution you can in the time available, aiming to improve it on the next iteration. And keep the wheels of business running.

    It’s a flu variant, not the black plague. Businesses that deal with this well will come out well. Right now, “Deal with it well” includes a lot of IT work: from continuity planning, to fast DevOps iterations, to getting people at home productive and supporting them through this.

    — Don Macvittie

  • You Still Have to Make Time for Maintenance

    You Still Have to Make Time for Maintenance

    I’m going to take a side trek today into home computing with applicability to IT. Bear with me.

    We maintain a pretty complex home network, as home networks go. With three NAS servers, a small one-box SAN, some web servers and connections to several hosted environments. We both work from home, and my business is contained in one of the NAS servers and some of those hosted environments, so it’s all necessary. Scheduling downtime with several people using the network darned near 24/7 is difficult. Not medium enterprise level of difficult, but still an issue.

    Two of our NAS servers each have a disk out. It happens, that’s why they’re NAS servers. In general, the only day that replacing the disks makes sense is Sunday, when things are a little slower (both in schedules and network usage) than normal. One of our web servers is just plain dead–but there’s info on there we have to get off. The code is mostly being replaced, but the data is collected over years and we need to see how much we can salvage.

    None of these things are shiny DevOps things. Yet, they still have to get done. Importantly, they have to get done when automated tools aren’t running across the network or counting on the NAS to be responsive. The rush isn’t huge, because there are off-site backups, but restoring a remote backup is a long-term proposition–weeks, not days in our current environment–so it must happen as soon as practicable.

    Don’t forget that with the drive to automate everything. If you own the hardware, it’ll need maintenance. If you own the software, same thing. If you need data to move platforms, it will take time. All things we kind of hand-wave in the DevOps world. They’re seen as bottlenecks, if seen at all. Generally, we don’t even consider maintenance issues until they impact DevOps, but we know they are going to happen so we should have a plan for how to deal with them.

    Those few of you whose entire environment is hosted in a cloud provider have an easier job of it, but eventually you will be asked to move cloud providers. As sure as the sun will rise tomorrow, something will drive a move away from your chosen platform. Normally TCO, but other factors play in, too. When that happens, the work will be more than “Find time for the NAS to rebuild without overly impacting everything else.”

    So, spend some time thinking about it. Do you have plans to make room for maintenance? Are you scheduling maintenance into release cycles? Are you coordinating releases with updates that are not required by this specific release?

    This is where dev (typically Agile/Scrum) meets ops (typically system/network maintenance), and it is every bit as important as what is normally seen as DevOps. Get it right and have fun, keep cranking stuff out. Get it wrong and struggle with the problems infrastructure issues can inflict upon your cool new update. One of our new websites outright stopped development when the web server went down–for a variety of reasons, but the catalyst was the loss of the original. We’re working out what to do about that.

    Meanwhile, we didn’t make time yesterday, so I’ll be replacing disks and tearing apart a web server in a much smaller window that is available today. See you when I poke my head back up. Hopefully, you’ll have better planning than we did.

    — Don Macvittie

  • The Right Toolchain Is the One You Build

    The Right Toolchain Is the One You Build

    One of several iterations that IT likes to go through is corporate standards for technology versus best tool for the job. We like to have standardization because it allows staffing portability between projects, but we like right tool for the job because from the moment you choose a standard, competitive factors and changes in needs make the standard less of a big win.

    DevOps is still struggling through this process, particularly in enterprises where standardization bears a bit more weight on important projects.

    The fact is that DevOps is well suited to the idea of iterating standards–somewhere between a wild west of everyone using their “right tool” and an organization dictating the tool of choice.

    Most of us use Jenkins, because it does what we need it to do. What needs doing is different from organization to organization–some use it for continuous testing, while others go all the way through application release automation. But the fact is we could iterate and replace some, or all, of the functionality we’ve decided to use Jenkins for tomorrow. Kind of like a “We have a standard that is evaluated regularly” approach.

    For those new to DevOps, the array of choices is downright bewildering. Xebia Labs has a toolchain diagram page to help those already doing DevOps, and several sources have spreadsheets/PowerPoint templates to help you work through your existing environment. While all of the options these tools try to organize for you are great for the industry to find better solutions, it makes for a confusing mess. Your toolchain could be all AWS with some scripting, all Jenkins with plug-ins or 15 different apps working independently. A surprising number of organizations are even using Git for the bulk of their toolchain.

    What matters is that you know what you have, and know what your options are. Build the best toolchain for your environment today, and keep half an eye on it to be aware when something more suited to your environment comes along. We still maintain python scripts that do a fair amount of our automation, but several toolsets in place also.

    There are objectively better tools out there, but for our purposes they are almost universally overkill. So we go with what’s best for our environment. As time has gone on, we’ve integrated more and scripted less, but it will be a while before out toolchain is actually just tools–if ever.

    If your toolset is doing the build/test/deliver/deploy cycle well enough, you’re covered. If it’s not, you need to look for alternate solutions. Even if it is, make sure you’re aware of what’s on the market and not just what’s “hot” right now. Be aware of those companies that are up and coming, maybe in spaces that are already flooded. What differentiates them, and in our environment would that differentiation matter? That’s all you need to know–there is no need for a super deep technical evaluation, unless you’re actually considering them. Just enough to know if their differences add value.

    Keep cranking out the apps that make business run. Perhaps with an updated toolchain, perhaps not. In the end, what works for your environment is all that matters.

    — Don Macvittie

  • Never Ignore the E-Factor

    Never Ignore the E-Factor

    When cloud burst upon the scene, we were treated to wild-eyed prognosticators telling us about the death of the traditional data center. This is a trend in IT that you would think we’d learn from, but we repeat every couple of years. 4GLs, no, XML, no…Were all going to end development, and yet here we are, with more lines of code and more programming languages in use. It just keeps happening.

    These all share two common failings. First, technology in use today may not be perfect, but it is getting the job done, so dumping it for the new silver bullet is an unlikely result either in the long or the short term. For example, we’re many iterations beyond the conception of the C programming language, and yet for some purposes it is still going strong–because it does the job.

    But that’s a little tangential to today’s discussion. Today, the other failing is where I’d like to focus. The E-Factor.

    Enterprises are a lot of things, but one of the things the successful ones are not is careless. Cloud use in the enterprise was always going to be both multi-cloud and hybrid. Why? Multi-cloud because sole supplier arrangements are riddled with possible issues, and hybrid because every enterprise has something they want to maintain sole control of or something that simply can’t be moved but they want to push toward newer environments.

    We were always going to have multiple choices, and successful enterprises were always going to use multiple of them. Containers facilitate this truth a lot. The ability to run containers pretty much anywhere makes them portable, as long as staff is familiar with the infrastructure of a given environment so they can support the container management system in that environment. But even without containers, a cloud portability solution was inevitable.

    There is a massive amount of automation going into IT right now, all for the good. Freeing up traditionally scarce IT hours to focus on more and better services is all to the positive. Inevitably, one or more of these automation tools will be hailed as “The End of X.” Ignore them, and keep rocking at your job. AIOps seems most likely to gather this type of following right now. It will offer a flood of new data and consolidated views of that data, but not much else in the near term. Even when decisions start to be automated, full-on automation based upon AIOps feedback still needs code to run against and infrastructure to run on, so no doom and gloom there.

    Apply the E-Factor to anything hailed as a silver bullet. If you’ve worked in the enterprise, you know there are so many variables in the datacenter that any silver bullet would have to be a splintering round, each splinter behaving in a completely different manner to address current IT needs. More options are always good, and I, for one, go after new tech because I’m non-stop curious. But it is indeed just more options for your IT needs. Use the ones that will help, ditch the ones that make things worse and ignore the cheering “This time we mean it!” crowd.

    — Don Macvittie