devopsy.kinsta.cloud

Tag: continuous optimization

  • Optimism Matters and so Does a Sense of Wonder

    Optimism Matters and so Does a Sense of Wonder

    I’m a terrible video game player. For as much fun as people have with me at the table for Table Top RPGs (TTRPGs), I’m a pain when playing video games.

    As a guy with a masters in computer science, and years of experience ranging from embedded drivers to enterprise architecture, I see bugs or bad design decisions in video games and they tweak my sense of right and just. Ask my wife and youngest about playing Fortnite with me, you’ll get an earful. My wife uses her masters to analyze what could have happened in the code, and why it’s understandable. I fume and say “Yeah, well the code–not me, not the other guy–just eliminated me.”

    In short, I’m jaded where video games are concerned. As a casual gamer, I see the bad even while the good all around is rocking–EPIC devs, you’re doing a great job, particularly with the rate of change the game sees. Gamer rage is about the occasional oddity like getting stuck waist deep in the snow. Or about things beyond your control, like Skill Based Matchmaking that isn’t.

    I’ve noticed a trend in the portions of DevOps that I keep an eye on lately–fatigue. A sense that the change is non-stop, and the volume will just keep increasing. It only makes sense, we’re knee deep in sea change and new terms, products and processes seem to crop up on a daily basis. It can be wearing. Just looking at requirements for jobs–there is the persistent joke about 2000 years’ experience in Jenkins for a reason–it shows a fractured and constantly changing environment that begets unrealistic expectations.

    This has a tendency to make people jaded about new technologies and techniques. After all, Agile and DevOps have brought a huge return on investment, the law of diminishing returns might be kicking in, right? And lots of new shiny have turned out to be smoke and mirrors.

    The thing is, the rate of change in DevOps is still moving so fast because there is still more to gain. Continuous optimization, aka AIOps, is cool and promises a lot. Automated testing is still ramping up, even though automation of build tests is solid in most environments. Other kinds of testing (security, regression, live and even A/B) are still lagging, and test automation is offering help.

    What we need to do is try to keep that sense of hopefulness that we embarked on DevOps with. New tools might give us an appreciable ROI. They might free up time for time-constrained teams, which is the best ROI you can hope for. New processes might address shortcomings in existing ones. Will new tools and techniques always pan out? No, your environment is unique so even popular tools or techniques might not be best fit for your particular organization/apps. That’s okay, keep poking around at what’s new and remember the wins.

    I’ve got like a 4% win rate in Fortnite. Those other 96 games out of a hundred? All learning experiences to (hopefully) increase my win rate. Same with evaluating new tools. The failures feed the successes. It’s far easier to go “Product X didn’t work for us, and this is very much like it. Let’s look closely before even trying a pilot.”

    While there are more people in IT these days by conscious career choice, the bulk of us are still here because of the wonder moments–first time you got code to compile, spun up a cloud instance, figured out network segmentation or divided physical disk into partitions. The same sense of new and exciting should be brought to the current set of changing technologies, while still rock-starring your job. After all, it is some pretty astounding stuff we’re getting to play with every day.

    Maybe I’ll take my own advice, chill a bit when playing video games. After all, that’s another space that has jumped light-years in quality and availability.

    — Don Macvittie

  • Continuous Optimization: An Idea Whose Time Has Come?

    Continuous Optimization: An Idea Whose Time Has Come?

    Agile makes development deliver code faster. CI makes testing move faster and CD makes delivery faster, but what keeps track of the volume of change all of this introduces and delivers optimizations faster?

    That is the question Opsani wants you to be asking. And it’s a valid question. Optimization in a complex and constantly changing software world becomes more important–if it can keep up. Opsani thinks it can, with a little AIOps to help anyway.

    The premise is simple. There are ways to adjust the environment that might increase performance and/or reduce costs. Those ways are individually relatively simple (such as JVM settings or cloud instance sizing), but combined they make a complex web that impacts performance as a whole, with individual bits sometimes helping and sometimes hurting.

    Up JVM memory on a large instance and it might help. Switch to a smaller instance later, and that JVM change may cause problems on the smaller footprint, for example. So something more dynamic is needed. As code changes, best optimization options might change also. As the other parts of the environment change, that magnifies the concern that applications are not running at their best and might be costing too much money.

    Opsani’s answer to this problem is continuous optimization. Using AIOps to check different combinations of settings at a rate that operations staff couldn’t manage even if they did have the time. And they generally don’t.

    From my (not their) perspective, there are two pieces to this puzzle. First is gathering inputs and determining performance, second is tweaking settings. Then repeat. Seems simple but the environment continuous optimization would work in is increasingly complex. Any look at how many places optimization can occur in a given environment–from VM/Instance to code to network to management platform to storage/database choices–there is a lot going on, and all of these settings can impact each other.

    Hence the idea of continuous optimization appeals to me. They’ve got the interfaces that one would expect to gather inputs, names such as Jenkins, DataDog and New Relic. They’ve got the interfaces to enact and test out changes too, with interfaces to products such as Kubernetes, Terraform, Rancher and Wavefront. So it certainly appears they’ve got the basics covered. Of course there are vendor interfaces I’d like to see that aren’t in the list of integrations, and no doubt the same is true for you. But the core is here, getting to the monitoring and management tools most companies use regularly.

    Opsani seems to be aware of the different comfort levels of various organizations, also. Able to run in dev or test as well as production. Since every organization has a different taste for putting new ideas into production, this is a good idea, though personally I would aim for eventual production rollout, just because that is where the rubber meets the road. Having it running as part of normal operations means even that small change that reduces responsiveness of your application by 25% (we’ve all seen it) will be detected, and Opsani can try changing some of the environment to compensate.

    When I spoke with them, we did not discuss cost, but we did discuss savings. For budget-sensitive environments, it is worth looking into the cost in your organization versus the potential savings in actual monthly dollars. Here is a screenshot showing the cost measure combined with the performance measure. Reducing monthly overhead to pay for a tool that also improves performance might just be a no-brainer–if it suits your environment.

    I can’t say if it suits your environment, nor can any other analyst/pundit. That’s for your organization to decide. But the idea of continuous optimization is a good one. Opsani is not alone in working on this problem, so even if this particular tool doesn’t suit your needs, you can look for others that do. I recommend getting the demo and seeing what they’ve got, and how it might help in your environment.

    — Don Macvittie