devopsy.kinsta.cloud

Category: Features

  • Survey Finds DevOps Teams Under Increasing Pressure

    Survey Finds DevOps Teams Under Increasing Pressure

    The fact that a much larger percentage of companies now recognize they are software companies that happen to specialize in a specific vertical industry is now putting a lot of pressure on developers, according to a new survey of 750 development team leaders in the United States and the UK conducted by Testplant, a provider of tools that automate application testing.

    The survey finds that 42 percent of the respondents claim they are expected to design, develop and test apps in an unrealistic amount of time. More than one-third (36 percent) also report they are not given enough time to ensure apps are properly tested before deployment, while 56 percent note that use of outdated techniques and tools is holding them back from meeting the demands of the digital world.

    Because of this combination of factors, nearly half the respondents (49 percent) say they are deploying applications before they go through an ideal testing amount of testing, and 45 percent admit to putting applications into production that will perform below initial requirements.

    Dr. John Bates, CEO of Testplant, says it’s a matter of time before IT organizations will have to rely more on tools that automate much of the testing process, as pressure on DevOps teams to roll out new applications and update existing ones is only going to increase. The survey respondents (60 percent) say most of the pressure to accelerate software development is being driven from within the organization itself. But nearly half (49 percent) say pressure comes from competitors. As more organizations realize their competitive differentiation comes from the software they develop, there’s now a lot more focus on accelerating application development, says Bates.

    The survey also notes that the applications being built are more complex than ever. Over the next 12 to 18 months, half the respondents (50 percent) say their company will develop more apps using components for an internet of things (IoT) environment. Well over half (58 percent) also say their company will develop more apps with artificial intelligence (AI) components, and 62 percent say their company will increase the amount of applications that incorporate machine and deep learning algorithms.

    When it comes to deploying applications, automation is ranked as the most critical challenge by 67 percent of the respondents, and 70 percent claim they are now more focused on automated testing today than they were in the past.

    In total, 75 percent of the respondents say that with access to better tools, the applications deployed by their team would have a greater impact on the business. A full 81 percent also say that with more time, applications deployed by their team would have a greater impact on the business.

    Unfortunately, more time for application development is luxury most business don’t have today. Not only is a wave of digital business innovation is making it easier for startups to not only enter markets, but companies that traditionally have focused in one market segment are now extending their reach to adjacent areas. The difference between surviving and being made obsolete now comes down the level of customer experience an organization can deliver by the applications it makes available to customers.

    Unfortunately, when it comes to those applications, customers tend to be unforgiving. Once bad application experience and many of them will move on to try an application developed by a rival. Bates notes that too many organizations still seem to think they can test their applications on end users on the assumption they can fix any issue that comes up rapidly. In reality, rather than participate in what amounts to an extended beta testing process, most end users will simply look for a better alternative application experience.

    In short, the difference between success and complete failure now hinges on the level of quality application testing that can be implemented in the shortest amount of time possible.

    — Mike Vizard

  • DevOps Chat: Cloud Sprawl, DevOps and ParkMyCloud w/ Jay Chapel

    DevOps Chat: Cloud Sprawl, DevOps and ParkMyCloud w/ Jay Chapel

    I bet you know how many instances you have running AWS or Azure or Google Cloud. OK, maybe you don’t. But whether you do or don’t, do you really have a handle on what your cloud infrastructure looks like? If you are like most, the answer to the question is no. Cloud sprawl, multicloud, hybrid cloud … it is hard to get a handle on this. In this DevOps Chat we sit down with Jay Chapel, CEO of ParkMyCloud and discuss how really understanding your cloud infrastructure can help DevOps deliver better.

    As usual, the streaming media of our conversation is below, followed by the transcript of the conversation:

    Audio

    Transcript

    Alan Shimel: Hey, everyone, it’s Alan Shimel, and it’s time for another DevOps Chat. Today’s DevOps Chat guest is Jay Chapel, CEO and Co-founder of ParkMyCloud. Hey, Jay, welcome to DevOps Chat.

    Jay Chapel: Hey, Alan, how’s it going? Thanks for having us.

    Shimel: Oh, thanks for having—thanks for being here, Jay. So, Jay, I invited you on because I wanted to talk specifically about a problem that I first encountered, oh, I’m gonna guess seven, eight, nine years ago or more, and I called it cloud sprawl. Which is, you know, the nice thing about Amazon and AWS is, it made it so easy to spin up new instances and add new storage and what have you. The not so nice thing about AWS and those kinds of things is, it made it so easy to spin up new instances and storage and those kinds of things.

    So, it was—it’s come to the point, Jay, where I know many, many companies really have little control and even less insight into what they’re actually spending on, and what they actually have in terms of assets in the cloud. You know, and for anyone who’s gotten an AWS bill or tried to go through an AWS bill, my AT&T wireless bill is probably easier to understand, if you can believe that.

    So, it’s a real problem. Jay, I would imagine this is something that you guys are helping companies with an awful lot, and that’s the crux of it.

    Chapel: Yeah, that’s correct. I think there’s three problems we primarily see with customers that relates to Amazon, Azure, Google, and/or even multicloud. One of them obviously is what you just brought up, sort of cost visibility. A second, though, is once you get the visibility, it’s around control.

    So, I get a good view of what I have, how do I control those costs using things like reserved instances or turning things off and on. And then the third thing is, really automating that as part of your DevOps process. So, how do I automate that as part of how I’d spin things up in the cloud, spin things down, and really make that integrated into my infrastructure.

    Shimel: So, and hand in hand with automation, we tend to think once stuff is automated, we can reduce the cost of it, but we really can with automation and on and off stuff. You know, Jay, and we can talk later perhaps on another DevOps Chat, we can get into the kinda technical details of how this all works.

    But I wanted to focus our conversation today really at the business owner or business stakeholder, if you will, who is tasked with keeping a cloud budget on budget or under budget, who is tasked with making sure that there’s enough resources to do what needs to be done, but not—they don’t have excess resources—who really is, I mean, this is a major problem for them.

    Without naming names, Jay, can you give me some war stories, if you will, of kinda the worst messes you’ve seen some companies get into before they came over to ParkMyCloud?

    Chapel: Yeah, so, I mean, to your point around the business owner—so, we just talked to a large company yesterday that’s moved into AWS, and they actually had a team of people on the phone with us, I think there were five or six of them, and they all had cost management or cloud reporting or some kind of financial control in their title, even though they were technical people. So, people are—companies are putting people sort of in charge of this problem and spending money to help manage and reduce money.

    So, that’s a really large company with lots of resources, but then, for, I would say, companies born in the cloud, like whatever fintechs or health care or social media or ad companies that have been built over the last five or 10 years with all their infrastructure in the cloud, to really put that responsibility more on sort of the DevOps person.

    So, it’s kinda interesting as, even though they’re technical, they’re also responsible for controlling cloud costs, because somebody’s knocking on their shoulder saying, “Hey, this bill’s gone up. You need to manage this. Here’s a visibility into that—now you need to put controls and mechanisms in place so people just can’t spin things up randomly, and there’s some process in place.”

    So, it’s kind of a mix based on the size of the company, for sure, but that’s definitely a problem we see, and those are the people we talk to every day.

    Shimel: Absolutely. So, Jay, I don’t know if you guys have amassed any kind of metrics or anything, but give me a size of a company and kinda what their cloud bills are. And there’s probably a difference between native cloud and companies who are just starting to kinda go through their transformation. But what—you know, just so we have a kind of field of reckoning, what kind of budgets are we talking about?

    Chapel: Yeah, well, that’s an interesting one. So, lots of people you actually talk to on the phone don’t really know how much they totally spend per month on the cloud. [Laughter]

    Shimel: Oh, I know that.

    Chapel: But they do know the size of the infrastructure, so they’ll be able to tell you, “Hey, we’ve got 4,000 instances, and I’ve got this much in storage, and I’ve got this much in terms of database spend,” and things like that. But they really don’t know their total bill.

    But we talked to—we just talked to a company today with 4,000 instances, another one the other day with 7,000, another one the other day with 12,000. So, it’s really all over the map, but if you have 12,000 instances, you’re spending millions of dollars per month with either Amazon, Azure, or Google—in this case, it happened to be Amazon.

    But the more interesting thing is that, what we see is like—for a really good example, we’re just looking at a company today based in Canada that uses our platform, they have about 430 instances in Amazon, and they park 26 of those, but they save $18,000 a month just by parking 26 of those.

    So, what’s interesting is how big the instance is and then how much money you can save on it. So, if it’s a small or micro, you’re not gonna save much money, but if it’s a database and/or a large, extra-large, you know, the gargantuan instances, you save a lot of money on those.

    So, it’s really all over the map on how much you spend based on not always the instance count, but the size of those instances or databases you’re running in the cloud.

    Shimel: Got it, got it. It’s a crazy—I mean, when you think about it, the fact that they don’t know what they’re spending, Jay, and they have—you know, you’re talking to someone who, when I used to have to put a new server in would grab a screwdriver to rack mount it, right? [Laughter] So, 400 is a lot of screws.

    Chapel: Yeah. [Laughter]

    Shimel: But the fact that they don’t even know what they’re spending, I mean, at some point, that’s almost negligent, right? But yet, I get it. I get it, because it’s hard to put it all together.

    Chapel: Well, it’s hard to put it all together, but then, you know, it also depends on who you’re talking to. If you’re talking to the CFO or the CIO or CTO, they probably understand quote-unquote how much they’re spending in the cloud. But, as you move down the organization to DevOps engineers or IT operations or director level, they may or may not know the total bill, but they definitely know what they’re responsible for in terms of infrastructure. And then, more importantly, how are they charging that infrastructure back?

    So, we talked to some companies that do a pure chargeback model and they even do a cost uplift. So, let’s say that some organizations spend $100,000 a month in the cloud—well, they’re actually gonna cost uplift that and say, “Okay, well, I’m gonna put 10 percent on this or 20 percent on this for managing that for you.” And we talked to some companies that have no chargeback at all, that IT just pays the entire bill.

    So, it really—you know, it’s really very similar to a traditional data center in that sense; so, just depending on the way people put their cost models internally and if they charge it back to projects and stuff. Definitely very interesting conversations when you get to it with people.

    Shimel: Absolutely. Jay, just while we’re here, though, why don’t you give a little background on ParkMyCloud, though? I realize we didn’t really do that before, so what exactly—you know, give us a little background.

    Chapel: Yeah, sure. We’re a two-year-old company based in Northern Virginia. We’re right near Dulles Airport, if people know where that is. And basically, what we do is, we help people optimize their cloud costs by turning things off when they’re not being used.

    So, you could take a simple example of a customer that has maybe 100 instances in the cloud, maybe 55 of those are production and 45 of those are non-production. Well, those non-production instances generally don’t need to run on nights and weekends, and then we help them identify those instances, automate the sort of shut-down process based on schedules, and then bring them back up when they’re needed. And this is all integrated with single sign-on technologies like Slack and Jenkins audit logs and reporting, so it’s really an enterprise technology, and it even has an RBAC model that allows people to set up users teams, so you can do a whole role-based access control around that.

    But when you park an instance, the average savings on an instance is usually between 65 and 70 percent per instance per month. So, ergo the example earlier where this company is parking 26 instances and saving $18,000.00 a month. You can really get a significant ROI doing that. And we have a lot of large enterprises using the platform—Capital One, Unilever, McDonald’s, etc. They’ve been on the platform for a very long time, and we have born in cloud startups like ParkMyCloud using it as well. We do have customers all over the world now in about 15 countries.

    Shimel: That’s pretty amazing. Really amazing story. And Jay, what about you? What’s your background?

    Chapel: Yeah, so I’m a sales guy by nature. So, I’ve been in the IT industry since the year 2000. I used to work for a company called Micromuse. They had a product called Netcool, so if people are familiar with traditional data center service assurance, network assurance, etc. And then we got acquired by IBM Tivoli in 2006, and I spent a lot of time over at IBM.

    And funny enough, in about 2010, 2011, 2012, we were in Tivoli inside IBM and we sold infrastructure software like server monitoring, application monitoring, storage, and stuff like that. And we started losing stuff to born in cloud companies—companies like ServiceNow, companies like Splunk, companies like New Relic and AppDynamics, even solar ones and stuff like that. And what we—you know, and SaaS technologies.

    So, really got into seeing, okay, how are people gonna use the cloud, and then where is that gonna go over time? And obviously now, since it’s a utility, really, we really kind of turned ParkMyCloud into something that focuses on cost control and optimization. Sort of like Nest for the cloud—that’s how we got to where we are today.

    Shimel: Very cool, man. So, as I mentioned, Jay, we’re gonna have you and the folks on again, because I want to get more into the technical aspects of all of this. But I think what we’ve given people today is a good overview of the business case on why—I mean, if you don’t know what you’re spending on cloud to begin with? Call, right—give a call over there.

    If you don’t know how many instances you have or, you know, are you shutting stuff off automatically, or is it simply if you’re just wanting to automate this, right? Because this is really something that, to me, screams out to be automated—really, ParkMyCloud seems like a great solution that you should be looking into.

    Chapel: Yeah, it’s a single purpose platform, built solely to help people optimize inside AWS, Azure and Google. And we offer a free trial, and it’s, most of—I would say at least 75 percent of our customers are 100 percent self-service. So, we’ve never talked to them, they pay a subscription, they save money, and they love using the technology.

    Shimel: That’s a nice business right there, my friend. Alrighty!

    Hey, Jay Chapel, CEO, Co-founder of ParkMyCloud—thanks for being this week’s guest on DevOps Chat, and we look forward to hearing more about ParkMyCloud in the future.

    Chapel: Yeah, likewise. Thanks for the time, Alan. I really appreciate it.

    Shimel: Alrighty. This is Alan Shimel for devopsy.kinsta.cloud and DevOps Chat. We hope you enjoyed this, and we’ll see you soon on another chat.

    — Alan Shimel

  • Measure What’s Important: DevFinOps

    Measure What’s Important: DevFinOps

    Lately there seem to have been quite a few DevSomethingOps terms being coined. However, I do think we need one more: DevFinOps.

    Dev-What-Ops?

    One of the biggest problems in IT is working out the cost of IT. Left unchecked, IT will expand to fill whatever budget it is given. This may mean evermore involved business continuity and redundancy, reinventing evermore elaborate wheels, irrational versus buy decisions and so on.

    In fact, the whole idea of cost estimates for IT projects has become something of a joke. Most IT projects are reputed to exceed their budgets.

    There is an entire #NoEstimates movement that rejects the idea that it is even possible to deliver a sensible estimate for a software development project. As is often the case, the basic idea is reasonable:

    it is possible to do small chunks of work incrementally, leading as rapidly as possible to a desired shippable product, and that when you do that there is no need to do much of anything in the way of estimating stories or the project.

    However, the simplistic interpretation that is all over Twitter is that because there is no estimate of the  overall project, there is no estimate at all. That is not the idea! It is simply to break down the overall estimate (which is probably wrong) and instead budget for much smaller chunks of work, which can presumably be estimated more precisely and accurately.

    So What Can We Do?

    Maybe what is required is integration of financial concerns directly into the fabric of IT development operation. We might call this DevFinOps, in line with other extensions of DevOps such as DevSecOps or DevNetOps.

    This is not such a leap; after all, we already integrate costs in areas such as SLA calculation, estimating the TCO of a tool or the ROI of a proposed purchase. However, these are generally calculations that are made after the fact, and may even be retconned to fit external assumptions.

    What I am proposing, though, is to build this information right into the IT metadata and processes to enable us to make better decisions.

    This is not IT Asset Management, although it would build on those data and extend their reach. A particular device or piece of hardware has its purchase price and current amortised value documented in the ITAM database, but the actual value it has at any given time might vary depending on which business function it is currently supporting. This calculation should change over time to reflect the real current value it is delivering to the organization at any given time.

    An idle server has no particular value beyond the intrinsic value of the hardware, back-end support (floor space, network, cooling, etc.), and perhaps any associated licensed software. However, the same server will take on a much higher value to the organization when it is provisioned as part of the infrastructure supporting a major business-critical application.

    Performing actions on these systems would therefore have different potential impacts, and should be treated as costs deducted from a limited budget. Live-patching a business-critical server is an expensive operation, not to be treated lightly. The cost of doing so should be deducted from an operational budget.

    This calculation has the benefit of making it easier to communicate the different impacts of various proposed courses of action outside the IT department. Deciding between cloud and on-premises deployment options, or between different flavors of cloud, can be a fraught process. Technical options and pricing models are rarely easily comparable, and then there are other costs such as compliance (yes, and GDPR) or vendor risk. Quantifying and normalizing these disparate factors would make it that much easier to compare options up front and calculate benefits after the fact.

    Is This Even Possible?

    Google already does something like this in its Site Reliability Engineering (SRE) program, with the notion of an error budget:

    The business or the product must establish what the availability target is for the system. Once you’ve done that, one minus the availability target is what we call the error budget; if it’s 99.99% available, that means that it’s 0.01% unavailable. Now we are allowed to have .01% unavailability and this is a budget. We can spend it on anything we want, as long as we don’t overspend it.

    There is a long and sordid history of attempts to make programming projects comparable and their estimates more reliable. Often this devolves to simply counting lines of code, according to the age-old management syllogism: “We need to measure something; this measurement is easy to gather; let’s measure this!” and of course the Mythical Man-Month.

    Fortunately, there is a way to calculate the complexity, and therefore the potential cost impact, of a piece of code: the Halstead volume. This is a measurement of the complexity of code, described in terms of the number of distinct operators, the number of distinct operands and the total number of operators and operands. While it is not guaranteed to be perfectly accurate in every case, it is at least accurate enough to be comparable, and therefore can be used to estimate the risk of a change, in terms of the relative Halstead volumes of the code to be changed and the patch to be applied.

    But What About the Squishy Meatbags?

    Connecting the human costs would also enable other metrics to be gathered. It has been historically difficult to differentiate between what is urgent and what is important, and how to prioritize each. If we connect salary data (including overtime) to changes, it becomes much easier to make the call on when enough time has been wasted on a problem and the cost-effective solution is to start from scratch.

    It sounds like a lot of work to gather all of this information, but these data already exist; they’re just not connected up in one place. When the business wants to launch a new service, there are (usually) pretty rigorous calculations behind that decision. The expectation is to acquire or retain a certain number of customers who have a certain average lifetime value and break-even points and other criteria are all mapped out ahead of time. For whatever reason, though, these islands of information are rarely if ever connected up.

    This, incidentally, is just one reason why it can be worthwhile to work with reputable and experienced vendors. I have written before about what this process looks like. The good vendor sales teams will help to unearth this sort of information—but even in the most positive sales processes, the kimono is rarely fully open. There is far more information inside the organization that could be enormously useful if only it were available in the right place and at the right time.

    Longer term, this would mean that business cases and ROI calculations would finally be concrete and factual, rather than extended performance pieces in the medium of spreadsheets. On that note, there is a wonderful little book, titled “How to Lie with Statistics,” which is even available as a free PDF. It’s one of those books that is fun to read because you start spotting the things it was talking about simply everywhere.

    If you wanted to be maximally Zeitgeist-compliant, you could probably verify all of this with blockchain, although I worry that the transaction costs (including thermal costs!) would be prohibitive. The good news, though, is that you could use this DevFinOps methodology to work that out too …

    All That Effort, for What?

    Bottom line, the goal is to be able to calculate (at least within reasonable limits) how much IT is costing today, and what the impact of any proposed changes would be—and crucially, to do so in real time.

    The goal is agile cost estimates. There is a reason I chose the DevFinOps coinage. The way we do cost estimates today is very “waterfall“: large teams have extended arguments over spreadsheets, and the process is so painful and expensive (in person-hours and disruption) that it is only undertaken for the largest changes.

    Agile’s faster release cycles do not align at all well to this process, which is where #NoEstimates is coming from. However, if we start gathering and processing all the cost data in real time, and make it available via a simple API call, it becomes possible to calculate both ends of the cost of a proposed change: the complexity of the code itself, and therefore the probability that it contains bugs, and the infrastructure impact that the deployment will have. This cost can then be compared to the team’s current SRE error budget to determine whether the change can be made automatically or whether it requires signoff as an exception.

    The result looks a lot like ITIL’s notion of a “standard change”, but without the inherent conflict between ITIL’s centralization and SRE’s decentralization. The key is a common accepted measurement of what a standard change actually is, which would otherwise require the ITIL Change Manager to make the determination ahead of time.

    What Does This Look Like in Ops?

    Let’s not forget Ops, either. Proper cost estimates like the ones described above would enable Ops to prioritize alerts correctly and estimate impacts accurately. Two outages with equal technical severity may have very different business impacts. Today, that reconciliation relies on tribal knowledge and systems that are often inaccurate or out of date. Given a central shared repository of data that describes the value of deployed systems, it becomes possible to calculate those impacts much more accurately.

    While we work to get to full DevFinOps, you might want to consider AIOps, which helps gather a contextual view of what is actually going on in IT. Gartner just released a Market Survey for this emerging space. Normally these documents cost $1,295, but you can get a free copy here, courtesy of Moogsoft.

    Dominic Wellington is Chief Evangelist at Moogsoft. He has been involved in IT operations for a number of years, working in fields as diverse as SecOps, cloud computing, and data center automation.

    — Dominic Wellington

  • DevOps Chat: Harness.io, Continuous Delivery as a Service w/ Steve Burton

    DevOps Chat: Harness.io, Continuous Delivery as a Service w/ Steve Burton

    Today marks the launch of Harness.io, continuous delivery as a service. The company is founded by some of the original team at AppDynamics. They want to take the same kind of approach AppDynamics brought to APM, to the CI/CD market. We caught up with Steve Burton, VP of product marketing at Harness to get the scoop on this exciting new company.

    As usual immediately below is the audio of our discussion and the transcript of our discussion follows after that.

     Audio

    Transcript

    [su_pullquote align=”right”][su_custom_gallery source=”media: 118147″ width=”300″ height=”300″]Steve Burton

    Steve is VP of Product Marketing at Harness, a new Continuous Delivery-As A-Service Platform. Prior to Harness, Steve ran Product Marketing at AppDynamics, Moogsoft and Glassdoor. Steve also started his career as a Java developer back in 2004 at Sapient. When he’s not playing around with technology he’s normally watching Formula 1 or researching cars on the internet. Twitter: @BurtonSays[/su_pullquote]

    Alan Shimel: Hey, everyone, it’s Alan Shimel, with another DevOps Chat here on devopsy.kinsta.cloud. Today’s chat is with Steve Burton, VP of products at an exciting new company – just launched today – called “Harness.” Steve, welcome.

    Steve Burton: Thanks, Alan. Great to be here.

    Shimel: Great to have you here and, hey, it’s a great day to launch a company, Steve.

    Burton: Yes. Sure.

    Shimel: Of course, you know, I’m reminded of what someone told me when I sold the first company I started, and they said, “Companies are like boats – the best two days are the day you buy ’em and the day you sell them.” So this is one of the good – this is one of the big days for ya. And speaking of that, though, Steve, before we get into what Harness is about and markets and stuff, you actually – you’re one of the founding team there, and the team’s really kind of a get-together of a lot of the guys who helped found AppDynamics, I guess, back in the day. Correct?

    Burton: Yeah, for sure, with a few AppDynamics guys here. We’ve also got people from Apple and Google as well, so there’s a nice mix. But, yeah, for sure. There’s Jyoti, there’s myself, Greg Howard, and Randy Boysen, so there’s – yeah, that’s what we love to do, is build start-ups.

    Shimel: Yeah. Getting the band back together. So, Steve, though, with Harness, though, you guys have taken an interesting kind of approach here in that, you know, you see a tremendous opportunity within the CICD market. Correct?

    Burton: Yeah. Yes. I mean, Harness has primarily kind of been built for continuous delivery as a service, so the kind of CD part of CICD, and we think there’s a big opportunity there. There’s a lot of excitement, there’s a lot of projects and customers, and there’s a lot of complexity to solve, and so, yeah, that’s what we’ve kind of founded the company to kinda help customers with.

    Shimel: Sure. And, Steve, I mean, here at devopsy.kinsta.cloud, we obviously follow the CD space pretty closely, and there’s certainly no lack of companies that have thrown their hat in the ring here, right, without naming names, from well-funded start-ups to big, traditional 800-pound gorillas, but the fact that no one has really captured a dominant market share probably indicates it’s because no one’s really come up with the killer CD app, if you will, or the – and if it’s not the app, maybe it’s the delivery means and everything else. Is that part of what drove you guys to, you know, go this route with Harness?

    Burton: Yeah, I mean, for sure. I mean, if you speak to Jyoti, one of the key reasons he founded the company was when he was, obviously, CEO and founder of AppDynamics, he met with a lot of enterprises and big customers, and they were telling him, “Hey, look, we have hundreds of DevOps engineers, but a lot of them are spending their time scripting and building automation platforms. And so there’s no real solution to help us kind of be like a Facebook or a Google, where we can do continuous delivery.” And so that was really the impetus for Jyoti to kind of take a step back and think, “This problem really isn’t solved yet.”

    Shimel: Yeah. No, I think you hit on something there ’cause there’s been some – not backlash, but there’s some talk on some of the DevOps channels that, “You know what? DevOps hasn’t been as successful as we thought it was going to be and a lot of organizations aren’t experiencing the success they hoped with DevOps.” And, frankly, a lot of it is subjective, not objective, and maybe some of it also has to do with hyped-up expectations that can never be met anyway.

    But, that being said, you hit on something there that I think is important, that, a lot of times, when we talk about DevOps teams and implementing DevOps, it’s time spent figuring out automation, right, and scripting automation. And, whether it be automated testing or automated integration or configuration or what have you, it’s kind of like groundwork, rather than actually doing the work. And you probably need to do the groundwork first, right, Steve? I mean, no one’s – I’m not saying that, but, with a SAS solution like Harness here, you can kinda not cheat, but you can get a head start on that.

    Burton: Yeah, for sure, and I think one thing we’ve tried to do is simplify continuous delivery, and so a lot of the scripting and automation that you might require teams of DevOps engineers to do, we feel we can give those teams a solid platform that they can build on top of, to do continuous delivery. And so I actually sympathize because, if you look at the complexity and the work involved to make continuous delivery work, it’s more than just provisioning infrastructure and configuration management. I mean, today, you’ve got release strategies, you’ve got canary deployments, you got blue-green. You think it’ll verify how those deployments succeed in production. You’ve got rollback, so, if things fail, how quickly can you roll back?

    And I think as well, from speaking to customers, one thing we hear a lot of is just the compliance and security around DevOps, and so DevOps is ultimately about empowering teams and giving freedom to developers and operations, but, at the same time, these companies need to control and audit and make sure that things are done correctly. So a lot of the boring stuff, like the credentials and secrets management and kind of visibility and reporting, that’s as much of the puzzle as a lot of the cool stuff.

    Shimel: Yeah, you’re talking my language, Steve. Certainly, security and compliance, and I tend to think compliance is the caboose on the security engine. You know, just doing compliance doesn’t make you secure. But, that being said, security and compliance are major – they could be your best friend or your worst enemy, in the continuous delivery game, right? If you do it right, you could automate a lot of that and shift it left. It could really help speed up a successful CD process, a successful experience. But if you don’t pay attention to it and you run afoul of your security and compliance, I mean, it’s like going back to “Go,” don’t collect the 200 bucks, and you’re starting from scratch. So it’s an important piece of the puzzle, for sure.

    Steve, give us a little background, though, in – you know, so Harness sees this and the team sees this opportunity with CD. It’s a SAS-based solution. What more can you tell our audience about what you guys are doing?

    Burton: Yeah. So, primarily, it’s SAS and we also offer on-premise software as well, so you can deploy either model. I think what we’re trying to do is three things, is one is automate the actual deployment aspects, and so, instead of needing kinda scripting or coding a lot of the configuration and wiring together all of your ecosystem, and so you kind of use CI in your repository tools, like Jenkins, Bamboo, JFrog, CircleCI; and then making those kind of work in sync with kind of Amazon cloud platforms, Kubernetes, Docker; and then, finally, all the configurations. So what we’ve tried to do is build reusable connectors and templates for all of the technologies in the ecosystem so that you can literally plug them together and build CD pipelines in minutes.

    And that sounds totally alien and kinda sounds too good to be true. We’ve managed to do it, but it’s been a lot of work and it’s been working with a lot of customers. And so, in the last 3, 4 months, we’ve literally had, I think, 270 kind of validation meetings with customers. We’ve got over 20 betas in deployment. And so it’s been understanding that complexity of how we can simplify the CD pipelines today. So, yeah, it’s still a lot of work to do, but I think we’re on the right path.

    Shimel: Excellent. And, of course, Steve, you mentioned something that I wanted to bring that out too, is that, you know, it’s sort of this “It takes a village” with CD, right? There’s no one tool that, soup to nuts, is going to do everything for you, and, as you mentioned, Harness already has integrations with a number of the most common tools that are out there, like a Jenkins and so forth.

    Burton: Yeah. Yeah, and I think, if you look at a lot of the solutions on the market, they require you to rewrite your CD process and change the way you do deployments and potentially replace tools you already have, and kinda that never really works because most customers have invested a lot of time and money and resources in those tools, in those processes. And so what we do is we can fit around your existing ecosystem and tools, as well as your processes, and so a lot of the customers who’ve gone through our beta program, within the first three or four hours, they’ve actually been able to get a CD pipeline up and running and reuse the Jenkins or reuse all of the cloud technologies and platforms, in addition to the monitoring tools as well.

    Shimel: Excellent. So, you know, though today’s launch day, Steve, you guys have actually put in months and months, if not year, already of work on this, but where do you think it goes next?

    Burton: Yeah. Yeah, so, in the intro, I talked about us building the building blocks for the automation and getting the CD pipelines built. We’ve also architected Harness to do continuous verification. What that means is, once you’ve deployed code or artifacts in production, we’re actually gonna use machine learning to understand whether that deployment had a positive or negative impact on the business. And so we’re gonna verify things like performance, response times, errors, throughputs, in addition to looking at application logs to see if there’s any regressions or anything that’s been introduced as part of the deployment.

    And so that’s what we’re excited about. That really, we believe, is unique to Harness – the ability to validate a production deployment. And if we see failures or we see anomalies, we can automatically roll back to the last working version for the customer, with no interruption to their business. So, for me, the future, it needs to be more than just deployment. If you don’t know the business impact of your deployment in production, then you could say there’s been a lot of work and time and effort for, potentially, nothing.

    And I remember, when I was a developer, I worked on projects for months and our success was hitting the go-live day. And once we hit the go-live day, it was operations’ responsibility to deploy it and we never really knew whether we had a positive impact or a negative impact. And I think, in today’s world, with kind of continuous delivery and DevOps and going from an idea to money as quickly as you can, you’ve really gotta know the business impact of every change. And if you don’t, you’re letting your company down.

    Shimel: Agreed. Agreed. So, Steve, it sounds – you know, this is something that I’ve always wondered about with DevOps, which is we put so much effort into automation and doing it better, you know, getting better code, automating all of the stuff, automating CI, automating CD to the point where we actually deploy, and then, all of a sudden, post-deployment, we’re on to the next thing or we’re looking for our feedback loops so we can develop the next iteration of it. And I guess sort of APM sort of filled that next post-deployment monitoring and so forth, but it sounds here like Harness wants to fill that gap in there. Is that fair to say?

    Burton: Yeah. Definitely. I think we wanna automate how customers verify their deployments, and so the APM market is like $5-billion market right now because, literally, every company’s building software and their software keeps breaking. One stat for you is 30 percent of application deployments fail. This was an article that Wired.com wrote – I think it was a few months ago – but that’s a staggering amount of failure. And the reactive way to deal with failure is to go and buy an APM product to help you kind of troubleshoot in production, when you do a deployment.

    The smarter way to do it today is to start and do canary deployments in production, where you roll out the application to a small amount of nodes or users and then verify it before you then roll it out across the rest of your application environment. And so you can kind of think of Harness as a safety net – we’re gonna let you deploy in production, we’ll help you with canary deployments, and, if we see something that’s wrong or we spot an anomaly, you can roll it backward with virtually no business impact

    Shimel: Got it. Got it. Well, Steve, believe it or not, we’re probably a little over time here already, but, hey, we tried. Steve, before we wrap up, though, for people who wanna find out more about Harness, where can they go?

    Burton: Yeah, they can go to harness.io, is our Web address, and we’ve got lots of videos and will be a free trial coming shortly. And you can actually subscribe for the early adopter program as well, if you wanna show your interest there.

    Shimel: Oh, that’s excellent. Excellent. And I’m sure there’s plenty of stuff on the website where people can find out more information of all of these things. Steve, congratulations to you, Jyoti, and the rest of the team. It sounds like you guys are on to your next great adventure and I’m sure it’s gonna be an amazing journey. We hope to have you back here soon and we’ll be watching Harness closely and seeing what it brings to the market. Congratulations.

    Burton: Yeah. Appreciate it. Thanks, Alan.

    Shimel: All right. Steve Burton, VP product at Harness, at harness.io, if you’re interested. Exciting new entry in the DevOps space. Best of luck, Steve, and we’ll see you soon. This is Alan Shimel for devopsy.kinsta.cloud, DevOps Chat. We’ll see you soon on the next DevOps Chat.

    — Alan Shimel

  • Automation: Addressing Bot Security with BotChain

    Automation: Addressing Bot Security with BotChain

    Bot technology is all the rage these days, and with good reason. Bots help you shop and provide customer service. In fact, one bot keeps contacting me on Facebook, telling me how I can optimize my marketing spend. They’re everywhere and they’re getting smarter all the time. Any one bot can access the entire intelligence of the internet to answer your most arcane questions or give you insightful suggests tailored to the details based on your online profile.

    Still, the full potential of bot technology has yet to be realized. Right now, most bot interactions take place between a bot and a human. But, what would it be like if bots could bring their powers of recognition, recommendation and bargaining to bear interacting with other bots? Such a time is not that far away. The implications will be profound, particularly for those in DevOps.

    The Emergence of Bot-to-Bot Communication

    Machine-to-machine communication is nothing new. Unassisted stock trading has been going on for years. A machine monitors stock exchanges throughout the world looking to buy or sell stock according to its programmed logic. Once an opportunity is identified, a trade takes place without any human intervention. While it is true that each machine is acting with some degree of autonomy, the scope of interaction is limited. A machine designed to buy and sell stock is not going to go awry and buy a car. Also, the details of the interaction are well-known. When a trade takes place, the details of the transaction are recorded and an audit trail is created on both ends of the transaction. However, when it comes to bot technology, things start to look different.

    Bots can act autonomously. For example, imagine a bot that is on a mission to find the best price for red sneakers in size 9. Instead of using a predefined list of sneaker vendors, the bot can use an internet search service such as Google to find online merchants that sell sneakers. The bot will use the result of the search to continue forward, looking for the best sneaker price. (See Figure 1.)  As you can see, there is a good deal of machine autonomy in play already.

    Figure 1: Bots use the internet and can act autonomously

    Once the best price for red sneakers in size 9 is identified, typically, the bot will defer back to a human to make a purchase decision. However, deferring to a human is not mandatory. As we saw with the stock trading scenario, a machine-to-machine purchase transaction is entirely possible. Thus, given the proper programming, there is nothing to prevent a “buyer bot” from interacting with a “seller bot.” Furthermore, it also is entirely possible for the “buyer bot” to interact with a variety of “bank bots” to determine the best credit card to use to make the sneaker purchase. Who knows? Credit card “A” might be offering better air miles than Credit card “B” on that purchase date.

    The important thing to understand is that, in the past, machine-to-machine interaction was pretty much a two-party interaction that is well-known. Today, modern bot technology makes it possible for a bot to engage in any number of transactions with any number of other bots with a high degree of autonomy. Along with such autonomy comes a good deal of risk: Any one of those bots could be an impersonator or could be using fraudulent information.

    The Perils of Bot Impersonation

    Any transaction is subject to fraud—a person writes a check without the backing funds, another makes a purchase using a stolen credit card, somebody else submits an invoice to a company by impersonating a vendor. These types of misdeeds happen all the time within the scope of human activity. So, too, will such crimes happen with bots. Just as a cybercriminal can impersonate a bank website to lure unsuspecting customers into giving away money and sensitive information, bots will be able to fool other bots into fraudulent transactions.

    As bots become increasingly autonomous, the degree of harm that one bot can perpetrate upon another will grow, too. So, what’s to be done?

    Ensuring Bot-to-Bot Interaction Using Blockchain

    If you want to know that bots are playing by the rules, you have to be able to observe their behavior. For those in DevOps, the usual way to observe the behavior of the systems within an enterprise is by analyzing logs.

    Logging is a way of life in DevOps. We put logging statements into the software we write to report the details of the commands executed; we put entry dates in the records we write to our databases; we log the requests being made to websites, and administrators use logs to provide the audit trail necessary to determine the integrity of the transaction being made in systems and between systems. Coupling logging with comprehensive system security and data encryption practices makes it so that IT operations knows who is in the systems and what those entities are doing.

    However, given the autonomy that bots can have and the wide scope of interactions that they can engage in, the usual mechanisms used to determine transactional integrity degrade. Going back to our red sneaker example described above, imagine the “buyer bot” contacts an unknown number of “seller bots” to negotiate the best price for a sneaker. Part of the negotiation process is in a bidding war among all the “seller bots.” Then imagine that once the sneakers have been identified, the “buyer bot” negotiates with two “bank bots” to determine the best credit card to use. That’s a lot of transactional activity, all of which is dynamic and most of which is unknown. How do we know that each of those “seller bots” is authentic? What do we know about the details of the negotiations done by all the bots in the bidding war for the sneakers? How do we know that the credit card used to make the purchase is not stolen? The fact is, without a common source of truth that describes all the transactions in the sneaker scenario, we don’t.

    While it is true that each bot might keep records of its part in a given conversation or transaction, there is no common ledger that records all interactions made by all the bots in the given scenario. Without a common ledger by which to audit the activity, the security, integrity and quality of bot behavior is compromised.

    This is not a new problem. Those who work with cryptocurrencies have had this problem for a long time—making sure that the information provided in a transaction is authentic, true and auditable. The way that cryptocurrency systems solve this problem is to use blockchain technology. Given that cryptocurrencies and bots share many of the same security issues, blockchain technology can be applied to bots. In fact, there is an emerging technology that applies the principles of the blockchain to bots. It’s called botchain.

    Botchain makes it so that all activities conducted among bots are reported in a common, secure ledger. The botchain ledger is a distributed resource on the internet. Botchain provides the mechanisms and audit trail required to ensure that bot-based transactions on the internet are conducted by authentic bots, acting within the scope of their rights.

    Botchain technology is projected to be an important part of the modern internet, particularly as IoT technology grows. As bots become more a part of general DevOps landscape—particularly in the e-commerce-enabled IoT space (think: refrigerators that can buy their own inventory)—systems and engineering staff will need to become more adept at using botchain technology to protect the enterprise.

    Bots will bring added benefit to the enterprise, no doubt, but they will also create new types of threat vectors. Agent impersonation is but one one of many security risks that are sure to emerge. The wise DevOps organization will do well to prepare. At the least, having a working knowledge of botchain will be a good insurance policy to battle the threats on the horizon. As those of us in IT have learned, the best insurance you can buy is the insurance you never use.

    Mastering the details of botchain technology is an excellent way for DevOps to address the security issues that will arise with the increased use of bots in the modern internet. There is little downside in preparing for a future that is sure to come.

    — Bob Reselman

  • BMC to Infuse AI Across Software Portfolio

    BMC to Infuse AI Across Software Portfolio

    At its recent BMC Exchange event, BMC Software announced it will be infusing machine learning algorithms and other artificial intelligence (AI) technologies across its entire portfolio of IT operations software.

    The first instance of BMC software to make use of machine learning algorithms is the latest version of TrueSight AIOps platform, which ingests data from multiple data sources to automate processes across BMC service desk, IT operations and tools for managing DevOps processes. BMC also is working with IBM to employ the cognitive computing services known as the IBM Watson cloud service across its portfolio.

    In addition, the company launched TrueSight Cloud Cost Control, a tool for managing and tracking usage of cloud services across multiple providers, and BMC SecOps Policy Service, which easier to embed compliance and testing via an external service that gets included in their software development processes.

    Finally, BMC announced it has signed an alliance with Amazon Web Services (AWS) under which the two companies will work to accelerate the migration of application workloads to the AWS public cloud.

    Dan Streetman, a senior vice president for worldwide sales and marketing at BMC, says his company is developing a product strategy around three major themes:

    • IT organizations will require management tools that will work across multiple clouds;
    • As part of general “shift left” developers now expect to be able to programmatically invoke IT operations and security services; and
    • IT professionals now expect the tools they use to manage IT to have the same types of advanced capabilities that consumer applications provide via speech interfaces such as Apple Siri or Microsoft Cortana. Various IT and customer service desks also soon will use speech interfaces to provide a highly automated self-service experience to end users.

    In fact, given the complexity of the IT tasks that now need to be managed, Streetman says a race is now on between IT vendors to live up to those expectations. Much less of a concern, he says, is any notion that AI technologies might one day replace IT professionals that by and large are already overtaxed; rather, it is apparent that IT vendors are now being evaluated on their ability to maximize existing investments in IT professionals that are already in short supply. The real opportunity is to free IT professionals to enable them to concentrate on higher-value tasks.

    Naturally, it remains to be seen how various AI technologies will impact the management of IT. It certainly will take a while for IT administrators to put their faith in AI. But as those technologies continue to mature, there may soon come a day when IT professionals look back with wonder at all the things they used to have to accomplish one manual task at a time.

    — Mike Vizard

  • GitHub Applies Data Science to Managing Code

    GitHub Applies Data Science to Managing Code

    Over the last several years GitHub has emerged as one of the primary repositories around which application development now revolves. At its recent GitHub Universe 2017 conference, the company revealed how it is extending that central role to provide DevOps teams with the addition of a dependency graph that can be employed to alert DevOps teams when a module of code has been updated and a security alert service that will notify them anytime a patch has been made available for a specific module.

    Miju Han, engineering manager for data science for GitHub, says both new capabilities are examples of how the company is applying advanced algorithms and data science techniques to make it easier to manage DevOps processes that revolve around GitHub.

    In addition, Han says GitHub is making available a news feed through which DevOps teams can track updates to groups of modules stored in the repository, as well as a tool through which they can explore a curated set of modules.

    Han says his company intends to combine a variety of emerging data science tools to simplify the daily workflow that revolves around GitHub. As the repository has become more widely used, the sheer volume of code and related updates a DevOps team is supposed to track has become, in many cases, overwhelming. That’s why the company is now pouring resources in several data science research projects with an eye toward making it simpler to navigate the repository.

    The latest annual edition of an Octoverse report published by GitHub finds that there are now more than 24 million developers in 1.5 million organizations around the world accessing 67 million GitHub repositories. A total of 25 million of those repositories are public. The most popular programming languages in use across GitHub are JavaScript (2.3 million projects); Python (1 million projects); Java (986,000 projects) and Ruby (870,000 projects). In terms of pull requests, GitHub notes that Python surpassed Java in popularity in the last year. The company also notes that half of the largest companies in the U.S. based on revenue are employing GitHub repositories.

    There is no shortage of repositories being employed inside and out of enterprise IT organizations, including an enterprise edition of GitHub that the company claims has been implemented by 45 percent of the Fortune 100 list of the world’s largest companies.

    Arguably, the biggest challenging many organizations now face is trying to reconcile the various code repositories in use. Just about every provider of an application development platform provides access to a code repository. In addition, providers of everything from container frameworks to application lifecycle management (ALM) often provide similar capabilities. Keeping track of what version of any given piece of code resides where at any given time has become a significant challenge.

    The good news is that providers of repositories are starting to address that issue on their own platforms, which means it stands to reason that one day soon tools for managing code across heterogeneous repositories may not be all the far off. In the meantime, DevOps teams can take some comfort in the fact that the management tools they rely to manage all the code are about to become a whole lot smarter.

    — Mike Vizard

  • CA Technologies Positions Automic at the DevOps Core

    CA Technologies Positions Automic at the DevOps Core

    After acquiring Automic earlier this year, CA Technologies suddenly found itself with an embarrassment of IT automation riches. Now the company is moving forward by further integrating the Automic IT automation platform with the rest of the portfolio of tools and services that it says are required to construct a software factory.

    Ron Gidron, technology evangelist for Automic, says the latest version of Automic increases the number of integrations with the rest of the CA Technologies portfolio to include support for CA Test Data Management, Service Virtualization, Privileged Access Governance, Application Performance Management and Veracode application security software, among others.

    CA Technologies has made it clear it intends to make the release automation software originally developed by Automic the foundation of its overall DevOps strategy. Most of that effort is now focused on integrating the various elements of the CA Technologies portfolio. Longer term, CA Technologies will eventually move to rationalize any duplication in functionality.

    Version 12.1 of Automic also brings forward orchestration tools and self-service capabilities to enable developers to provision resources within guidelines defined by IT. Gidron says that while there will always be a need for IT operations specialists, CA Technologies is making a concerted effort to “shift left” to provide developers with more programmatic control over the IT environment. To facilitate that process, Automic and the rest of CA Technologies have been investing in creating a standard set of external-facing REST APIs, which also will be used to make it easier for products and services created by the company to consume a wide variety of external data and metrics.

    Via acquisitions and internally developed software, CA Technologies is clearly trying to unify application, infrastructure and security management with the context of a single DevOps framework. The company doesn’t plan to force organization to consume that entire stack of software. But it will try to make acquiring as much of its portfolio as financially attractive and frictionless as possible to drive what the company describes as intelligent automation across a modern software factory. Driving that need is the realization that just about every company in every industry is now dependent on some form of custom software to drive one digital process or another.

    The rate at which CA Technologies has been expanding its DevOps portfolio via acquisition is a major contributor to what appears to be a wave of consolidation starting to occur across the DevOps category. Regardless of how advanced any organization might become in terms of building a software factory, major IT vendors realize that it’s only a matter of time before IT organizations start to pressure them to bundle more DevOps-related functionality together. In fact, the line between what’s DevOps today and tomorrow versus what was considered traditional IT management appears to be getting more blurred with each passing day.

    — Mike Vizard

  • With Distelli Technology, Puppet Expands DevOps Portfolio

    With Distelli Technology, Puppet Expands DevOps Portfolio

    At its PuppetConf 2017 conference, Puppet made it clear its ambitions now extend well beyond its namesake IT automation framework for IT infrastructure. On the heels of acquiring Distelli in September, the company announced it is adding several products to its portfolio based on technologies developed by Distelli.

    The new offerings include Puppet Pipelines for Apps, to automate commits; Puppet Pipelines for Containers, to automate the building of Build Docker Images from a source repository and then deploying them on a Kubernetes cluster; and Puppet Container Registry, to host Docker images and unify views of them regardless of whether the repositories are local or remote.

    At the same time, the Blueshift platform developed to automate deployments of container platforms such as Kubernetes, Docker Swam and Mesos is also being enhanced. The Kubernetes module now installs the container cluster in a more secure way that is also highly available. The Docker module adds support for Puppet Code Manager, Docker Swarm mode and Docker Secrets. A Kream tool makes it easier to deploy Kubernetes and Helm, a package manager for Kubernetes, at the same time. Helm also now can manage applications deployed on Kubernetes.

    In addition, the company announced Puppet Discovery, a tool that makes it simpler to identify infrastructure distributed across a hybrid computing environment, and Puppet Tasks, which employs new open-source agentless software dubbed Puppet Bolt to automate entry-level IT tasks. Bolt is capable of running existing scripts written in any framework and executing them on any platform that Puppet supports.

    The company is also adding a Task Manager to Puppet Enterprise that makes it easier to manage ad hoc tasks and executing them across hundreds of Puppet nodes. The latest release of Puppet Enterprise includes tools for inspecting packages deployed on and a tool to simplify configurations of those nodes.

    Puppet has also expanded its alliance with Splunk to tighten integration between the two IT operations’ platforms, and formed new alliances with Baracuda Networks, CloudPassage, Conjur/CyberArk, Cumulus Networks, Electric Cloud, F5, Intelliment Security, Onyx Point, Praecipio Consulting and Sensu. In addition, the Puppet module for the Microsoft Azure cloud has been updated to provide access to more disk storage, expanded networking support and support for Azure tags.

    Tim Zonca, vice president of marketing and business development, says with these products Puppet should no longer be considered a one-product company. It is now committed to developing a full range of DevOps management capabilities. That’s significant, notes Zonca, because today there is too much tension between IT operations teams and developers caused by silos of automation across various DevOps processes. As part of that effort, the company is also committing to start to synchronize the release cycles of the various elements of its portfolio.

    As DevOps continues to mature, the line between how infrastructure, applications and security are managed continues to blur. Many IT organizations prefer to acquire a set of DevOps tools from one vendor because it simplifies purchasing and support. Over time, those vendors combine those tools into an integrated suite that aims to unify the management of infrastructures, applications and security. Most vendors today are a long way from unifying those functions, but a wave of consolidation across the DevOps sector suggests the race is on to provide a unified DevOp stack capable of being employed across multiple platforms.

    The percentage of IT organizations that make extensive use of IT automation frameworks such as Puppet is relatively small. Much of the resistance to IT automation frameworks can be attributed now to simple inertia. But as the size and scope of IT environments exceed the capabilities of an internal IT team to manage manually, it’s now only a matter of time before reliance on IT automation increases.

    Puppet and other vendors also have infused their platforms with machine learning algorithms to expand the scope of what can be automated within an IT environment. In general, Zonca says reliance on those capabilities tends to increase in time once the DevOps teams gains confidence in the algorithms’ abilities to make the right decision. Until such time, Zonca says most IT professionals employ those algorithms to either present them with a series of suggested options based on the most recent events that have occurred. Given the nearly infinite number of possibilities that can be inferred from those events, most DevOps teams already are going to need all the machine learning algorithm help they can get.

    — Mike Vizard

  • DevOps Dozen Nominations Are Now Open

    DevOps Dozen Nominations Are Now Open

    [su_heading]The 3rd annual DevOps Dozen awards are now open for nominations. [/su_heading]

    The DevOps Dozen honors the best of the best in DevOps. The third annual DevOps Dozen awards opened for nominations today. Finalists will be selected based upon how many people nominated them. The top 4 to 6 nominees in each category will then make it to the finalists. The winners will then be voted on by our panel of judges.

    You can nominate up to two entrants in the 12 categories for the DevOps Dozen. It is one nomination per person though. We are also requiring name and email address for all people nominating. While that is not going to thwart ballot stuffing, we hope people take these awards in the spirit they are meant to be.

    As stated earlier, we will take the top 4-6 nominees in each category and designate them finalists. Our panel of judges will then pick the winners from that finalists list. Finalists can submit a presentation on why they deserve the award. These can be sent to judges@devops.com. Finalists will be announced 2nd week of November and winners will be announced in December.

    Who are the judges? This is tough. We couldn’t have anyone who might be eligible for an award. That disqualifies vendors, practitioners and many others. However, I think we have 4 great judges:

    1. Alan Shimel, founder, editor-in-chief, devopsy.kinsta.cloud
    2. George Hulme, long time tech journalist and editor at devopsy.kinsta.cloud and Security Boulevard
    3. Jayne Groll, CEO and co-founder of the DevOps Institute
    4. Ericka Chickowski, an original editor of devopsy.kinsta.cloud and well know tech journalist

    So what are the dozen categories for the DevOps Dozen this year? Well you can get the full story at the site itself. Here they are as well:

    [su_custom_gallery source=”media: 117944,117942,117948,117947,117946,117943,117950,117951,117949,117941,117945,117940″ width=”600″ height=”130″]

    If you have questions after visiting the DevOps Dozen website, write us at DD@devops.com.

    The DevOps market is so crowded with worthy winners that we know some great companies and people won’t make the cut. However, there can be only one (as they say)

    Voting for finalist nominees is open for just 2 weeks, so don’t waste time. Nominate your favorites today. Good luck to everyone vying for the DevOps Dozen.

     

    — Alan Shimel