Author: Alan Shimel

  • Digital Transformation Survey: Help Us, Help You

    Digital Transformation Survey: Help Us, Help You

    The term digital transformation is probably one of the most overused, if not abused, terms in the tech/DevOps world today. Everyone is doing it, but what is it? Is it a synonym for adopting DevOps? What are its effects on you, your job and organization? What does it mean for software development and deployment? So many questions. Actually, they’re only a few minutes’ worth of questions in our new survey, Digital Transformation and Your Organization.

    digital transformation surveyThese surveys really help us understand where the market is, what our readers and community members are dealing with and what we can do to serve them better. You helping us by taking the survey allows us to help you—not only you, but the wider community as well. Your opinion is important and it counts. So please take a few minutes and help us. Take this survey now.

    You still here? OK, if our words didn’t persuade you, let me go one better: We are willing to pay you to take this survey. We will give one in every 10 people who take the survey a $50 Amazon gift card. To be eligible for the gift card, you need to enter your email address in the optional last question of the survey. Otherwise, we don’t know who to send it to. So that is another reason to take the survey.

    We will make the report of the survey findings available as well, and everyone who registers will receive a copy. The survey is open to anyone, so please feel free to share the link with your colleagues.

    Beyond taking the survey, I don’t want to minimize the importance of digital transformation. While for some—especially in our DevOps audience—digital transformation means DevOps transformation, that is not its only use or meaning. For many businesses, just adopting a digital footprint, using the internet as an active part of their business or adopting modern methods, software, Agile methodologies, etc., opens up unimagined new ways of business. At the end of the day, digital transformation may, in fact, be one of the biggest agents of change in our world over the last 20 years.

    We’re looking forward to analyzing the responses and seeing your digital transformation experiences. Please help us help you by taking the survey.

    — Alan Shimel

  • 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

  • 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

  • DevOps Chat: Shift Ops Left, Shift Dev Right with Kristian Stewart, IBM

    DevOps Chat: Shift Ops Left, Shift Dev Right with Kristian Stewart, IBM

    In this DevOps Chat we speak with Dr. Kristian Stewart of IBM’s Cloud Event Management team. Kristian has some keen insights into the role of dev and ops and how they interact. Kristian calls it Shift Ops left, shift dev right. An interesting way of looking at things.

    As usual the streaming audio is immediately below and the transcript of our conversation is below that.

    Audio

    Transcript

    Alan Shimel:               Hello, everyone, this is Alan Shimel, devopsy.kinsta.cloud, here for another DevOps Chat. Got a really hot chat today and my guest joining me is Kristian Stewart of IBM’s cloud event management team. Kristian, welcome to DevOps Chat.

    Kristian Stewart:         Thanks very much for having me, Alan.

    Alan Shimel:               And I just wanna make sure I got it right – it is Kristian Stewart, right?

    Kristian Stewart:         Last I checked.

    Alan Shimel:               Okay. Well, sometimes my funny French accent throws people off, but, anyway – and, Kristian, I mentioned you’re working with IBM in cloud event management, but give our audience a little bit behind that. What exactly does that mean?

    Kristian Stewart:         Well, let me give you a bit of a background ’cause there’s some history here, in particular with respect to the topic of the podcast, which talks about operation tools. So I’ve been with IBM for ten years. I’m one of the lead architects for a suite of IT service management tools, and my own specialization is in event management, as part of IBM’s Netcool brand, okay? So I’ve been in this industry for 18 years.

    I worked for a small start-up back in the late ’90s – the company was called “Micromoves,” and we were focused on introducing tools for disciplined fault management into telcos, into communication service providers, during the dot-com boom of the late ’90s. And then, in the early ’00s, we pivoted and successfully sold into enterprise, finance, retail, as their IT infrastructures became larger and more complex and as they matured, from an IT operations perspective. So we were acquired in 2006 and we started to work towards applying interesting mathematical and analytical techniques, for increasing the value provided by our tools, and applying machine learning and problems to this space. So that was my background up until about three years ago.

    So what do I mean by “cloud event management”? Well, more recently, as part of the movement of the industry that we serve, as they move into cloud and their investment in cloud has increased, I’ve been working with teams to build software-as-a-service offerings  capabilities we had, till that point, only available on-premise, so it includes alert notification tools, runbook automation tools, and cloud event management. And so our particular interest in DevOps is twofold, right? So our transition itself, from going to shrink-wrapped client service software, that was originally deployed on-prem, has gone through to the development of cloud-native, cloud-scale, public cloud resident offerings, and with our guys embracing paradigms like micro-service architectures, 12-factor apps, and, of course, DevOps.

    And one of the biggest challenges or one of the biggest changes our teams have had to endure is that they now have to operate these deployments themselves, right? So they’ve gone from shrink-wrapped, “Give it to the client. Now it’s their problem,” – well, kind of – through to “Now we’re hosting this for you.” So we’ve had folks from development and QA transitioning to operations roles, and they’re required to apply software engineering skills and work with app developers to ensure that we’ve got robust capabilities in private cloud. And we’re providing 24/7 ops to support these offerings.

    But we find ourselves in a fairly unique position because we’re running operations but as a service product that themselves are designed to help people responsible for running operations for their own apps and services. So it’s just sort of a renewed empathy for our end users, especially as we start to angle our offerings towards teams that are embracing DevOps. Does that answer your question?

    Alan Shimel:               Yeah, and then some. [Laughs] But good stuff, Kristian. Thank you very much. So wanted to talk a little bit today bringing this back home to DevOps, right? And one of the trends that we’ve been seeing over at devopsy.kinsta.cloud recently is, really, around kind of putting the “ops” in DevOps, right? ‘Cause we’ve spoken now to a few folks in the DevOps space from both the vendor and practitioner side, who are really emphasizing the role that ops plays in DevOps. And one of my things about it, though, Kristian, is I get the opportunity to speak to a lot of people like yourself, a lot of people who are heavily invested in DevOps, but I also get a lot – the chance to talk to a lot of people who aren’t and are new DevOps or just dipping a toe in the water and planning their DevOps migration and transformation.

    And one of the things that I try to remind people is that “Don’t leave your common sense at the door,” at the DevOps door, right? Bring it with you, number one. And, while you’re bringing something with you, it doesn’t mean everything you’ve done in ops to this point and all the lessons learned and best practices accumulated get thrown out – you know, the baby with the bathwater. With DevOps, we evolve. We’re not necessarily revolutionizing; we’re evolving. And so building on best practices and time-tested ops practices and methodologies and processes is probably a better solution than, you know, scrapping the whole thing and starting from scratch. And who has the opportunity to do that anyway? What do you say to that, Kristian?

    Kristian Stewart:         Oh, I agree completely. And, you know, amongst our clients, we’ve got a whole array of clients, from telcos to finance to retail, right? You name it. Across those clients, we have people on varying points on the curve of maturity, with respect to adopting DevOps. But what I say to those clients, as they look at those paradigms, is that the business objectives of operations teams haven’t changed substantially, certainly since I’ve been in the business. There’s a lot that has changed, but the business objectives continue to be measured by KPIs like mean time to repair, mean time between failures, and pressure on costs, right?

    So disciplines – so, within a, let’s say, a mature enterprise that have invested heavily in ITIL, they adopt disciplines like event and incident management, and that leans on a key set of capabilities, which are equally applicable when you transition to DevOps. You know, the proximity of your developers to your operations and the smoothing of the processes and the interactions between those organizations, if anything, are enhanced by some of the traditional methodologies and tools. So, you know, to list some of them, you need tools which can consume events from highly heterogenous environments; you need to minimize the amount of management noise that’s presented to the people who have to respond to events; you need to be able to integrate with other systems; you need to be able to help pinpoint probable causes, drive efficiency in operations, do things like apply machine learning and advanced analytics to gain insight from your event and incident data.

    So, if you look at the evolution of these practices, historically, right, ITIL emerged in parallel with the practice of event incident management. It didn’t dictate it. You know, these standards emerged as – sorry, event and incident management emerged as de facto practices, driven by the availability of practical tools to solve real problems, and they still solve those problems. You know, if you look at the way that operations has evolved, look at telecom from the late ’80s and early ’90s, right?

    So, in a telco network operations center back then, you might have had dozens of very highly-skilled people, _____ network engineers, with training on dozens of different management tools, and these guys and girls were expensive, right? I mean, their time cost a lot of money, and then the introduction of event and incident management tools helped transition from that to having perhaps the same number or even more operations staff of a substantially lower skill. And so the first thing event management and incident management did was to try and lower the cost of entry for running an efficient operations team.

    But now, if you look at the changes in IT management now – so I was chatting to a large enterprise just the other day, and, ten years ago, they – so these guys have always been driven by those same metrics – MTTR, MTBF, cost, right? A few years ago, their job was to provision physical hardware, static middleware, and the management of that stuff from an operations perspective. Now these guys are having to provide platform-as-a-service tools, distributed runtime container and orchestration systems, and they still have responsibility for the existing infrastructure – the network, the physical servers,  the legacy monolithic applications. And all that still requires management. So, mainly, they’ve got the challenge of managing hybrid cloud, coupled with extremely tight expectations on time-to-market that working practices like DevOps and Agile software development allow for.

    So I’d say that event and incident management tools are as relative now, if not more so, than they ever were because, when you shift to practices like DevOps and site reliability engineering, you know, back to the olden days where you have ops employing of hundreds of you know, low-skill operators, best practice is transitioning to one where you have a substantially lower number of substantially higher-skilled operations staff. Right? So these guys and girls are highly skilled, but they’re time-poor. You know, your typical operations professional, in an organization that’s embraced DevOps, wanna be concentrating on automation, on liaising with dev early on in the release life cycle, on prepping for new rollouts. They don’t wanna be grappling through log files and sifting through performance metrics to find out what happened just so they can restore a broken service.

    And I think the eventual goal of the kind of tools that we provide – event and incident management – isn’t just to help the operator find the needle in the haystack; I think it’s to hand them the needle. And that’s useful, whether you’re a low-skilled junior operator in old-school operations or a time-poor, hyper-technical site reliability engineer with 20 years’ experience. Alan, you still there?

    Alan Shimel:               Yes. Kristian, I’m sorry. I had a little internet issue. So all really good, but, you know, one of the things I wanted to touch on, Kristian, is the subject of empathy, as part of kind of your DevOps mantra, right? Sometimes, people give cultural things short shrift, but empathy is important in DevOps. And what I wanted to ask about was the idea of “How do we get developers?” Right?

    For a long time, the ops people have sort of had to empathize with developers are doing and what they’re doing in terms of development to help in deployment and stuff, as part of DevOps, but now, putting that on the other foot, right, getting developers to empathize with what the ops folks are dealing with, as part of this DevOps equation. I mean, I’ve heard of some organizations where they’ll actually embed developers on the ops teams for short periods of time so that they get empathy the hard way, if you will, right?

    Kristian Stewart:         Yeah.

    Alan Shimel:               They gotta live it. What do you think about something like that?

    Kristian Stewart:         I think, in terms of getting the development professionals involved, I think – so you mention role rotation, right? And I think that’s one tactic. You know, I like to think of this as much as “shift-right dev,” as it is “shift-left ops,” right?

    Alan Shimel:               Yeah.

    Alan Shimel:               Good. Good.

    Kristian Stewart:         And, actually, you know, it reminds me of the situation in shrink-wrapped software development, maybe 20 or 25 years ago, between development, who were the coders, and QA. Right? So there was sort of a brick wall, prior to Agile software development, where it was throwing a pile of code over the wall. And I think Agile, with that shift-left testing, really helped to remedy that, to the extent that I see, today, developers and quality assurance engineers working really, really closely together and not depending on, you know, reams and reams of documentation to communicate with each other.

    So, I think, with DevOps, I think a similar thing is happening, and I think you need shift-right dev, as well as shift-left ops. So operating an application or a service, I think, has to be a shared responsibility, and I do think that dev need to get skin in the game. So that’s gonna include dev as an escalation point, when an incident occurs. It can also include role rotation. But, for mutual benefit, I think they both need to use the same operations tools, right, so that they see what each other are doing, when an incident or a critical event occurs in the environment. And then they’re motivated to improve the use of those tools for themselves, as well as for the sake of operations.

    I think, you know, a 3:00 AM incident notification, you know, like a page at 3:00 AM, is a great motivator. So, for ops people, it’s an incentive to get runbooks and automatic incident responses written so that service restoration is as quick as possible and, preferably, automatic. With dev, it’s an incentive to make their services or applications operable, right, so they need to get the right amount of instrumentation into the app so that ops can manage an incident or, better still, that some script can, so that neither of them get the 3:00 AM escalation. So I think there’s a – with all due respect to my dev and ops colleagues, there’s a carrot-and-stick approach there.

    Alan Shimel:               Mm-hmm. Yeah, that makes perfect sense. Kristian, I want you to repeat what you said before. We need to shift ops left and shift devs right or did I have that backwards?

    Kristian Stewart:         Yeah, no, yeah, that’s what I said. Shift-right dev and shift-left ops, right?

    Alan Shimel:               Got it.

    Kristian Stewart:         So get them to have a degree of overlap with respect to their responsibilities. And, of course, what they do in response to those responsibilities can be quite different. You know, let me see if I can think of an example. So, for devs, under those circumstances, when they’re being involved in responding to an incident, it can be stuff as simple as being really clear in their application logs.

    So, if you think about events that are generated by, say, a container-based app deployed on Kubernetes, okay, so the event and incident management system is gonna be presented with logs from the app code; they’re gonna be presented with logs from middleware; logs from Kubernetes itself; logs from, potentially, external technologies and monoliths – NFS mounts, databases, legacy apps, network; and they may also be getting alerts from monitoring systems that are watching performance metrics for the running container, so transaction request rate between micro-services, CPU utilization, response time.

    So, if devs can make sure that something as simple as the concept of criticality or severity is included in the logs, that really helps with filtering _____ ops figure out whether or not something’s really a problem. You know, for example, is this event classed as a trace message? A debug message? A warning? An error? Is it known that this is service-affecting? Right?

    Alan Shimel:               Yeah.

    Kristian Stewart:         And, you know, how better to motivate devs to implement those sorts of practices than to make them consume log messages that are completely uninterpretable, right?

    Alan Shimel:               Agreed. Agreed. Hey, Kristian, we’re over time already, but, as I told you before we started, the time here goes quickly. But, you know, boiling all of this down, the last – whatever – 18 minutes down, really, I wanna make the point of – and I loved what you said about ops shift left, dev shift right – that our ops and devs can work together. And, as you said, they each will have different reactions with different roles and responses to given incidents or given stimuli, but they can work together and we can build on what ops has built over the last 50 years of the IT industry. And –

    Kristian Stewart:         Mm-hmm.

    Alan Shimel:               Right? We don’t leave that at the door of DevOps; it’s part of it. And one thing I want – you know, if we can ask people to take that with them. And you agree that’s key takeaways here for them?

    Kristian Stewart:         Absolutely. Couldn’t agree more.

    Alan Shimel:               Fantastic. Hey, Kristian Stewart, IBM, thank you for joining us on this episode of DevOps Chat. Love to hear more in the future about what you and the IBM team are doing around cloud and hybrid and some of the other stuff kicking around. And we’ll have you back again soon, but, for now, thanks for being our guest this episode.

    Kristian Stewart:         Alan, it was an absolute pleasure.

    Alan Shimel:               Great. Hey, this is Alan Shimel, everyone, for devopsy.kinsta.cloud, DevOps Chat. Thanks for joining us and we’ll see you soon on the next chat.

    — Alan Shimel

  • DevOps Chat: How DeployHub and OpenMake Software Help CI/CD w/ Tracy Ragan

    DevOps Chat: How DeployHub and OpenMake Software Help CI/CD w/ Tracy Ragan

    This DevOps Chat features OpenMake CEO Tracy Ragan. OpenMake are the producers of DeployHub and DeployHub Pro, which help DevOps with CI/CD. OpenMake is a company that was helping developers long before people spoke about DevOps. Using an open-source business model with DeployHub has transformed the company. We speak with CEO Tracy Ragan to find out how.

    As usual, the streaming audio is below with the transcript immediately following.

    Audio

    Transcript

    Alan Shimel: Hey, everyone, it’s Alan Shimel, devopsy.kinsta.cloud, DevOps Chat, and, in this episode of the chat, we’re joined by Tracy Ragan, CEO OpenMake Software. Tracy, welcome to DevOps Chat.

    Tracy Ragan: Thank you, Alan. Thank you so much for inviting me. It’s my pleasure.

    Shimel: Okay. So, Tracy, the last time I think you and I caught up, we were over at Jenkins World, out in San Francisco, a couple of weeks ago. And, you know, that was quite an event and it really kind of spoke to how big the CD space is becoming—you know, the CD market and the kinds of companies that are utilizing different CD solutions. Of course, OpenMake, you know, plays in that market arena, Tracy, but, for those of our listeners who maybe aren’t familiar with OpenMake, can you give us a little background?

    Ragan: Absolutely. So OpenMake Software has been playing in this continuous delivery space long before it was in fashion. Our initial product, our Meister product, was created about 20 years ago, and it was created to accelerate the process of compiling code once it was checked into a version control tool. So you check in and you build—we were doing that close to 20 years ago. Now we were just doing builds off of a trigger; we weren’t doing continuous integration. What we were doing was the hardcore build automation, and what I mean by that—the automatic generation of the compile and link scripts, the acceleration of the compile process, and the dependency management so you could do just-in-time builds, to speed up the process of moving code forward.

    So we were really early on in understanding the need for faster delivery of code and the ability to create what we call a “release candidate” at any point in what used to be call the “life cycle” and now what we’re calling the “pipeline.” So this is an area that we have heavy expertise in and a lot of heart for.

    Shimel: Absolutely. You know, Tracy, one of the things that I always find interesting, and somewhat sad, is that, when we talk CD, right, some people—I think most people still refer to continuous delivery, but others, you know, talk about continuous deployment, and then, unfortunately, I think there’s a Venn diagram kind of subset that think that somehow continuous delivery and continuous deployment are one and the same. And—

    Ragan: Yes.

    Shimel: – why don’t we start with destroying that myth? Right? What’s the difference? Is there a difference—I think there is—between continuous delivery, continuous deployment?

    Ragan: So if we look at the continuous integration process—and I think that’s where we have to start, to understand continuous delivery and then, of course, continuous build and continuous tests and continuous deployment underneath that— so continuous integration itself, I don’t wanna say it doesn’t do anything, but, in itself, it’s an orchestrator. It itself doesn’t compile code, it doesn’t test code, and it doesn’t deploy code. What does those steps are the unsung heroes who oftentimes write scripts or automation tools that sits underneath that process.

    Continuous delivery is the ability to have a release candidate ready to go at any point in time across what’s now called the “pipeline,” so, if you have a continuous integration at the dev state, you might also have one at a test state—now this sounds very waterfall, which is why I don’t like to describe it this way—but, in essence, what you’re doing is saying, “The development teams are ready and they have a release candidate they wanna push off to testing. Testing should automatically test it and then push it off to production.” Now what’s core, what’s the lowest common denominator between those simple three states, is the ability to get it out to end targets so you can actually run a test at dev or run a test at test or execute it at prod. That’s what continuous deployment does.

    I prefer to call it “continuous deployment.” We often hear it referred to as “application release automation,” or ARA, and that sometimes feels a little heavy and waterfall-like, but, in essence, that’s what those tools are doing, is they’re doing continuous deployment, in the same way as test automation tool does continuous test and in the same way, you could say, Maven or a product like our Meister is doing continuous build, all driven through a CI/CD workflow.

    Shimel: Excellent. Excellent. And, you know, you hit on something else there—ARA. And that, again, we’ve seen several vendors kind of stake—they’ll put a flag in the ground around ARA. So now that we’ve got some basic definitions done, Trace, let’s talk about how do we move right—in this case, it’s almost shifting right, right?—how do we move rightwards down this deployment—delivery, deployment, management—you know, timeline? And—

    Ragan: So I think what we have to do is we have to talk about DevOps, right? So we have this other big term that’s being thrown around, and that’s “DevOps.” Everybody I speak to has a different opinion of what DevOps is, so I’ll just share with you mine. DevOps is the process in which the development teams start taking over more of the operational tasks. And the operation teams’ role is mainly one of auditing or having some level of control. My guess is that, as DevOps is pushed left, so developers are doing more of the work, we’re going to see operation teams become smaller.

    And that’s really—if you really look at what companies are doing, they have large operation teams because they’re doing their own thing when it comes to doing software releases. They’re not part of the CI/CD process, in many of these cases. But, in reality, what happens is is that the developers are the ones who have to do the hand-holding at production, so the more we can get developers to declare their definitions around their software deployments, what their environment looks like, the easier it becomes for the data centers to become leaner. And that’s really what Agile, DevOps is all about, is getting, in the hands of the developers, tools that can automate these operational tasks to a point that the testing teams and the production teams can consume them and have some transparency and some level of control around them.

    Shimel: Got it.

    Ragan: So that’s what continuous deployment, application release automation, is achieving, is that ability for developers to dig in at the dev level, not with scripts because scripts can’t adapt across the pipeline, but to do that in a model-driven way that could adapt across a pipeline, so that the work – all the declarations are done down at dev, and the users of that are testing and production. Even down to a configuration change, if need be, at a Cisco router level. We’re talking low-level definitions.

    Shimel: Sure. Sure. So, you know, Tracy, it’s funny; you guys over at OpenMake have been involved in this space, as you said, 20 years, right? Way before we start using—throwing around the terms “DevOps” and “continuous” this and “continuous” that. And kind of living in the DevOps bubble, if you will, we think, “Oh, everyone’s doing this kind of stuff and this is the way it should be done and this is the way it is being done.” But, really, when you look at it—and you probably have a better view than most, Tracy—how far along are we on market adoption, around this, you know, more—I think it’s a more holistic approach to DevOps and continuous delivery and deployment, as well as ARA?

    Ragan: That’s a hard one to answer. I can give you my best guess and give you some numbers I hear from the analyst. If we talk about ARA, the analyst tell us about 20 percent of the companies have adopted ARA. Now, but, that being said, when I hear—yeah?

    Shimel: Yeah, I was gonna say that sounds high to me.

    Ragan: It does, but let me tell you why it sounds high. It sounds high because, when companies adopt an ARA solution, they’re often talking about a legacy product that somebody on the operations side of the house decided to purchase. And, oftentimes, they’re legacy because they have the requirement of in-target agents, so the decision to put an agent on every single production end point, including cloud or even define them to a micro-service, has to be done way right. That doesn’t mean that we’re doing continuous deployment; it means that their operations side of the house decided on a tool that may or may not be adopted by the left side of the house.

    You know, when I talk to companies, most of them will talk about that they’re adopting DevOps, but if you ask them if they’re able to solve a build in less than 10 minutes or if production can repeat the deployment that developers defined, the answer will be “No.” So the reason why it’s hard to answer that question, to get clear metrics on it, is because everybody’s definition of what that is is so drastically different.

    Shimel: Yeah.

    Ragan: In my mind, I’ve only met a few companies that have really established a real Agile, DevOps practice, and it’s not for the entire organization—it’s for a few teams—so we’re babies, when it comes to this. I believe we have a long way to go to really understand how to make that shift left so that this Agile concept of where testing and production are not separate states in life cycle and separate silos, but part of a circular process that is included everybody on the same team. So waterfall still persist, and to be quite honest, in continuous integration, if you look at what drives the CI process, we are still using the same waterfall scripts that we did, you know, five or 10 years ago, depending on how far you are in CI. Much of the stuff, they consider automated because a script executes it, but that’s not automation. It’s automation in the waterfall world, but it’s not automation in an Agile, DevOp practice.

    Yeah, these steps really have to truly be automated so that it’s transparent, there’s reporting, there’s clean metrics, there’s a continuous feedback loop, because that’s the best way to go fast. The best way to go fast in anything you do is control, right? The more control, the more speed. The problem with control, on the ARA side, is it costs too darn much, which is why we decided to do an open-source solution. It’s like developers, in order to achieve this, in order to really achieve this and really move as fast as possible and increase these release cycles, you have to have developers being able to get their hands on a product that will do the deployments without having to babysit a script for every state in the life cycle.

    Shimel: Agreed.

    Ragan: So we have a ways to go.

    Shimel: I agree 100 percent. But I’m gonna tell you—you know, and this, again, it’s not my original thought, but it’s something I’ve heard and I fully agree with, and that is I don’t think it’s the mission of DevOps or CD or ARA, you know, that we’re gonna totally eliminate waterfall. I think there are, you know, situations where waterfall—excuse me—where waterfall may, in fact, be the right solution to the problem. I think—[coughs] excuse me, Tracy—I think there are other areas where some sort of combination of waterfall and Agile, waterfall and DevOps, you know, some continuous kind of stuff, you know—it’s like that—you know, General MacArthur said, “Old soldiers never die; they just fade away,” or something like that. I think old development styles and techniques never die either, so I don’t necessarily believe in throwing out the baby with the bathwater. What do you think about that?

    Ragan: I think technology will change that. When you’re talking about monolithic applications that have been around for a while and they have some sort of a cadence that they’ve been going through, where they have developers developing and testers testing and production teams managing the production releases, you’re probably right. It’s gonna be some sort of a water-Scrum-fall or what we’re calling “bimodal” approach.

    But, with the introduction of microservices, that is going to change the way—if it’s not a monolithic application, as we move into microservices, even though it solves—microservice solves some problems, it’s going to complicate the landscape of the production environment, which means that the need to have these production operation types and these testing types working hand in hand, on the development team, will be critical. So, as we see microservices become more prevalent, we’re going to see waterfall slowly die.

    Shimel: Okay.

    Ragan: It’s just the nature of micro-services. Now it becomes—microservices becomes code as well. Everything has become code, which means that the productions teams are not gonna be able to track and manage that level of detail in the production environment. It’s gonna go beyond just a collection of DLLs or a WAR JAR file that’s going out to an end location. It’s gonna complicate matters and it’s gonna change the way we—it’s gonna change waterfall drastically.

    Shimel: Yep. And so it’s gonna change it drastically and maybe it does evolve, if you will, but I think that’s what technologies—I think—you know, one of the things I’ve learned over too long, being in this business, is we don’t see revolutions as much as we see evolutions. And then, when we look back over a five-, seven-, 10-year span, it seems like, “Oh, my God, that was revolutionary.” But, from the day to day, it’s rather evolutionary.

    Ragan: I would agree. When it comes to—you know, we have—if you look at the macro and the micro, when it comes to the micro level, we have changed—you know, software developer bank doesn’t evolve anymore; it’s revolutionized. And that is due to Agile. What happens is is that, in some of these enterprises, the fear of doing frequent releases has slowed down the adoption of lean practices at the production state. That, we have to fix because there should be a revolution. If an end user needs a fix, it needs to get out there. It shouldn’t evolve over a six-month period.

    Now, if we look at the macro, we take a—you know, we soar up a few miles up—when it comes to major shifts in the way the community at large does business, it is a evolution. Everybody—I mean, I was at the Gartner data center show last December, and very few of those enterprises had even completed the adoption of cloud. They still had big, you know, warehouses of servers, so you’re right. From the perspective, I would say, the data center adoption, it does evolve, but, at a micro level, I think that we see a revolution in the way developers want to develop software and are driving software, and that’s where the microservices is gonna change a lot of how we do things. And I think, as more developers push for that, I think it’s gonna happen faster than we think.

    Shimel: I don’t—I—so that, along with the evolution versus revolution thing, I think the speed of—you know, this internet time speed warps, you know, the world we live in. It just—I mean, it’s crazy. So it’s no doubt about that one. Tracy, we’re actually—I didn’t realize—we’re kind of over our time, but it’s okay. These things often run over. Let me just quickly bring it back to OpenMake. What are you guys—anything new? Announcements feature-wise? Or what’s happening over there that you may wanna share with our audience?

    Ragan: Well, we have our DeployHub product that you can become part of the open-source community and participate in freely-available continuous deployment at deployhub.org. We are also—we’ll be getting a press release out very shortly here, regarding a SAS version of our continuous deployment solution, which it will be both a supported version of the open-source, as well as the pro version which includes release management capabilities, all from a SAS model, so you don’t have to download anything. We can do that because we’re agentless. Makes it real easy to support people in a cloud model.

    Shimel: Excellent. Tracy Ragan, CEO of OpenMake Software. Thanks for being our guest on DevOps Chat. Hope to have you on soon—have you on again soon and you can keep us posted.

    Ragan: Okay. Thank you, Alan.

    Shimel: Thank you. This is Alan Shimel for devopsy.kinsta.cloud and DevOps Chat. Have a great day, everyone, and we’ll see you soon on the next chat.

    — Alan Shimel

  • 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

  • DevOps Chat: Measuring DevOps Success with Steve Boone, UrbanCode

    DevOps Chat: Measuring DevOps Success with Steve Boone, UrbanCode

    In this DevOps Chat we speak with Steve Boone, product owner and development manager for Urban Code Deploy. Now that DevOps is in practice at more organizations, measuring DevOps success is a question many are asking. Steve has helped hundreds of companies adopt, implement and scale their agile and DevOps practices as part of their digital transformation. Steve gives us some insights into how can you measure your DevOps success.

    As usual the streaming audio of our chat is below. Following that is a transcript of our conversation to follow along.

    Audio

    Transcript

    [su_pullquote align=”right”][su_custom_gallery source=”media: 117787″ width=”100″ height=”100″] Steve Boone
    Steve Boone is a DevOps SME at IBM. He has helped hundreds of companies adopt, implement, and scale their agile best practices including CI, CD, Environment Provisioning, and Application Release Automation. Steve is currently the Product Owner & Development Manager for IBM UrbanCode Deploy.[/su_pullquote]

    Alan Shimel: Hey, everyone, it’s Alan Shimel, devopsy.kinsta.cloud, here for another DevOps Chat. I’m happy to be joined today by Steve Boone. Steve is the Product Owner and Development Manager for IBM UrbanCode Deploy, one of the leading CI/CD solutions in the market. Steve, welcome to DevOps Chat—how are you?

    Steve Boone: Doing great, Alan. Thank you so much for having me today.

    Shimel: Great. Steve, I wanted to talk to you—well, about a couple of things today. But let’s focus in first on, I’m just back from another major conference, and once again I’m—not amazed, because by this point, it’s expected. But still, you know, going strong, the biggest thing we get, or the biggest feedback that I hear from organizations looking to do DevOps transformation is—hey, this all sounds great, it sounds really good, but how do we know, you know, first of all, how do we get started with our DevOps transformation, and then once we’re doing it, how do we know it’s working? Right? How do we measure the ROI, or even if we can’t get to a real ROI, how do we measure progress? What does success look like?

    And I would imagine, you know, the guys at UrbanCode, the team at UrbanCode has been dealing with this for some time. What do you tell people?

    Boone: Yeah, that’s a great question, and it’s—you know, I think it’s a little different for everyone. And when we start looking at measuring success and first finding out, you know, where do we start, a lot of times we’ll work with customers to identify, you know, what are your problematic areas? There’s a lot of aspects to DevOps, it’s not all CI/CD, there could be aspects of agile planning, there could be release management. There’s a number of different things that come into play.

    So, we usually sit down and try to focus on, you know, where do you think your bottlenecks exist today, and then start to address those. But when we went to measure—and you know, you’re right, the allure of DevOps comes with all of this ROI promise, right, where if we do these things and we change our people and our process and our tools, we’re gonna be better off for it, the business is gonna be better off for it.

    So, how do we then make sure that’s actually happening, right? That the time and energy that I’m putting into changing my processes are actually showing me that ROI.

    So, what we’ve seen a shift in the industry towards is really starting to gather the different sets of metrics that are coming from, really, the end to end products that we’re dealing with in DevOps whether it’s your build tools, your testing tools to understand what I’ll all our key metrics. So, you know, if in fact we are capable of speeding up our delivery to our pipeline, we should be getting to market faster, right? So, we look at statistics like cycle time—how long does it take for an application or a release of application to go from dev to prod? And then we look at that data over time. Is it, in fact, improving? And if not, we want to identify other bottlenecks that are kinda holding that progress up.

    So, if I look at a set of components that make up an application and I see that the majority of those components have a really good cycle time, you know, we’re only as fast as our weakest link. So, if the database component, for example, is routinely slower to get through QA than the rest of the component, that’s going to slow down our time to market and therefore gonna slow down our release.

    And the beauty is, in turning on the flashlight, so to speak, so that you can see that data and actually do something with it, a lot of times we look at it and say, “Well, we know we have automation and therefore we know we’re going faster.” But that just might mean we’re going to QA faster or we’re going to dev faster. We want to make sure that we’re actually getting that ROI, so if we can set baselines with teams and say, “Hey, prior to doing this automation, it took you four months to get from dev to production out the door, right? This past release cycle we did it in three and a half months—great. What is that time savings? What does that time savings mean in cost?”

    And, we’re starting to see a big trend within the industry of many different companies starting to put together products to start to track these. So, I think it’s a whole new area for us to focus on, and in hopes—what we’re trying to share with customers is that, look, not only are the changes in people and process that you’re making working, but the tooling is working, and hey, here are some areas where you can improve those processes.

    Shimel: Yeah. So, Steve, obviously, I want to—you said a mouthful, there. [Laughter] But let me focus in on one thing you said that I want to re-emphasize to our audience, and that is, you know, DevOps is so much more than CI and CD, right? There’s config management, there’s APM—there’s a lot that goes into this umbrella term that we call DevOps, and it seems to be growing every day.

    That being said, though—you know, I once heard someone describe DevOps is the symptom and CD is the cure. So, you know, I don’t want to minimize the importance of CI/CD, but you know, automation—there’s so much that goes into this equation or this term that we call DevOps. And I think that’s—you know, Steve, it’s almost like it’s its greatest asset but it’s also its greatest liability, you know what I’m saying?

    Boone: Yeah, there absolutely is. I think that a lot of times, we definitely see, when people are talking DevOps, their focus tends to be on CI/CD. And I think that’s because, you know, out of the gate, especially if you’re just starting off, it’s kind of your biggest bang for your buck, right? You can get a lot of fast return on investment just by improving your processes and automating them and making them consistent.

    As we see teams mature, and as they transition into a more Enterprise wide DevOps solution, then we start to see—well, where are the real boundaries in my organization, right? Is it, we see a growing trend where app dev teams are focusing on automation, but there’s a whole different silo in infrastructure, you know? So, an app dev team wants to request an environment to do some testing in—they have automation, and the tools that they have for automation could easily provision that environment. But the business dictates that that’s the infrastructure’s just, and they have a completely different set of tools that they use for that, right?

    And so now we get into this challenge of really continuing to try to break down these barriers to make sure that these assets and tools that are out there can work together, and that there’s clear cut guidelines on that.

    So, yeah, I think it is a blessing and a curse, right? Because when we start thinking about DevOps, everybody wants that—you know, we’re a culture of having that instant gratification. So, it’s nice that we can get that with deployment automation and build automation and test automation. But we need to be looking ahead to the future, which is gonna be—hey, I’m gonna provision these things on demand and make these environments available to my teams, and today we use Amazon for that. What happens if, six months from now, we have to change and we need to support Azure or Google or SoftLayer or Bluemix, right? We need portability, we need full stack provisioning and config management on that.

    And that’s—I think that’s something that, a lot of times, people just starting out, they don’t look too far ahead. And my suggestion to folks is—hey, it’s okay to take that first step. You should be cautious about the first step, but keep in mind where you wanna be two years from now, three years from now, five years from now. What’s your DevOps end goal?

    Shimel: Yeah. You know what? So, Steve, I think that might be the first question we need to—especially for consultants out there who may be listening to this. You know, whether you work for an IBM or a small consultancy, I think that has to be the first question. You know, people come and say, “I want to do DevOps.” You gotta ask them, what’s the end goal, here? What’s the end game? Why? And that’s a huge piece of it.

    Steve, if I can, I’d like to turn to a little bit more about UrbanCode and, you know, UrbanCode’s kind of a unique animal, if you will, in that, you know, it was one of the earliest, earliest kinda startups playing in the CICD space, right? And so it had that whole startup culture, if you will, the startup thing going on. And then, of course, you know, acquired by IBM and really become a linchpin of, you know, IBM’s DevOps, and not only DevOps, but you know, in IBM, as you know, DevOps is tied into cloud and hybrid and Bluemix and SoftLayer and all the things you mentioned. You know, it’s such a critical piece of that puzzle.

    What is happening lately with UrbanCode? I saw Gartner give you guys some accolades recently.

    Boone: Gartner gave us some accolades. We scored very well, as well, on the Forrester Wave that just came out.

    Shimel: The Forrester—yes.

    Boone: We were named as a leader in the—yep, in the Forrester Wave. So, that was exciting. It was a great score for us. We’re about as far right in that quadrant as you can be.

    And there’s a lot of really good things coming out. I think the reason we scored so well is that they’re looking at the strategy within UrbanCode and seeing that, you know—as you mentioned, this isn’t our first trip around the block. We’ve been helping customers do this for over 10 years. And for us, you know, we work with companies that are small startups to everything that are enterprise financial institutions and healthcare and government agencies.

    So, there are, at any given time, different, I’ll say, business focuses that are in a different spot of transition. So, I can go to an enterprise and talk to 30 different groups and organizations in that enterprise—they’re all in a different maturity, they’re all in a different level and area of that DevOps transformation. But what we’re able to do is, we have a solution that can help everybody regardless of where they’re at, and as they mature together over time, ultimately help them reach the goal where the company wants them to be.

    You know, some of the new things that we’re focusing on—you know, last year, part of our vision, we had announced at Interconnect our DevOps Insights product as well as our continuous release product that are focused on helping customers one, transition into DevOps, do a lot of that deeper reporting and ROI analysis on where they are in their transformation, but as well as help companies manage to the cloud and for the cloud.

    What I mean by that is, you know, today, we talk about cloud like it’s ours, but for large enterprises, it’s still very much a challenge. You know, it’s hard for a team to just go request access and say, “Hey, I’m gonna push my data to the private cloud.” There’s still a lot of—or even public cloud, whatever it might be. There’s still a lot of hurdles to that.

    So, what we’re trying to do is, as teams embrace this and they’ve got deployments going on-prem and off-prem, how do we organize that? How do we have visibility and traceability and understand as you’re taking large applications and breaking them down, let’s say, into microservices? You know, some of those applications are easy to re-architect, some are not. And sometimes you’re left with applications where you’ve only got maybe three quarters of that application re-architected, or you’ve got databases that are always gonna be on-prem, or you’re using mainframe services.

    And that’s really where the UrbanCode products excel, is allowing you to really deploy anything, anywhere, but also have a cohesive look at, what are the interrelated appendices of those parts? If something on my backend mainframe changes, how is that affecting the things that I’ve deployed into my mobile app? And if something needs to fall out of just release, you know, what’s the impact, even? How is that gonna affect business? And I think those are some of the main reasons why we scored well within the Forrester Wave and why they marked our strategy so high.

    Shimel: Absolutely. You know, Steve, we’re coming up on the end of our allotted time, unfortunately, but I wanted to mention one thing if we can talk about it, and that is that you spoke about Interconnect, which has been the big IBM DevOps related show, as well as other technologies for the last couple years. This year, IBM is kinda consolidating a lot of the shows they do into a pretty big mega-event called Think 2018, and of course, that is gonna be once again at the Mandalay Bay in Vegas, and it’s happening March 19th to the 22nd. I believe the call for speakers has just opened, and I’ll put some links in the show notes so that people can, if they wanna speak or if they want to attend the event would be great.

    But in any event, what’s UrbanCode’s plans around Think 2018?

    Boone: Yeah, thanks. I hope folks do and are able to register and come out. It’s going to be a fantastic show, and it is very much a mega show for us. So, we’ve taken—I believe there’s 11 different topics that really, I’ll call them focal points or even think of them as investments within IBM. Everything from cloud to Watson to mobile to security, internet of things—there’s a number of different topics going on at this.

    UrbanCode will be under the cloud focus, and we’ll—underneath the cloud topic, there’s a section specifically for DevOps. So, if that’s what you’re interested in, come out and check us out—we’ll be there. We’ll be talking about our latest release that we’ll have done at that time, and we’ve got a lot of really cool features that were actually in development and testing right now that we plan to announce at the Think conference, so without be demo-ing those, and we’ll have—as always, have a bunch of UrbanCode customers there sharing their ideas, sharing their experiences, and really helping educate how they’ve transformed their business.

    And I think what a lot of folks will find appealing is that it’s never a one tool solution, right? And that’s one thing I always encourage folks is, when you’re trying to be in a DevOps transformation, a single product, a single methodology—it’s not gonna do it. You really need to embrace the various tools that are in the market, you need to embrace existing tools that are already in your company, and these are gonna be working examples and explanations of how some of the top companies in the world are doing just that using UrbanCode and using a variety of tools that we support.

    Shimel: Absolutely, absolutely. Alright, Steve, we’re actually way over time, I apologize, but I think we got some good information here that people will be interested in. I want to thank you for being our guest this week on DevOps Chat and invite you back soon. We want to hear more about Think 2018 as we get closer as well, but good luck with UrbanCode, Steve, and we’ll speak to you soon.

    Boone: Hey, Alan, thank you. As always, appreciate you having me today.

    Shimel: Alright. Steve Boone, Product Manager, UrbanCode Deploy—or Product Owner, excuse me, UrbanCode Deploy. Thanks for being our guest on this DevOps Chat. This is Alan Shimel, and we hope to see you soon on another DevOps Chat.

    — Alan Shimel

  • DevOps Chat: IBM z14, Built for DevOps from the Ground Up, with Hayden Lindsey

    DevOps Chat: IBM z14, Built for DevOps from the Ground Up, with Hayden Lindsey

    IBM recently GA’ed perhaps its biggest zSystems mainframe release in the last decade or longer. The z14 mainframe from IBM has also been designed from the ground up to be DevOps-empowered. From APIs and other integrations to language support, the z14 is IBM’s most advanced mainframe ever. I had a chance to speak with Hayden Lindsey, VP of DevOps Enterprise Systems for IBM, about the z14.

    Hayden gives us the low-down on how the z14 has been designed to work in hybrid environments. It also works well with modern CI/CD tools such as Urban Code and others. Additionally, APIs give it the ability to integrate with many different environments, tools and apps. It is truly a mainframe for today and beyond. Hayden does a great job of describing all of this.

    As usual, the streaming audio of our conversation is below, followed by the transcript of our conversation. Enjoy!

    Audio

    Transcript

    [su_pullquote align=”right”] [su_custom_gallery source=”media: 117632″ width=”130″ height=”130″] Hayden Lindsey

    Hayden Lindsey, Vice President & Distinguished Engineer – DevOps for Enterprise Systems. Hayden is responsible for the development, product management, sales enablement, and services of this portfolio. He has worked at IBM for 28 years and has held a variety of positions, including software developer, product architect, product manager, co-leader of the Eclipse tools platform, and director of the WebSphere Studio/Rational modeling and construction tools. He has a bachelor’s degree in Mathematical Sciences from the University of North Carolina at Chapel Hill.[/su_pullquote]

    Alan Shimel: Hi, everyone, this is Alan Shimel, devopsy.kinsta.cloud, here for another DevOps Chat. Our guest on this episode of the chat is a good friend of ours, Hayden Lindsey, VP, Enterprise DevOps at IBM. Hi, Hayden, welcome to DevOps Chat.

    Hayden Lindsey: Hi, Alan. Good to be with you again.

    Shimel: Good to have you here. Hayden, it’s a big day—big day for the folks over at the IBM Enterprise team. It’s the general availability of z14 today, isn’t it?

    Lindsey: It sure is. Yes, we announced this back in the middle of July and we’ve now been making our products available. A lot of mine were available the latter part of last week, and now the box itself, GA, today. So—a big day.

    Shimel: Fantastic. And Hayden, just—you know, our audience being so focused on DevOps, they may not realize the full scale of what the z14 release is about. What it is, it’s a combination of hardware—as you mentioned, a new box. There’s a ton of software, there’s a tone of integration—it’s just chockfull of all kinds of goodies. Can you give us kind of a—at a high level, the scope of z14?

    Lindsey: Sure. And I think what you see is the result of pulling software, both middleware and tools, from the various divisions that we used to have like Rational and WebSphere and moving those into a single z or mainframe focused brand.

    And so, in contrast to most prior hardware releases where you’d be hearing about the speeds and feeds and, you know, the z13 had the fastest processor of any box on the planet—this time, the focus is more on the entire solution that involves both hardware as well as software and tools. And so I think—we worked on that, we did design thinking, we had sponsor users, we did the whole nine yards form the hardware up through the operating system, middleware, and tools, and I think that made a big difference.

    And so this time, for example, we have something called pervasive encryption. We all know how important security is, we all hear about these breaches that are happening—Experion being the most, or Equifax being the latest one. And, of all of the records that have been stolen, and I think it’s something like 9,000,000,000 since 2013—only 4 percent are encrypted. And this new mainframe lets you encrypt 100 percent of the data with no impact to performance. So, that’s just—that’s one example. Clearly, there’s hardware stuff there, but there’s also middleware that had to be involved in making this solution. So, that’s an example—it’s really cool.

    Shimel: That’s actually a big example, Hayden, because you know what? Encryption has been around—I mean, I spent 20 years in the security space and encryption has been around for most of that. The problem was the hit you took on performance when you encrypted and then had to decrypt and re-encrypt just the latency and—

    Lindsey: And the programmer had to do it. [Laughter] Or the database administrator had to set it up for the database, but then what about when it was being used in the application? And so that was—this is what is being solved, where you don’t have the time inhibitor of people doing it, and then you also don’t have the performance impact where it makes a system unusable.

    So, I think this could be really groundbreaking for the companies and the government agencies around the world that deal with sensitive data.

    Shimel: Sure—and we all do now. Hayden, you said something else, though, that I wanted to key in on, and that is sort of moving away from the speeds and feeds, if you will, metrics of—you know, to measure the value of anything. And I worked with a woman once, and she used to call that bag diving. Right? You know, when you gotta start getting into the speeds and feeds to show the value of your product, you’re diving into your bag instead of talking the true value.

    Lindsey: Right.

    Shimel: So, I’m happy to see that that’s kind of the path that IBM is taking, talking about the value, but I also think it’s a result, as you said, of so much being added into here, right, from the design thinking around the entire release, if you will, to the integration with things like cloud, with the DevOps entire tool set and methodologies that IBM and others have developed.

    This is so much more than just, “Oh, we put—this is the next iPhone with the faster processor.” This isn’t the next z with the faster processor, it’s much more than that. As I think I—maybe you said it earlier or maybe we talked about it off-mic. This is probably the most substantive release for z in at least a decade.

    Lindsey: I think it is, and of course, the market will tell us if our aspirations come to bear or not, but I certainly think the encryption element is just—well, I think it’s phenomenal, and it could be very, very, very significant for virtually any company out there.

    And then we’ve got more on machine learning and analytics so that you can do in transaction analytics rather than doing it after the fact and having to try to back out or just write off fraudulent transactions. And, of course, we’ve done a lot with our DevOps portfolio compilers. But I really do think, maybe, since we put Linux on the platform, it’s that significant.

    Shimel: Wow. Huge. So, Hayden, we are about DevOps here, so let’s focus in a little bit. I mean, one of the nice things is, I’ve seen some briefings around how you can use the new z14s with the IBM Enterprise DevOps solution and really sort of leverage—I don’t wanna use the term bimodal multi-speed nonsense. Leverage integrating your z system with cloud systems into one coherent business strategy. How’s that sound? [Laughter] So, talk about it.

    Lindsey: Yeah, so one of the three themes for the release is open and connected, and that obviously ties into a hybrid cloud strategy. It ties into, you know, a digital economy or digital transformation. It ties into API economy—whichever angle you want to take, you have to be able to make the data that resides on the mainframe, which is estimated that roughly 80 percent of the Enterprise data in the world resides on and is managed by the mainframe, and about 70 percent of the business transactions.

    And so, if you want to, though, make that available to your new iPhone X app, as we saw introduced yesterday—you know, or 10 or whatever they’re gonna call it.

    Shimel: Mm-hmm. Yeah, they’re calling it 10.

    Lindsey: They’re calling it 10 using a Roman numeral.

    Shimel: Yeah.

    Lindsey: But, you know, if you’re gonna do that, you have to make it easy to access the data and transactions, find those transactions, understand them, because very likely, they were written by somebody who’s not around any more or had moved on to other jobs. And so, you need to have tools that make API enabling and opening up and connecting to the mainframe easy and efficient, and just as easy, just as efficient as you would if you were opening up something on the Linux platform—although, of course, you have Linux on z—or a Windows box or anything else. So, that’s—it’s essential that we allow z to participate in the broader digital economy, API economy, and that’s what my team has been focusing on, along with other teams in IBM.

    Shimel: Sure. So, now, Hayden, in that same vein, you know, there’s still that mainframe attitude where, you know, we don’t open our mainframe up to all of these APIs, and maybe we don’t want to hook into our systems of engagement, you know, up in the cloud or what have you.

    For clients listening out there—and a lot of our listeners are Enterprise class, they work in Enterprise class organizations—how important is it that they really consider opening up, you know, their mainframes to this API economy, as you called it?

    Lindsey: Well, I think increasingly, certainly, the IT and line of business executives, the clients with whom I work, are realizing they have tremendous assets that they could leverage if they were to make them available. Nobody—at least no companies I know of, or government agencies, have the resources to just recreate everything from scratch. And, I think if you look back at what the analysts were saying back in the SOA era, they said, you know, it was five times faster to create a service leveraging something that exists that already does the same thing or something very similar than it is to create it from scratch—not to mention the fact that, if it already works, you’re likely to have higher quality as well. And I think the exact same analysis would prove to be true now that we’re talking more about RESTful APIs.

    So, I think more and more clients realize they need to expose that value. The key is, just, it’s sometimes daunting when you’ve got—you know, the estimate is like 250,000,000,000 lines of COBOL, not to mention PL/I and Assembler and 4GLs and so forth. It’s getting your arms around applications that were probably created in a more monolithic, less well-structured fashion. You need to do refactoring. You need to discover what is there, and then put together a plan for doing that API enablement.

    But I think people know they need to do it, it’s just, sometimes it’s viewed as a daunting task and they have to figure out how to get started, and we have something called the digital transformation model that we’re rolling out to help our clients put a plan in place.

    Shimel: Got it, and I agree. So, you’re just setting me up for my next things here, but—so, that’s the biggest question we hear at devopsy.kinsta.cloud, Hayden, which is—hey, this is all great. How do we get going? How do we roll this? How do I get executive buy-in? How do we—is there a one, two, three? Is there a blueprint I can follow.

    So, z14, let me throw it right back to you—where do we start? How do they get moving with this? How do they—and specifically, how do they start incorporating the DevOps and API stuff into this?

    Lindsey: Yeah, it’s the question that I hear from virtually every customer I talk to, and I’m getting ready to do a tour in Europe next week, and I’m sure it will come up in every single meeting. And the fact is, every customer is different, so there’s no single answer. And, within any given client, they have applications that span the gamut from nearing end of life to ones that are under active or brand new development. And so, what we’ve—but, of course, there are patterns and similarities across clients and application types, and there are best practices that we have gleaned by working with clients through the years, and that’s where I mentioned this thing called the digital transformation model.

    We’ve shifted to this way of working with our clients to focus on applications rather than one answer for the Enterprise—hey, you should start with deployment automation, or you should start with test automation. That answer should not be an Enterprise answer, it should be for this suite of applications because of what their current state is, the as-is state, and what you desire the to-be state to be. If you just need something to run efficiently and you’re gonna replace it in a few years or retire it, all you want it to do is run efficiently.

    So, use our latest compilers, but you know, the fact of the matter is, putting in a fully automated pipeline is likely a wasteful effort. Whereas, on the other end of the spectrum, for the things under very active development, that’s where you want to do DevOps in its fullest, and really, it’s just a matter of what steps do you take to get there.

    And so, this model that we’ve come up with has four levels—the first one I described about, just do your compiling, is run—just run it. Just run it efficiently. The next is maintain, the next is expose, the next is evolve. So—I mean, and I don’t know if we’ve got the best names in the world, but the fact is, you really need to think about, for the business, what degree of DevOps adoption do you need for a given application or application suite. So, that’s the more, I think, realistic answer that we’ve been using with clients this year and a tool that we’re using that’s different from what we’ve done in prior years.

    Shimel: Excellent. So, Hayden, I mean, just to illustrate this, I remember back at Interconnect last year, you know, we had the whole little DevOps TV booth set up, and I was interviewing some IBM clients. And one of them, it was a bank, and I forget if they were from Poland or the Netherlands now, or maybe even Australia. They were IBM’s z System customer and they had just updated, I wanna say, from COBOL 4 to 5—maybe it was 5 to 6, I don’t remember now.

    But they had just updated their version of COBOL, and it made a huge, huge difference for them in terms of performance and—

    Lindsey: Yeah. Yeah, exactly. You know, we’ve—one of the things that our compiler team does every single release, and this starts from the very earliest days of, we were just imagining what the new mainframe or new power platform is going to be. We were working hand in hand with the hardware folks.

    And, you know, with COBOL specifically, where something like 70 percent of the world’s business transactions are running COBOL, obviously, performance does matter, and so this is where you can get into a little bit of feeds and speeds. Mainly because, not because—some of the numbers aren’t eye popping, but it’s because you can be more responsive for your clients. But with some compute intensive apps, they run 16 times—not percent, times—faster on the latest compiler, which is 6.2, versus 4.2, which may be where that client was coming from. So, that’s skipping the version 5 things, but we still have the majority of our clients on the 4.2 version.

    So, it’s tremendously faster, but this is by doing this joint development. You know, if you put new instructions or new vector support in the hardware and the compiler doesn’t generate these new instructions, well, then, obviously, no client is gonna be able to take advantage of it unless they want to write their own assembler. So, you know, our compilers are delivering tremendous value, and I gave you a COBOL example, but you get similar results with PL/I and with our automatic binary optimizer that basically just does the, tries to do the work that the compilers do, but just working on binaries rather than having you go back to the source.

    So, it’s a big deal. You know, and the less—it’s maybe a bit more mundane. Yeah, the stuff runs faster and, as you said, diving into the bag. [Laughter] But, you know, when you’ve got numbers like 16X or 5X or what have you, that’s huge.

    Shimel: It sure is, it sure is. So, Hayden, you know, I mentioned Interconnect, too, and as we’re running low here on time, I just wanted to quickly prompt you on that and let our listeners now.

    So, this year, Interconnect is part of an even bigger kind of unified conference that IBM has put together called Think—Think 2018, I believe it’s called, and if I’m not mistaken, it’s March.

    Lindsey: Yes.

    Shimel: Go ahead.

    Lindsey: Well, you might see a trend here. [Laughter] Because, you know, Interconnect was the combination of Impact and Innovate. Innovate—I think that’s the name it was. I’ve kinda forgotten, but anyway, we had a Rational conference, we had a WebSphere conference, we had IoT stuff and all that. And now we combine those into Interconnect—at least the WebSphere and Rational stuff. And it got bigger, and now we’re doing something that is more or less IBM-wide and it’s called Think. It’s gonna be the week of March the 19th at the Mandalay Bay in Vegas, so still in Vegas like most of our other conferences have been of late.

    And so, I think there’s pros and cons to having a more broad, where we can tell the full IBM story, and that’s the focus, and you’ve got SMEs from all the different areas of the country, be it cloud, cognitive, Zpower, what have you. But I think that’s great, but because you do have those experts, and we will have the breakout sessions or keynote sessions on specific areas, be it DevOps or z or compilers or deployment automation like UrbanCode.

    So, there will be still those specialty sessions, and yet you get the big picture. And the one thing that I would like to ask your listeners is, the call for papers is open, and you know, we are shooting for having 100 percent of the talks in the various tracks either be a customer or partner only, or being customer and/or partner jointly with an IBM-er, but we’re just really trying to get away from IBM-er talking head telling a story without a partner or a customer there saying what they’ve done in real life with a given solution in a given area.

    So, we’d really love to have as many partner and client nominations as possible.

    Shimel: I love that idea. You know, I shared a panel the last two years, Hayden, on Dev—I think they were on, well, it was on DevOps and then SecOps. But, you know, I tried really hard to balance it with—yeah, we had one person from IBM, but we also had an analyst and then we’d have a partner and then a practitioner. And I think that sort of balance gives it, it makes it—

    Lindsey: It adds some legitimacy to the whole thing and different perspectives.

    Shimel: Yep. Just real quick, for anyone listening, if you go to IBM.com/events/Think, you can get all the scoop there and follow the links to submit. And as Hayden said, if you’ve got something to say and share with people, it—having been to three or four of these, or more, it’s a great platform. So, I’d encourage everyone who would like to participate to do so. And even if you don’t want to speak, but if you want to go really understand what’s happening, whether it be with Watson or z Systems or hybrid cloud or Bluemix or any of those things. You know, if any of those are important to you, I think it’s a great show to attend.

    Hayden, we’re about out of time—we’re actually over time, but that’s okay. Thanks so much for taking the time on what is a busy day with the general GA of z14. Best of luck with it. Let’s check in, I don’t know, maybe before the end of the year, and see how—you know, what kind of market reception a lot of these features and capabilities are receiving and we’ll see where the rubber is meeting the road.

    Lindsey: Sounds good, Alan, and thanks, again, for your time.

    Shimel: Thank you for your time. Hayden Lindsey, VP, Enterprise DevOps with IBM on GA Day for z Systems z14. Thanks, Hayden, have a great.

    Lindsey: Okay. Bye for now.

    Shimel: This is Alan—thank you. This is Alan Shimel for devopsy.kinsta.cloud. We’ll see you soon on another DevOps Chat.

    — Alan Shimel

  • DevOps Chat: The Continuous Delivery Map w/ Scott Wilson, Automic

    DevOps Chat: The Continuous Delivery Map w/ Scott Wilson, Automic

    Wouldn’t it be nice to have the entire continuous delivery topography laid out in a nice map that shows how they are all interconnected? Sort of like a subway or metro map? Well now you have it and it is interactive! The good folks at Automic, a CA Technologies company just released their Continuous Delivery Map. It is really cool and they are adding to it all the time.

    I caught up with Scott Wilson of Automic and had a chat about the Continuous Delivery Map. As usual the streaming audio of our conversation is immediately below, followed by a transcript of our chat.

    Audio

    Transcript

    Alan Shimel:                Hey, everyone, Alan Shimel, devopsy.kinsta.cloud here for another DevOps Chat. Welcome and welcome to our guest, Scott Wilson, Automic, a CA Technologies company. Scott, welcome back to DevOps Chat

    Scott Wilson:               Thank you, Alan. I’m glad to be here.

    Alan Shimel:                Glad you’re here with me. So, Scott, you know, lot going on with Automic, obviously – always is – but I wanted to focus in today on some pretty cool interactive graphic – well, it’s more than just a graphic. It’s really a whole project that you guys have launched and it’s called the “continuous delivery map.” For those following along at home, if you wanted to check it out, you can get to it at automic.com/continuous-delivery-tools and – dash or a hyphen. Scott, you know, assuming people are listening to us but not able to get to the site this second, can you describe for us what the continuous delivery map is?

    Scott Wilson:               Yeah, so the continuous delivery map is really just a way to visualize a topography, if you will, of all the different tools that are in the continuous delivery value chain, and there are lots of tools. And we found, in talking with a lot of prospects and just other companies in the industry, that amongst IT professionals there’s a bit of confusion on what kind of the best use case is for many of the tools, mostly, Alan, due to so many of these tools having a great deal of crossover functionality, right? It’s kind of muddied, blurred the lines a bit.

    And so, in thinking about a good way to help people out and kind of visualize the tool chain used to get an application into production environments, we took inspiration from metro rail systems, like the London tube or the New York subway, and so we built out a map that looks similar to that.

    Alan Shimel:                Yeah. I mean, for those of you, as I say, who maybe can’t get to a computer right this second, as you’re listening to this, it really is. It’s based on a subway map or a tube or it could be the Washington metro or the Boston or Tokyo or anyplace else, in that you have a central hub and then there’re different lines that are color-coded. And each of these color-coded lines represent a lineage or a line of a particular functionality in the continuous delivery world. So, for instance, there’s a line for cloud, IaaS and PaaS. Another line for middleware, another one for CI tools. Another one for artifact repositories. And, along that line, the stops are all of the different companies that kind of play within that are or are on that, and it’s not just companies – it’s actually the products of these companies that play on that particular branch, if you will.

    So it’s actually pretty cool, Scott, and what I like about it too is, though, look, plainly and clearly, Automic is a vendor. I mean, there’s no favorites here. You’ve done a pretty exhaustive mapping or the whole topography of the continuous delivery world, it looks like, to me anyway.

    Scott Wilson:               Absolutely. We really wanted this to be agnostic for the tools. We’re really just trying to help the community understand, you know, the landscape for continuous delivery, and, as you mentioned, the central hub is really the way you would bind all those many plethora of tools into a coherent pipeline, right, to safely and reliably deliver apps to production environments. And, yeah, this definitely respects that. Ultimately, we’re gonna be opening this up to the community so that people can comment or keep this updated ’cause there’re always new tools coming on board and other tools or open-source projects that kind of fall out of vogue, so we’re looking to really make this more interactive and far – we’ll keep it up to date.

    Alan Shimel:                Yep. And, you know, again, trying to visualize or paint a picture for people who don’t have it in front of them, at every stop on every branch, if you will, it’s a link, and if you click on that link, it gives you a little pop-up with a little information about that particular company or product but also links through to their full websites or what have you. So it really is – I could see this being a really useful tool for anyone interested in the CD kind of world. There have been – I mean, clearly, Scott, right? Full disclosure: there’ve been other companies that have tried to organize, if we will, the CD world, but, really, using this paradigm of the subway map and the branches and lines, if you will – maybe it’s just ’cause I’m from New York and I’m used to subway maps –

    [Laughter]

    – makes a lot of sense to me.

    Scott Wilson:               Right. Well, we’ve heard that feedback as well that that’s just – well, you know, continuous delivery’s about movement, right? You’re moving things along and it just seems to help visualize it. You know, a lot of the data from what other folks have done is similar, right – a big list of tools – but just being able to put it in a format like this, we’re finding a lot of people go, “Ah, this makes sense. I would use these set of tools. Source code management fits here and deployment automation fits there.”

    And it’s helpful because I think, without presenting it this way, you’re just left to a hodgepodge of tools and you’re like, “Yep, I got ten of these and two of those and I’m good.” When you look at it in this format, you realize, “Oh, well, I could actually go further. I could do more or I could better organize things,” or maybe even take some of the burden off a tool that you keep having it be more than it was designed for and actually use a best-of in another category, or, as we represent it as, a color-coded rail line.

    Alan Shimel:                Yeah. Yeah. And, of course, you know, the thing about projects like this, Scott, is they’re, in some ways, a never-ending story. They’re constantly morphing, changing, growing. And, I mean, the good news is you’ve got a great start right here; the bad news is you guys need now to keep this up, week in, week out, month after month. What are the plans, going forward, to keep it current and fresh?

    Scott Wilson:               Excellent observation and point. We are looking to ultimately open this up to the community, so this page will not only be as it is now; it’ll be far more interactive, where visitors can come in and recommend tools that aren’t on here, maybe further defining particular lines or branches that we have, upvoting, downvoting various tools, and, yeah, so we’re looking to have that community help us keep it up to date. In just doing the research for this and playing with many of these tools and looking at their viability to be on the map, as you said, it was a ton of work. And so it’d be impossible, with the growing market, to do that on our own, and we’re definitely looking forward to collaborate with the DevOps community at large in keeping this current, the information current and fresh and, of course, far more interactive and useful, as we go forward.

    Alan Shimel:                Yeah. I mean, you know what? I mean, this is great and I don’t know how you would visualize it, but it would be great to show sort of connected dots, in terms of how companies or products actually integrate or work together. But that –

    Scott Wilson:               So, yeah, not to give away – [chuckles] – so much what we’re planning, but, yes, you’re absolutely correct. That is something that is on our roadmap, what we’re planning. Indeed, what we think would be useful for this is to allow us to kind of rank or order the tools and use a kind of a most popular or what the market, the community says, “Now this is the best practice set of tools.” A simple example would be SQL Server and Oracle. Right? If you’re going down the RDBMS line, the database line, then, well, those two are kind of the giants. And so by ordering them such a way, you would be able to come in, list the tools that you have, and be able to visually see, “Are you kind of following what everyone, what the consensus best practice is? Or are you have a lot of outliers?” And I suspect a few outliers here and there are okay, but, you know, if you’re going two four outlines, you might be putting yourself at risk.

    And sometimes I think it’s just to help you answer that big question, is “I don’t know. Should we go with this tool or this tool?” Well, you could come here and, in future releases, be able to see what the community is saying the best of or the next best of, right, and have it ordered and you’d be able to see that in a nice map, visual way, to understand and help you to, hopefully, make decisions on what tooling you should consider or not.

    Alan Shimel:                You can also see if you’re taking the express or going on the locals. There’s a lot that a clever marketing person and someone with a good knowledge of the market here in the CD space can really make some hay with this, Scott. And, you know, beyond cute, it’s actually pretty – a really useful tool here.

    Scott Wilson:               Yeah. Appreciate that. Like I said, we’re looking to make it far more useful and what you hinted to and what I’ve just discussed is really make it really interactive and help you measure yourself against what the market or the community is doing, what the norms are, best practices and so forth.

     

    Alan Shimel:                So I’ll include a link to this, Scott, in our show notes when we publish, but, for those who may be listening on iTunes or SoundCloud or audio only, again, the URL for this CD map is automic.com/continuous – dash or hyphen – delivery – dash or hyphen – tools. And you could check it out there. Scott, you know, in real DevOps fashion, upgrades here will be continuous, right? There’s not a Linux version planned or anything like that, I would assume

    Scott Wilson:               Correct. Yes. So we have continuous sprints planned. New vendors are actually in our current sprint, that are coming out, and, yeah, so you’re absolutely right. If we’re gonna do something on continuous delivery, then we ourselves are looking to be agile and looking to keep it fresh and then, ultimately, have one of the inputs to those sprints be the community, community feedback and input.

    Alan Shimel:                Got it. So, Scott, this is really great. Congratulations to the whole team at Automic who worked on it. It’s a piece of work here that I think is highly useful. What else is new at Automic, Scott? Anything noteworthy you wanna report on

    Scott Wilson:               Well, what we’re shipping here lately, in the next few weeks, is a incremental release of our application release automation product, version 12.1. There are several enhancements that are coming out, going GA here, in the coming weeks. We’re pretty excited about that and some of the additional enhancements. There’ll be a lot of information coming out in a few weeks about all of that and the functionality and things that we’re doing with that. And then, you know, just additionally, the growth and recognition within the CA company, as an automation business unit, and, yeah, we’re keeping pretty busy with automating not just things within the continuous delivery value stream or DevOps tool chain, but also within the CA ecosystem itself. There’s a lot of growth. And so, really, what’s happening with Automic is we’re really able to help show how we can automate, really, the modern software factory.

    Alan Shimel:                Yep.

    Scott Wilson:               That’s kind of one of the – falls in line with what CA is trying to do, one of the core tenets. They’re trying to reach out to the community and the marketplace.

    Alan Shimel:                Absolutely. All about software development life cycle and software supply chains.

    Scott Wilson:               Yeah.

    Alan Shimel:                Well, Scott, thanks for giving us a peek behind the scenes at the continuous delivery map. We’ll try to feature this on devopsy.kinsta.cloud and we’ll be watching as it continues to develop, adding even more features or functionality, but it’s pretty cool stuff.

    Scott Wilson:               Well, thank you very much and, as always, I love being here and grateful you had me.

    Alan Shimel:                Well, we’ll have you back on again then. You know, Scott, flattery will get you everywhere.

    Scott Wilson:               [Laughs]

    Alan Shimel:                Thanks

    Scott Wilson:               That’s so true, isn’t it?

    Alan Shimel:                Yep. We’ll have you on again. Scott Wilson, Automic, a CA Technology company, talking about their new continuous delivery map here on DevOps Chat. Scott, thanks for coming. Hey, everyone, thanks for listening. Hope to see you soon on another DevOps Chat. Until then, I’m Alan Shimel for devopsy.kinsta.cloud and we’re out of here. Thank you.

    — Alan Shimel

  • DevOps Chat: Chef Update with Ken Cheney, Chef CMO

    DevOps Chat: Chef Update with Ken Cheney, Chef CMO

    There are always new developments going on at Chef. We caught up with Chef CMO Ken Cheney to give us an update. Last time we spoke with Ken was right after ChefConf. Since then, Chef continues to move forward on several fronts including Habitat, Automate and INSPEC. We speak to Ken every other month or so, as it is always good to know “what’s cookin’” at Chef.

    As usual, the streaming audio of our conversation is immediately below, followed by the transcript of our chat. Enjoy!

    Audio

    Transcript

    Alan Shimel: Hey everyone, Alan Shimel, editor in chief of devopsy.kinsta.cloud here, for another DevOps Chat. Today’s guest on DevOps Chat is our friend Ken Cheney, CMO of Chef. Ken, welcome back to DevOps Chat.

    Ken Cheney: Alan, it’s great to be here. Thanks for having me.

    Shimel: Thank you. Ken, I apologize, between your schedule and my schedule, it’s been a while since we’ve had a chance to catch up. I think the last time we left off it was – was it right after Chef Conference, ChefConf?

    Cheney: It was actually right before ChefConf. So it’s been a couple months, right? Given that was at the end of May. 

    Shimel: Ken, I don’t think I’ve been home for more than two or three days at a time since then. So yeah, it has been. But for our listeners who maybe aren’t lucky enough to be down in Austin and ChefConf this year, can you fill us in a little bit about maybe what we missed?

    Cheney: Yeah, so ChefConf this year, as you mentioned, was in Austin, Texas. And you know, I think the highlights of ChefConf, on the product side, were some announcements we made around Chef Automate and bringing in our open-source tooling fully under that umbrella of Chef Automate. So Chef Automate is our commercial offering. And first and foremost, we brought in InSpec fully, so now, from one spot within Chef Automate you can see both how you’re doing in terms of your infrastructure and how your infrastructure automation is going with Chef, but also from a compliance perspective you can see what’s happening in terms of policy through the Chef Automate UI. So it’s really – the product has evolved from how it was working before, where we essentially had two servers for and now you have a single, common UI for looking across all the various data points

    In addition we brought in the Habitat data so now you can see the state of your Habitat instances that are running in the wild.  And you know, what I find really interesting about what’s happening with the compliance front is that, you know, we’re really evolving quickly from just being focused on sort of core compute elements to now expanding InSpec out to cover up on cloud-based APIs. So we can now go at AWS and Azure and be able to scan those, as well as VMware environments. So you know, we’re expanding InSpec to be a language that’s not just appropriate for compute, but also for broadly managing all of your infrastructure as code. And so that was announced as well at Chef Conf. And I think that’s a bi move forward. You’re going to see that continued expansion of that InSpec language and capabilities to go after a broad set of other types of infrastructure in the near future.

    And it’s an area where we see just a tremendous interest and uptake from our customers and users. So anyone who hasn’t tried out InSpec, I really encourage them to try it as part of Chef Automate if you want to actually see that InSpec data roll up into common policy views and really understand how you’re doing at an infrastructure level, both in terms of the state of your infrastructure but also how your infrastructure is conforming to policy around compliance and security. You get that from one place. And in this world of WannaCry and other exploits that are happening, it’s amazed me how many organizations, when tools like InSpec exist, still have giant vulnerabilities, right? And here we have this open-source tool that can solve this problem of really understanding what is your exposure. And then you can use a tool like Chef to actually remediate and fix it. It just blows my mind that it’s still a common occurrence.

    Shimel: It blows your mind, Ken? For 20 years it’s blown my mind. For those of us in the security space, it’s no secret that well over three-quarters—actually, probably over 80 percent or 85 percent of attacks and successful attacks actually take place not because of what we used to call Zero Day or unknown vulnerabilities, but because known vulnerabilities were not patched.

    Cheney: That’s exactly right. That’s exactly right, yes.

    Shimel: And that’s the key. I mean even today –

    Cheney: Yeah, and –

    Shimel: It’s crazy. I’m sorry, go ahead, Ken.

    Cheney: Oh I was just going to say, one of the common things, you know, as many organizations haven’t really fully automated – and so they reintroduce the vulnerabilities into the wild all of the time. And what I love about what you can do with InSpec is you can actually – because you’re managing as code, every time you test your software, every time you push a configuration with Chef, you can verify that you’re not reintroducing to file that or something on a keyboard the reintroduces that potential hole in your organization.

    Shimel: Yep, you know – I’m sorry, can you hear?

    Cheney: Yeah, yeah, go ahead.

    Shimel: I’m getting a little audio back. I hope this is recording well. Ken, we did a survey a while back where only 75 percent of organizations are actually scanning their code for vulnerabilities prior to deployment. And you know, what are the other 25 percent thinking?, is kind of what I think. But anyway, on the topic of security, Ken, I wanted to quick mention that Matt Ray of Chef is actually speaking at a conference I’m doing as a part of RSAAPG on DevSecOps next week. And Matt, I think, is based in Australia, correct?

    Cheney: Yes, he is. Yeah, Matt is based in Australia and he will be talking about InSpec, and folks who are there can attend his session and learn more, for sure. 

    Shimel: So maybe it’s because I’m traveling to Singapore and so it’s kind of right in my face, but to me, it’s this global – I mean, DevOps has really become a global – I don’t want to use the word “phenomenon” – but a global force. And we’re seeing it

    Cheney: Yes, it is.

    Shimel: – you know, certainly in EMEA, but we’re seeing it in AP. And then just this week, Ken, I think Chef just announced their first Latin American partner, right?

    Cheney: Correct, correct. Yeah, we are definitely seeing DevOps at a global level and seeing broad interest. And what’s interesting is that – Alan, I’ve been in the industry a while, and it used to be a little bit of a lag – you know, a several-year lag before you’d see markets such as Latin America or parts of Asia pick up technology that would originate in the United States. Or process ideas. But things move much more quickly now and you’re seeing global companies with operations in India and operations in China. And so we as a company do a lot of activity at a global level. You know, if you look at how we’re doing meet-ups and where we’re doing meet-ups, they’re happening all over the place. And our partner ecosystem, which is well over 300 partners, covers the globe, because we see that demand.

    Now how we enter any given market varies depending on what’s going to work best in that market. So some markets we address through partners and some markets we actually put our own physical presence in that market.

    Shimel: Yeah, we see the same thing at devopsy.kinsta.cloud, Ken. You know, our readership when we first started was almost three-quarters U.S.-based, and now it’s only about 37 percent, with the rest being global. But it’s more than just spreading through the world. It’s what you said – there’s not as great a lag time. At one point, Latin America was three – we used to tell people, “Oh, it’s three years behind what we’re doing here.” And that’s not the case anymore, certainly.

    Cheney: Yeah, I’ll tell you, the highest volume of leads that we get come from the Asia Pacific region.

    Shimel: Really.

    Cheney: Yeah, so there’s just a tremendous amount of demand coming out of there. I’ll tell you, if we do a meet-up in Bangalore or Delhi, we’ll have 300 people show up to that meet-up.

    Shimel: Wow, that’s fantastic. You know, we’ll talk more about that off-mic. But Ken, a lot of what’s driving strong numbers like 300 people at a meet-up and stuff like that is training and availability of training, right?

    Cheney: That’s right.

    Shimel: And that’s something Chef has always done really well. But you guys recently rolled out – not Pilot, excuse me – what is the name of the –

    Cheney: Chef Automate. The Chef Automate Pilot, yeah. We actually rolled out a whole new online learning site called Learn Chef Rally and it’s gotten very fast adoption and has a lot of users hitting it every day. And as part of that we have what’s called the Chef Automate Pilot, which is really targeted at an individual who wants to really understand Chef over the course of maybe a lunch, right? So that kind of lunchtime evaluation where they want to get a feel for how Chef works and what it does for them. But as a whole, Learn Chef Rally constitutes a whole set of modules that will walk you through the various parts of our technology. So if you want to learn about compliance, there’s an InSpec module and a Chef Compliance module. If you want to learn even about DevOps concepts, you can go and learn about them there on the Learn Chef Rally site.

    And we’ve had such strong uptake. You know, we’ve seen a lot of customers who would like to bring that learning site in-house and customize that learning environment for their own company. There’s been such a strong interest. So it’s a great resource and I encourage people to go look at it.

    Shimel: Sure. Ken, well, the logical question then is, how do they get there?

    Cheney: Yeah, so it’s very easy to get there. You can just go to learn.chef.io and you can get started.

    Shimel: Excellent. That’s a good one. So that’s Chef Rally and it’s highly recommended. It sounds like there’s a lot and I’m sure you guys are planning to add more into that. So Ken, we are kind of in the dog days of summer here but it’s certainly not slow, it doesn’t seem, anywhere. Any other news, events?

    Cheney: Yeah, well we just passed the one-year anniversary of Habitat and I’ll note that, you know, we at ChefConf made some Habitat news. So we announced a Habitat build service and we made improvements to the Habitat scaffolding, which are essentially build packs to make it easier for people to package up their applications, as well as we’re writing a set of enterprise-ready Habitat plans or common languages, common platforms, such as like BigData, Cassandra, Spark and real common kind of web apps. And so Habitat continues to evolve, and just in the past couple of weeks we announced the pre-release of Habitat for Windows. So along with what we had for Linux support, people can now use Habitat to package up their Windows-based applications. And from our view, Habitat is now the premiere packaging solution for containers. It’s the fastest, easiest way to package an application and have it run in a container and be able to manage it across the life cycle.

    Shimel: That rocks. I mean, because certainly, Ken, the one thing that we’re seeing here is the – you know, we talk about the Internet time crunching or compressing time. The pickup on containers? I’m old enough, and probably you are too – remember when VMware first came out, right?

    Cheney: That’s right.

    Shimel: And through virtualization, it went really quick. The move to virtualization went a lot quicker than let’s say the move off of client server or something like that, from peer-to-peer, or peer-to-peer to client server or what have you. But the move to containers – man, I’ve seen several surveys recently that showed container in production numbers upwards of 50 percent of organizations. And I thought frankly this wasn’t true, but it says something. Right?

    Cheney: Yeah well, you know what’s interesting though about that move? What’s interesting about that move, Alan, is that the majority of containers that are running out there are being used almost like a VM. You know, 75 percent of containers right now are running a full OS.

    Shimel: Yep.

    Cheney: And they’re basically just using it as a way to kind of attempt a higher level of abstraction and remove a little bit more of the infrastructure complexity that they were encountering when they were using VMs. So what I think the next wave is going to happen, I think people are going to actually figure out how to actually better package their applications to actually take advantage of what they can do to remove unwanted dependencies and remove a lot of the weight around the application that they’re currently doing today when they just package up the full OS and all of the broad set of unassociated dependencies that they’re packaging right now. So I expect that’s going to be the next wave and we’re there to help them when they go there.

    Shimel: Agreed, agreed. Ken, any shows or conferences coming up, other than of course the DevSecOps that I mentioned, where Chef will be presenting or a part of?

    Cheney: Yeah, well yeah, we will be at VM World, coming up. We’ll be at Microsoft’s big event that’s coming up. And of course as we look toward November we have our own community summits that happen in the fall timeframe. So those are a great way that we bring our community together. So the first one is going to be in London Oct. 10 and 11. So that’s coming right up as well. So expect to see Chef and our brand showing up at a lot of different places in the coming months.

    Shimel: Great. Very cool. Well Ken, we’re about out of time here. 15 minutes goes quick. But hopefully it won’t be a few months before you’re back on –

    Cheney: Yeah.

    Shimel: – and we can pick up where we left off here.

    Cheney: Yeah, Alan, enjoy your travels and thanks so much for the time today.

    Shimel: Not a problem. Ken Cheney, CMO of Chef, here on DevOps Chats. This is Alan Shimel for DevOps Chat and devopsy.kinsta.cloud. Thanks for listening, everyone, and we’ll see you on another DevOps Chat soon.

    — Alan Shimel