Author: Alan Shimel

  • DevOps Chat: The State of Alerting & On-Call Survival for IT Ops, with OnPage CEO Judit Sharon

    DevOps Chat: The State of Alerting & On-Call Survival for IT Ops, with OnPage CEO Judit Sharon

    In this DevOps Chat we sit down with Judit Sharon, CEO of OnPage. OnPage has been providing alerting and incident management services primarily to the healthcare industry since before DevOps was called DevOps. As DevOps has exploded on the scene, the security and functionality built into OnPage was a perfect fit for IT Ops and DevOps teams. As a result, OnPage has expanded beyond its healthcare industry roots to become a very popular solution in the DevOps space.

    OnPage recently conducted a survey on the state of alerting in the IT Ops space. Judit gives us some insight into the findings, but you can download the full survey report at www.onpage.com/the-state-of-it-operations-ebook/.

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

    Alan Shimel: Hey, everyone, it’s Alan Shimel, and you’re listening to another episode of DevOps Chat. Today’s DevOps Chat is a really nice one that I think you’re going to enjoy. I have as my guest Judit Sharon, CEO and co-founder of OnPage. Judit, welcome to DevOps Chat.

    Judit Sharon: Thank you, Alan. Happy to join you.

    Shimel: Happy to have you here. So, Judit, let’s start off a little bit, as I mentioned, you were the founder and CEO of OnPage, but maybe some folks in our audience are not familiar with OnPage. Why don’t you give us a little bit of background on the company and how you came to start it?

    Sharon: Sure. So, OnPage is a SaaS based incident management platform hosted in a secure facility across the U.S., and in a nutshell, we—OnPage gives you visibility and feedback on incident status. You can track alerts, delivery, ticket status, and response, and it’s rock solid reliable. As one of our customers once said, it’s a must solution for those who need to elevate critical incidents.

    Shimel: Mm-hmm.

    Sharon: So, if I just go a little bit deeper, OnPage was built around the incident resolution life cycle to enable an organization to get the most out of their digital investment, ensuring that sensor and monitoring system have a reliable means to escalate urgent notification to the right person and immediately.

    So, you know, Alan, just a few years ago, when we wanted to come up with a product, all we needed to do is plan the product, develop, test it, and deploy it. That’s it. That was the end of it. Today, in the DevOps era, we also collect data. We use a special tool to collect data, to remove the noise. We calculate the data, we learn normal behavior, we predict anomaly, and we even attempt to correct it if possible writing a little script.

    So, we invest a lot in collecting this information, and as long as the process is working well, machine to machine communication is ideal. However, in the case of failure, disaster, or outage, when a technical person is needed, e-mail and SMS or even a phone call is not a sufficient means of notification, and OnPage is the best, most reliable solution to be used. And why? Because the technical person on call will get all the information right to their device, can start working on the incident immediately. If they’re not available, there are escalation rules that are pre-defined, and they can escalate it to the next person.

    Furthermore, in the event that the person did receive it and now they need help from a different person, from a different team—so, they don’t need to know who is on call in that team, all they need to do, they can forward the entire ticket, add some notes to it, and send it to the different organization. OnPage will send it to the right person on call and will escalate it within the next team.

    So, in one sentence, to summarize, OnPage automates the entire notification process to avoid human errors.

    Shimel: Yep. And Judit, I want to call out another not feature but characteristic in the history of OnPage. You know, we see so many companies that saw DevOps as a gold rush. You know, founders who say, “Wow, I want to start a company around DevOps,” and they build a tool for DevOps.

    Not the fact with OnPage. OnPage has actually been around for some time, and its mission dovetails nicely with DevOps but it’s not one of these Johnny-come-latelies trying to capitalize on how many people are searching Google for DevOps or something like that. Correct?

    Sharon: Right. So, we started about seven years ago. We started as incident notification, and actually, we started in health care. That’s why our solution is HIPAA-secure, something that is very unique about us.

    The other thing that we did, because we started in health care, was, we needed to alert until read. So, we are very unique in that, that we don’t just send you an alert, like send an SMS or an e-mail or send you just a push notification. We will alert consistently for eight hours to ensure that the message was delivered to the right person. And we have the audit trail, so now, accountability is a must. Now, we have the audit trail of who got it, when, how long it took to open the message.

    And another very nice feature other than the fact that we are HIPAA-compliant, so you know, we are secure, all the communication is secure at rest, and it’s encrypted in our database. We also save all the information for up to six years. So, other than the fact that we are HIPAA-compliant and other than the fact that we have the alert until read—we have other very nice features. Right now, there are a lot of companies, large companies mainly, that have a lot of systems and processes and sensors that sense just e-mail notification. And you will see from our study that we will talk about later, a lot of people are using e-mail notification for incident notification. And we just integrated those e-mails, and basically, you can leverage all the OnPage capabilities and elevate those messages if they’re important.

    Yeah, that’s what we do.

    Shimel: Sure, absolutely. And Judit, I wanted to kind of shift the conversation, if we will—if you will—to a larger topic, and that is sort of the state left alerting in the IT Ops world and the state of IT Ops. I know recently OnPage conducted a survey of IT Ops professionals. There’s been a few articles on devopsy.kinsta.cloud about it by Aura Lee,  love of your company as well as download the full report.

    But for those of our listeners who maybe haven’t had a chance to go on the site and check out the report—and we’ll put links to it in our show notes—can you talk a little bit about that, give us a little insight, here?

    Sharon: Yes. So, the state of IT operations, we conducted a study where we surveyed about 96 different companies, and the nice thing about that survey, we got a few people from each organization. So, we see the response from different levels of leadership. So, 20 percent were SVP or C level, 22 percent were directors, 34 percent were managers, and 24 percent were individual contributors. So, you see a nice distribution among the different levels in the organization.

    And the findings were—I mean, first, what did we want to look at? We looked at how teams are notified in critical incidents, how many alerts the team received, who received the critical alerts, and how did they get handled?

    So, the findings were really interesting. As I told you before, we found that 80 percent of the respondents said that they get notified via e-mail. You know, e-mail—the same e-mail that you get as junk mail, the same e-mail that you get on a regular basis—80 percent of IT get their notifications via e-mail. Which means they need to be on top of e-mail all the time. They’re always on, they’re never off. And I don’t know if you remember Target, they had some cybersecurity?

    Shimel: Mm-hmm.

    Sharon: Apparently they did get alerts, right? They did get notified, but they got notified via e-mail. So, three days later, they found the e-mail that they got notified. So, what OnPage says is, “Yes, you have processes that are sending e-mails. You can always change those processes and maybe extensively change the processes.” But why don’t you elevate those e-mails so they find you in case of emergency rather than you sit there and always, always check your e-mail?

    Another interesting point that we found is that 40 percent of IT teams get more than 10 alerts per day; 20 percent get more than 20 alerts per day. So, couple that with the fact that two-thirds of the respondents saying that they sent alerts to the team—so now, you don’t send alerts to one person, every alert gets sent to the entire team because they don’t want to miss the alert, right? So, what OnPage does, they say, “Okay, you get a lot of alerts. Don’t send it to the entire team. Send it to an escalation team, so one person will get it, and then always change who is the first one in line so the burden gets distributed.” So, you don’t get as many alerts, and you don’t—like, basically, the workforce, right, and the quality of their life, you don’t diminish it completely.

    So, that was just a few very, very interesting facts that we found about that demographic that we surveyed.

    Shimel: Yep. You know, Judit, I’d like to make a comment, but more of a question to you and get your advice, because this is an issue we deal with here at devopsy.kinsta.cloud, even. We have tried so hard to move off of e-mail as our primary communication, alerting, operational format. And we have tried. We’ve tried things like Slack and Chat and Google Chat and texting and I can’t tell you how many different tools we’ve given a try to. And yet, we keep coming back to e-mail.

    So, it doesn’t surprise me that many Ops people still rely on e-mail, with all the spam and all the noise to signal ratio problems there. What do you—for people listening out here in the same boat I am in—what’s your suggestion? What’s your advice?

    Sharon: Well, I think that e-mail is really good for audit trails, right? You want to know what happened, who said what. All the communication gets distributed to a distribution group—that’s fine.

    What we say is, when it’s critical, right—e-mails are okay for day-to-day communication. E-mail is okay, it’s actually for events or incidents that don’t need to be taken care of right away. So, those events that don’t need to be prioritized, they should go to e-mail. That’s absolutely true.

    What we say is, when there is an event that needs your attention immediately—and that’s another thing that I would like to go into are the costs, right? Those incidents that need to grab your attention immediately, those should be elevated. Those should find you rather than you always check your e-mail and always be on.

    Another interesting thing that we’ve found is, 12 percent said they are still using a pager.

    Shimel: Yeah?

    Sharon: And then we looked into those 12 percent, what vertical they come from, and we found that they come from the healthcare industry. Come to show you that the IT follows the technology implemented in the organization; they don’t kind of bring new technology for themselves. So, if the health care organization is using a pager, the IT organization of the same organization will use pager. Only with those who responded. We have a lot of customers, health care IT, that are using OnPage to elevate those messages.

    Another thing I want to get into is the cost, right? How much it costs. So, 99 percent of the organizations say that a single hour of down time costs them $100,000.00. So, every minute that we delay working on it and remedying the issue costs you about $1,670.00—every minute, right? You know, the counter is working, and we found that 62 percent of responders, it takes them 5 to 15 minutes to deliver an alert. Twelve percent said it’s more than 15 minutes to deliver an alert.

    So, here we see that just the delivery costs of the down time is between 8,000 and 25,000 per incident. Now, compare that to the cost of the solution. The cost of the solution is almost like a no-brainer. When we started the company and we pitched the idea, it was a quote—it’s a no-brainer. The cost is so miniscule in comparison to the cost of the lost time in delivering the alert to the right person and having the audit trail and having the reporting so you can afterwards go and even audit your team, make sure that everyone is accountable, that everyone is reliable.

    So, that was an interesting finding from this survey. Actually, we think it’s so interesting that we would like to run the survey in a different venue as well to try to get maybe a bigger audience, because this one was about 200 to 150 responders, but maybe if we can go on a larger scale and see if it’s working the same across all industries.

    Shimel: Sure. That would be fascinating. And I think—you know, it’s funny, I happen to be working on an e-book we’re writing on the state of DevOps in 2017, and I will tell you, there’s frankly not enough research being done and that’s available on these kinds of subjects, right? I mean, people are going more on kinda what their gut tells them on subjective rather than objective data.

    Sharon: Yeah.

    Shimel: And that’s always—you know, sometimes it works, but it’s always risky. So, I would encourage you to do that if you guys can, for sure.

    Sharon: Right. The other thing that we found that, you know, security became really, really important, like, this is top of mind for everyone. It used to be only health care, right, that cared about security and compliance, and now we go through one survey after another about our security policies from IT organizations, right? So, security becomes very, very important, and 40 percent of the responders said that encryption, even of alerts and messaging is very important for them. So, that’s another nice piece of information that we got from this survey.

    Shimel: Absolutely. Well, Judit, as I mentioned to you off mic when we were talking before recording today, the time goes really quick here. We’re already—we’re well past 15 minutes, so we’ll try to be respectful of our audience’s time, and maybe we can have you on for another chat to continue the discussion, maybe if you continue another leg of the survey.

    But thanks for being our guest on this DevOps Chat. I just wanted to end it, because I forgot to ask you in the beginning. For people who want to get more information about OnPage, where can they go?

    Sharon: So, of course, there is our website, www.OnPage.com. If you want a copy of this survey, it’s located at devopsy.kinsta.cloud, and there is another location on our website, OnPage.com/DevOps-ebook. A little bit more complicated than devopsy.kinsta.cloud, but we are going to publish another part of this survey, because we put the white papers in two sections, so part two is going to come up soon.

    Shimel: Great.

    Sharon: And I would love you guys all coming to look into what we do.

    Shimel: Okay! Judit Sharon, founder and CEO of OnPage, thank you for being our guest.

    Sharon: Thank you, Alan. Pleasure to be here.

    Shimel: Pleasure to have you here. Judit, we’ll see you soon.

    Sharon: Sure.

    Shimel: This is Alan Shimel for devopsy.kinsta.cloud. Thanks for joining us. Hope to see you soon on another DevOps Chat, and have a great day, everyone.

    — Alan Shimel

  • DevOps Chat: Continuous Testing with Sandeep Johri, CEO, Tricentis

    DevOps Chat: Continuous Testing with Sandeep Johri, CEO, Tricentis

    In this DevOps Chat we take a dive into the continuous testing market, which is one of the most dynamic in the DevOps space. Our guest is Sandeep Johri, CEO of Tricentis, a leader in the space.

    Sandeep gives us his own personal background, as well as the history of Tricentis. The company is not an overnight sensation in the continuous testing space. In fact, it has been perfecting its offerings for many years. Tricentis literally helped usher in the continuous testing age, making continuous testing part of the CI/CD pipeline.

    This chat is a great way to learn about what some of the important points for continuous testing are. Have a listen. As usual, the streaming audio is immediately below, followed by the transcript of our conversation to follow along. Enjoy.

    Audio

    Transcript

    [su_pullquote align=”right”][su_custom_gallery source=”media: 120253″ link=”post” target=”blank” width=”230″ height=”230″ title=”never”]Sandeep Johri
    As the CEO of Tricentis, Sandeep brings over 25 years of enterprise software experience. He manages all business-related functions including business strategy, products, services, sales, marketing, and operations to achieve business profit and sales objectives. Sandeep most recently served as the COO of Appcelerator, the leading open source mobile application development platform. He was Vice President of Strategy and Industry Solutions at HP, where he also served as Vice President of Corporate Development. There, he was instrumental in developing and implementing the growth strategy that resulted in the software business growing 2X market over the last four years. Sandeep was instrumental in the formation of two startups, Determina (VMware) and Bluelane (VMware). He was also the CEO and founder of Oblix (Oracle), and co-founded eBoodle (EW Scripps), one of the first ecommerce comparison shopping services. Sandeep has an MBA from Stanford University, a Master’s degree in Industrial Engineering from Wayne State University, Detroit, and a Bachelor’s degree in Mechanical Engineering from Pune University, India. Sandeep is involved as an advisor and investor in various startups in Silicon Valley and India.[/su_pullquote]
    Alan Shimel: Hey, everyone, it’s Alan Shimel, devopsy.kinsta.cloud, and you’re listening to another DevOps Chat. Got a really great chat lined up for you all today. I’d like to introduce you to Sandeep Johri. He is CEO of Tricentis. Sandeep, welcome.

    Sandeep Johri: Thank you, Alan.

    Shimel: First of all, Sandeep, I just wanted to make sure I’ve got your – we pronounced your name correctly.

    Johri: Yes, you did, actually. You got it absolutely right.

    Shimel: Good. All right. It’s always a good start. So, Sandeep, let’s start foundational here. Tricentis is a company that, really, had a very, very strong presence over in EMEA, I think, and has most recently really begun to exert themselves in the North American market. But some of our listeners may not be familiar with Tricentis at all. So why don’t we start with that, if you can give us a sort of a – not an elevator pitch, but a little background on Tricentis?

    Johri: Sure. So Tricentis was founded about eight, nine years ago. It was founded by Wolfgang Platz, who was actually a tester and working on complex enterprise applications for testing and was frustrated with all the tools out there. So, like any good entrepreneur, he decided to write his own tool. And the tool initially was focused primarily on automation. And it sold – they were – Wolfgang was based out of Vienna, Austria, and they sold it locally into the German-speaking market, so Austria, Germany, and Switzerland.

    Shimel: Mm-hmm.

    Johri: And they had a nice, little business going and they had a great product. I ran into them about 4 years ago, in 2013. I found them and felt that this could be a really interesting offering because what the market needed was automation, especially as people were going to Agile. Given my background with Mercury at HP, I knew that there was not much automation, but, if you go Agile, you have to have automation. It becomes a critical component – automation on the testing side becomes critical – and that’s why I joined the company. You’re right; they were initially focused primarily on Europe. And, remember, this is pre-coining of the term “DevOps,” but the need for automation was always there, especially as you kind of shift towards Agile on the dev side.

    So now, you know, cycle ahead four years and we are now a global company. We did as much business in US as in Europe, so we are now really very well balanced. And we also have now created a presence, over the last few years, in Asia-Pac, so Australia, New Zealand, and Singapore, so we’re truly kinda global, with a typical balance of about equal between US and EMEA, and then another additional APAC component to it. And, obviously, once DevOps became the kinda mantra in the industry, we had a really nice fit and people started talking about continuous testing. Well, with automation, what you really get is continuous testing, so that’s why we are all about continuous testing. But the core engine is an automation – is a test-automation engine, so for the enterprise.

    Shimel: Absolutely. So I wanna get into the whole automation and testing market, but you mentioned a few things that I, if you don’t mind, I’d like to dive into. I don’t mean to embarrass you, Sandeep, but, when you get to my age – and you’re a contemporary – you know, we like to reminisce. So you mentioned Mercury and your experience there. I mean, for those who aren’t looking at your CV or the management team details up on the Tricentis site, why don’t you give a little background on yourself to our audience so they get a flavor for this?

    Johri: Sure. Sure, Alan. I’ll try to keep it short. I’ve been in Silicon Valley for almost 30 years and I’ve been entrepreneur. I started a few companies. One was Oblix, which was a leader in the identity space. And then a couple of other companies, Blue Lane and Determina, which were then acquired by VMware. I joined HP after that because they were looking to build out their IT-management portfolio, and, over 3 or 4 years, from 2005 to 2008, we acquired about 13, 14 companies, including Mercury Interactive, which was the largest, but we also acquired Opsware for data-center automation; we acquired Peregrine for asset and service management. And that whole portfolio became HP ALM, so it was – that business went from about $600 million to about $3.5 billion.

    Shimel: Wow.

    Johri: And then everyone knows HP was having some challenges and were increasingly focused less on the software business, which they eventually sold last year. But I felt the need – I felt the opportunity was there for a next-generation tool or next-generation testing platform that better suits the Agile automation environment, which we now call more “DevOps” because it takes the whole cycles and kinda creates a continuous-delivery chain, if you may.

    Shimel: Absolutely. So, Sandeep, that’s sort of the quintessential Silicon Valley entrepreneur story, where you’ve done everything from start-ups that had some very successful exits. As I mentioned offline, I remember Oblix and I remember Blue Lane almost like it was yesterday. And then, of course, you had this big company, HP kind of experience on the resume, and I would imagine, knowing what I know about the Insight Venture team, who I believe is an investor in Tricentis, I would imagine you would have been a very, very attractive candidate, when they were looking for a – the team was looking for a CEO to take Tricentis to the next level, so right person at the right time there. Fantastic story.

    Johri: Yeah, I joined before Insight came in. Yeah, I joined four years ago – Insight came in last year – because I thought that they were really promising, and we spent the first couple of years kind of building out the product to be more – you know, filling out the product. We added service virtualization. We added test data in it. You know, we’ve added a whole bunch of capabilities and we were beginning to get recognized by Gartner and the like as a leader and we also started having some really large enterprise customers in the US. That’s when Insight also had a similar thesis, that, “Hey, HP seems to be walking away from this market, but there’s a need – there’s an opportunity there,” and they found us. And that’s why they invested $165 million late last year, so.

    Shimel: Wow. That’s quite an investment. And so sort of I had the horse before the cart, but congratulations. Right? This is not an easy thing with that kind of investment, but also comes when there’s that kind of opportunity. Let’s turn now, if we can, Sandeep, and talk a little bit about the testing market. You know, testing – before DevOps and Agile, the whole QA testing thing was really, really super geeky and I don’t know how interesting to people. Back in my day, at StillSecure, the hardest thing for us in testing was just building up a test lab that could handle the scale we wanted to test at. Right?

    Johri: Right. Right. Right.

    Shimel: And testing software and so forth was relatively a bunch of open-source tools that the development team did as part of the release cycle in the old Waterfall. But, you know, with Agile and automation and, look, there’s Agile with automation and then there’s automation in and of itself, throughout the software life cycle.

    Johri: Uh-huh.

    Shimel: It’s become imperative, right? And, all of a sudden, now –

    Johri: Right.

    Shimel: – yeah – testing has taken on a super role, right? I mean, it’s really become kind of the – you know, when we look at the continuous integration, continuous delivery pipeline, right, that testing, man, it sticks out. And it’s like swamping everything else, if you will, right? It’s swallowing it.

    Johri: Right.

    Shimel: And so tremendous opportunity. We’ve seen a number of companies try to enter this fray, many of them based on open source, whether they’re doing Selenium or something like that, but there’s different aspects of testing. Can you share with our audience, Sandeep, what type of testing is it that Tricentis is doing?

    Johri: Right. And so, Alan, I think you cover a lot of the history and perhaps I can comment on that because that’s really interesting. So, you know, testing, for an enterprise, has always been critical, but you’re right. It was kind of a “Oh, God, I have to do testing and it’s a lot of manual process,” so people mostly outsourced testing. And, when you were in Waterfall mode, that was okay because you did a bunch of development and then you threw it over the wall. In most cases, at an enterprise, it went offshore and people did it manually. But it has always been a huge spend. Even today, there’s a $30-billion spend on testing services.

    Now the challenge is that the tools that were out there, both open-source and commercial tools, were primarily script-based tools, so it was really difficult to automate. And, because you had outsourced, you kinda got the labor arbitrage and people continued to do it manually. And, even today, 80 percent of testing, enterprise testing, is done manually, which is kinda crazy, right? ‘Cause here we’re getting ready with autonomous cars on the one hand, but, on the other hand, we’re doing software testing which is – software’s so fundamental to every enterprise – we’re doing all the testing manually. Well, now – and that was okay in the Waterfall environment.

    As you go to Agile on the dev side, you start doing frequent builds. And, as you start doing frequent builds, if your testing cycle is still six to 12 weeks, you’ll fall right back into a Waterfall mode, even though your dev might be Agile. So testing is becoming – the need for automated testing is becoming critical because, otherwise, it becomes the bottleneck in your delivery chain. And what we do or our view of testing is that testing should be at the same cadence as development, so, if you’re doing daily builds, you should be testing on a daily basis.

    Now you mentioned developers. Developers do unit testing – they do subsystem-level testing as they build – but, for a large enterprise, which has a complex environment that has a mix of technologies, just doing subsystem-level testing doesn’t work. It is necessary but not sufficient. And, therefore, what you need to be able to do to really deliver faster or to really be getting – to get into a continuous-delivery mode, you need to be able to build continuously but also test end-to-end on a continuous basis. And that is fundamentally what we enable through automation. We can get to 90-percent automation; we leave manual testing only for usability and exploratory. And then, you know, you truly have your DevOps tool chain in a continuous mode, where you’re doing continuous builds and then –

    Shimel: Mm-hmm.

    Johri: You’re doing continuous builds on the one hand, you’re doing continuous testing on the same cadence, and then you can push it out into ops, so you’re right. It becomes absolutely critical, and the manual testing is rapidly decreasing, and people are shifting more to automation now.

    Shimel: Absolutely. And not only shifting. You know, it’s a global, massive shift to automation and especially with the testing. And, frankly, look, that’s why you get the kind of valuations we’re seeing. That’s why you’re seeing the kind of acquisitions by large companies that we’re seeing. You know, I don’t see how you can do testing, going forward, without automation, so this is a fundamental change in the way this is being done. You know, you look at some of the companies from the old way of doing it, who are maybe selling testing equipment and so forth. Right? And they’re kind of dead men walking, to a certain extent. Right? And I –

    Johri: Yeah.

    Shimel: Geez, I don’t know what to tell you with it.

    Johri: But, you know, Alan, one more point on that. I think when you think about a large enterprise – a bank, an insurance company, or the like – their business processes span technologies, meaning they have modern front ends, but they also have a lot of legacy systems. And most of the early DevOps work has been done only on the front-end systems, where you can go dev and, as long as you’ve done some unit testing, you can move to production. When you’re thinking about enterprises with large end-to-end systems that span every technology that’s been invented, you have to get into a continuous-testing mode; otherwise, you cannot do DevOps for a large enterprise. So the enterprise DevOps is a slightly different animal than, let’s say, a smaller startup in Silicon Valley doing DevOps, where they have a relatively modern tech stack and a relatively monolithic application, if you may.

    Shimel: And, frankly, I always like to say, Sandeep, those companies – first of all, it’s DevOps, right? I don’t care whether you’re big or little – you’re all like do DevOps – but they do DevOps because they just don’t have the resources to do it any other way, frankly, right? Everyone wearing multiple hats and the way they – they have to – it is just no other way. It’s in their DNA, if you will. Where, with large enterprises, it’s DevOps or die, to a certain extent, in today’s competitive marketplace. And when I say “DevOps,” I’m talking about continuous – continuous testing, continuous delivery, continuous integration. You know, that automation is wherever – I mean, you know, all of the things we’ve come now to recognize as DevOps. So –

    Johri: Mm-hmm.

    Shimel: Sandeep, I guess we see these mega-trends. We see the way the market’s heading. We’ve heard about your background and the company’s history. I mean, it’s an eight-year-old or nine-year-old startup, right?

    Johri: Mm-hmm. That’s right.

    Shimel: What does the future hold? Specifically for Tricentis.

    Johri: Well, you know, we see ourselves as – and also we have about 600 large enterprises across those regions that I talked about – US, most of EMEA, and then Australia, New Zealand, and Singapore – and we focus primarily on large enterprises, the Global 2000 or the Global 5000. Competitively, we’ll end up replacing the old HP, which is now called “Micro Focus.” Most enterprises are looking for a modern tool set, just like they use AppDynamics or New Relic to replace the old app-monitoring solutions and they’re replacing old defect-management systems with newer things like Jira and the like. So we see a lot of replacement, but the really exciting part is that the $30-billion spend that I was talking about, on testing services, that is, like I said, mostly manual, and, as you start automating that, what we are really doing is disrupting that $30-billion manual-testing market. So the global opportunity for us is incredible. There’s a multibillion-dollar opportunity, in terms of what a platform like us can be selling out there.

    Shimel: Mm-hmm.

    Johri: Mercury was a billion-dollar company – almost a billion-dollar company 10 years ago, 2007, and so we see that not only as a replacement as a replacement opportunity, but also, because we’re disrupting the services play, as you disrupt manual labor, you know, a big chunk of it goes towards the automation tools, and that’s what we see. So, in terms of the future, we see a very, very bright future. And we wanna be the marketshare leader in testing tools, so we have a very comprehensive solution already for end-to-end testing, both performance and load testing, and we will continue to enhance it so that we’re the innovative leader, as we are right now. We will maintain that and continue the leadership, so.

    Shimel: Sandeep, I have little doubt of that, as long as you’re at the helm, driving this. It sounds like, based on your track record – and I have to agree with almost everything you said about the market. That’s kind of where we are right now and it should be an interesting next couple of years. The opportunity is certainly there, right? Someone’s gonna dominate this.

    Johri: Wonderful. Yes.

    Shimel: Yep.

    Johri: Mm-hmm. Mm-hmm.

    Shimel: Sandeep, as I told you when we started, the 15 minutes goes really quickly, so we’re at 20 minutes already. So we’re gonna need to kinda wrap up on this, but, before we do, for people who may be – we’re doing a bunch of activities with Tricentis, where I believe we’ll have some webinars and some content up on devopsy.kinsta.cloud, but, beyond that, where can people maybe either see you guys at conferences or speaking? Or, obviously, they can go to tricentis.com – T-R-I-C-E-N-T-I-S.com – for information, but just if you happen to know off top of your head where people might get more info even or a little hands-on –

    Johri: Yeah, well, we have – yeah, absolutely. Well, we, like you said, Alan, we do participate in most of the major conferences, either on DevOps or testing. You know, there’s testing-focused conferences we participate in. We also participate in larger vendor conferences, like the Appalachian Summit and SAP’s SAPPHIRE. But what is most exciting for me is that, this year, we’re organizing our first US user conference, which will really be a conference focused on continuous testing. And we have scheduled that for April, yeah, here in – actually, no, no, wait a minute. It is scheduled for –

    Shimel: I don’t know.

    Johri: Oh, God.

    Shimel: You know what?

    Johri: Yeah, I should –

    Shimel: I’m looking it up myself for you. Hold on here. Tricentis Accelerate? Would that be it?

    Johri: Yeah, it’s – yeah, it’s on the 8th or 9th.

    Shimel: San Francisco, May 7th to May 8th.

    Johri: Yes. Yes. Yes. May 7th and 8th. Sorry about that.

    Shimel: It’s okay.

    Johri: But that conference is gonna be completely focused on continuous testing. We’re gonna have – obviously, show all our product capabilities and the like, but what’s more interesting and exciting is that we’ll have a whole bunch of large enterprise customers that are gonna talk about how they’re tackling continuous testing, as they are on their journey of DevOps, so it should be really exciting. I would really welcome everybody to come attend that conference in San Francisco on May 7th and 8th.

    Shimel: Yep. And also you’re doing, it looks like, one in Vienna, Austria, October 9th and 10th. And ’cause – you know what? – our audience, like DevOps itself, about 36, 37 percent are US-based and the rest of the world makes up the majority. For anyone interested, though, you can go to accelerate.tricentis.com – that’s accelerate, A-C-C-E-L-E-R-A-T-E, at tricentis – or accelerate.tricentis.com, to get information on both of those. And we’ll probably be covering them from devopsy.kinsta.cloud as well. Well, this has been a great introduction to Tricentis and a great discussion of the testing, Agile, DevOps market. Sandeep, thank you so much for joining us.

    Johri: It was wonderful, Alan. Thanks a lot for the time. And I have a special offer for you. For your listeners, we will make some tickets available to the conference and you can distribute it to your favorite listeners, so we will follow up and get you a whole bunch of tickets to the conference that you can distribute to your readership. Your readership is exactly who we target and who we – that’s in our domain. That’s exactly our domain, so we’d love to have as many of your readers – or listeners and readers –

    Shimel: As both, right.

    Johri: attend the conference as possible. Yeah. Wonderful.

    Shimel: Really kind for you. I will put it in the show notes as well as on the article on devopsy.kinsta.cloud, for people who are interested. We’ll raffle ’em off, depending how many we have here. Sandeep Johri, CEO, Tricentis, powerhouse in automated testing. Thanks for being this episode’s guest on DevOps Chat and continued success.

    Johri: Thank you.

    Shimel: Thank you. This is Alan Shimel for devopsy.kinsta.cloud, DevOps Chat. Thanks for listening, everyone, and we’ll see you soon on another DevOps Chat.

    — Alan Shimel

  • DevOps Chat: Concurrent DevOps with GitLab CEO Sid Sijbrandij

    DevOps Chat: Concurrent DevOps with GitLab CEO Sid Sijbrandij

    In this DevOps Chat we speak with GitLab CEO Sid Sijbrandij. Sid has guided GitLab as a co-founder to the heights of the DevOps market. Joining Sid and me is Ashish Kuthiala, who recently joined GitLab. I have always been impressed with the completeness of GitLabs’ vision of the DevOps toolchain and what the company wants to offer. Sid’s vision for this is something he calls Concurrent DevOps. You will hear more about Concurrent DevOps in our chat, as well as in the months to come.

    Another thing about GitLab is is an open source-based company, which allows for a lot of transparency. With hundreds of thousands of organizations using GitLab and thousands of paying customers, GitLab is a great example of a DevOps success story.

    As usual, the audio of our conversation is immediately below, followed by a transcript of our conversation.

    Audio

    Transcript

    [su_pullquote align=”right”] [su_custom_gallery source=”media: 120255″ link=”post” target=”blank” width=”200″ height=”200″ title=”never”]Sid Sijbrandij
    Sid saw the first ruby code in 2007 and loved it so much he learned to program and made this his profession. Before that he was engaged in various businesses, from selling programmable infrared receivers to starting a recreational submarine company. He is always looking to publicly document an answer or to make a process more efficient. He was never good at sports but tries to make it up in quantity by hiking, sailing, skiing, snowboarding, speed skating, dancing Zouk, squashing, and running. In love participating in conversations on Hacker News, and reading Marc Andreessen’s tweets (now that Marc stopped this greatly increased his productivity).[/su_pullquote]
    Alan Shimel: Hey, everyone, it’s Alan Shimel, and it’s time for another DevOps Chat. Our DevOps Chat episode today is gonna be all about GitLab, and we’re joined by two GitLab folks. First joining us is the co-founder and CEO of GitLab, Sid Sijbrandij, and I hope I did that justice. Sid, welcome to DevOps Chat.

    Sid Sijbrandij: Thanks for having me.

    Shimel: Thank you. And joining Sid and I is a friend of mine, recently joined the GitLab team, Ashish Kuthiala. Ashish, I didn’t mess that up too bad, did I?

    Ashish Kuthiala: No, you didn’t. No, that was perfect.

    Shimel: Alright! Well, one of the nice things about tech is, I get a lot of experience. Not a lot of Smiths in the group. [Laughter] And as I said, this is Alan Shimel, and we’re here with DevOps Chat.

    So, guys—GitLab. You know, first of all, Sid, I’m sure you’ve probably heard this before, but I’m sure there are people in our audience who still have to ask themselves, “GitHub, GitLab,” right? And as silly as it sounds, they may confuse them sometimes.

    So, let’s set it straight in terms of GitLab. Sid, you co-founded it. What exactly is GitLab and how does it differ, let’s say, from GitHub, and we’ll go from there.

    Sijbrandij: Yeah, so GitLab started off as an open source alternative to GitHub, where you could have Git repositories, do version control, do some issue management, and it’s now grown a lot as a company and as a project. We now do the whole DevOps life cycle. So, anything from planning to rolling out what you’ve made—CI/CD, packaging, monitoring—all in a single application.

    Shimel: Great. And I think you’re being modest, actually. GitHub is certainly—when you say branched out, it’s branched out, I mean, from what I know, and I’m no expert, obviously, the breadth of the vision is pretty dynamic. So, congratulations with that.

    Sijbrandij: Thank you.

    Shimel: Ashish, you were—thank you. Ashish, you recently joined GitLab, and why don’t you give us out, what’s your position there?

    Kuthiala: So, Alan, I think you and I have known each other for a while, and I am very passionate about the promise of DevOps, especially at large scale enterprises, right? Not smaller teams or not those who had the luxury of building out their infrastructure and teams to adopt DevOps and realize the promises of that.

    We still a lot of the larger enterprises struggle with adopting and realizing the promise of DevOps as it is. I mean, a lot of them are achieving results, but a lot of them are still in the journey and trying to figure out how to get there.

    So, and I had heard about GitLab, I knew that they were building out a solution for this, but I think it was in the last DevOps Enterprise Summit, you, I, and Haydn ran into each other. And I started talking to Haydn and I learned more about the company, and I think it’s just the right product at the right time. Because if you look at all the challenges that exist in the big enterprise, there’s massive transformation needed, and there’s several things that prevent this from moving forward at the speed that everybody would like, whether this is different organizations within the large organizations to get them to collaborate together, whether this is stitching together the different toolset chains to kind of make this seamless.

    And I think GitLab has really built something from ground up that addresses this problem. And the good news is that the velocity at which we are adding functionality, we are adding the needs that need to be addressed. Because we are an open source company, we are completely open and transparent, right? We gather input from everybody, a road map is opened. We take the input, we take contributions, and we build the right thing for solving today’s problems. And as needs change, I see this model as something that can really adopt to that, right?

    Because the world of DevOps is changing very rapidly, and often there’s a fear of getting locked in with a vendor, too. With our solution, I think the openness of it and the direction it can go to solve problems as they change is a great promise, and we’re already solving a lot of problems. So, that was a big thing for me, you know, that I considered in joining GitLab.

    And the other thing is the culture and open transparency that Sid and the company have built in the company. It’s just phenomenal for me, right? I mean, that was just an eye opening model of how everything we do is open to the world. It’s open within the employees. Anybody can contribute, anybody can look at everything we do and how we move forward to help our customers.

    So, these two are the main things for me that really inspired me to join GitLab.

    Shimel: Great. So, Sid, I’d like to come back to you. Certainly, we can all have vision, but execution is what kinda separates winners from losers in the market. And I’d like to ask you, as the CEO, what’s the secret, if you want to share it with us, right? How do you translate this vision that attracts someone of Ashish’s quality and character and then translate that into an execution that actually translates to success in the market?

    Sijbrandij: Yeah, I’d love to talk about that. We’re biting off a lot, so I think we’re now—GitLab offers a great solution for 10 different product categories. So, that’s massive. There’s a lot of engineering effort. For example, we have a CI/CD team that is just 10 people, and that they have to compete with people that are 100 times bigger. So, how do they do that? First, they’re just selected. GitLab CI is the leader in this space. There’s GitLab CI on the top right and then whole lot of nothing.

    Shimel: Mm-hmm.

    Sijbrandij: So, how do you do that with 10 people? Well, there’s a couple of secrets. The first one is—you don’t do that with 10 people, you do that with 1,800 people. So, we’ve got over 100,000 organizations using GitLab, and over 1,800 people contributed to the product. So, in the release that will go out in a week from now, there’s not just 1 contribution, there’s not 10, there’s 93 features that people contributed that aren’t paid by GitLab.

    So, we see it as, instead of having a tool chain where you have to make the integrations yourself—and that’s not just a few, we identified over 24 integrations you have to make in a standard DevOps tool chain. Instead of making them all yourself with your DevOps tooling team, you work together with 100,000 organizations and 1,800 people to do that.

    So, that’s the big secret. It’s open source. We work together. Then there’s some small secrets, and one of them is iteration. Iteration is one of our six values, and it’s something that everyone is super excited about when they join, but they all kind of don’t understand how painful it is, because it’s very, very painful to do the minimal thing. We’re now in a call with Ashish that Ashish will probably not like that we’re gonna probably change the header on our home page today, because we thought of something better. He’s probably gonna say no, but give me a month, I can think of something even better. And I will be like, “That’s great, Ashish. Think of something even better and then change it again.”

    Shimel: Yep.

    Sijbrandij: It’s very, very painful, and we do that throughout the company, and in product, it’s a very painful thing. My previous call was with Martin, and they’re working on a cloud native chart for GitLab, and we have a thing with uploads and we probably are gonna ship a chart with an NFS server as a part of that. A very clumsy thing, but it unlocks everybody else, and we can keep shipping. And one of our other subvalues is boring solutions, and I love that, because it’s so obvious. You say “boring solution” and people understand what you mean. We don’t go for the shiny toy. Our mission is, everyone can contribute, and people can only contribute if there’s a stable environment to do that, if they understand what you’re doing.

    So, when I saw the GitLab code base a year after Dmitri created it, I expected to see a hobby project. Someone super passionate, but doing this outside of work, like, putting some new development paradigms in it and having something that is hard to comprehend, especially since 300 people already contributed in that first year.

    And instead, I opened up the code base, and I saw a pristine Ruby on Rails application. Totally idiomatic, like, exactly how it should be, and we kept that. We don’t allow anyone to do anything that isn’t boring, and that enables everyone to contribute. That enables us to make forward progress, and we adopt the best of what’s out there. We embrace Kubernetes, we embrace Prometheus—really great, rock solid open source solutions that we can build for later on, and that’s been a big success.

    Shimel: Absolutely. You know, Sid, that was a mouthful in more ways than one, right? So, let’s hit on a couple things. First of all, harnessing the power of open source, right? Right out of The Cathedral and the Bazaar, you know, the book, and what’s gone on is, I mean, the false multiplier there is amazing. Of course, there’s a certain amount of a herding cats element to it, right, in getting everyone moving the same way. But if you can, harnessing that power is just—you know, it’s amazing.

    No. 2, you know, you spoke about iterations and sort of feedback loops and constant change, right? This is core to DevOps, right? This is DevOps 101 kinda stuff.

    Sijbrandij: It really is. This is exactly what we deliver to customers.

    Shimel: Yeah.

    Sijbrandij: Organizations adopt GitLab because we can make their DevOps life cycle three times faster, but you still have to work between the tools. They had these handles between the tools, they had these integrations that weren’t transparent, that weren’t seamless.

    With GitLab, they can work concurrently. As soon as you push your change, QA is gonna run, security tests run, production is gonna have the first review up out there. There’s not a sequence to it. It is, you paralyze the whole process and you gain tremendous speed and you reduce your time to value, and you allow to get feedback and to improve based on that. That’s the value we bring as a product and of course, we try to practice that ourselves.

    Shimel: Yeah. Well, so, but you more than practice it yourself. I think, you know, Sid, I’m a little different. You’re the CEO of this great company, GitLab. I’m an observer, I’m a fly on the wall of many DevOps companies, of many DevOps transformations, and I will tell you, the DevOps tools providers who do it best are those who eat their own dog food, who are practicing DevOps themselves. If you can’t do DevOps internally, don’t try to tell other people how they should do it or, you know, what they should be doing.

    It’s not a case of “do as I say, not as I do.” You have to live that, you have to talk the talk, walk the walk in order for you to truly understand it well enough to get other people to buy into it and be successful. So, kudos to GitLab for doing that.

    You guys recently announced an acquisition in the securities space. We’re kinda running low on time, but I wanted to just touch on that. Sid, your take on it?

    Sijbrandij: Yeah, we acquired a company called Gemnasium, and I think they’ve done the best job of any company of assessing all the different libraries, all the dependencies that are out there and saying which ones are vulnerable, which ones contain a problem. And that is functionality that’s gonna, that’s part of the DevOps life cycle, so we want them to be right in the product.

    So, we’re really happy to join their team, and I’m super proud of them for embracing our values, because they joined us, and within three weeks, all the Gemnasium functionality ended up in GitLab, so.

    Shimel: That’s cool.

    Sijbrandij: We know we hired the right people, they’re amazing, so congrats to Philippe and his team.

    Shimel: Yep. Congratulations to them. And look, we see it here, you know, this whole DevSecOps thing, if you will, if you want to call it that, is probably, along with testing, two of the hottest areas within the larger DevOps community.

    Ashish, we’re almost out of time. Let me come back to you, though. So, you joined this fantastic organization. We’ve heard from Sid a little bit of a peek into what’s making this engine roar, this rocket lift off. What are you gonna bring to the table? What are we gonna see from you, Ashish?

    Kuthiala: I think we need to take this message out to the marketplace, like, you know, a couple of things you talked about when people hear GitLab, they sometimes confuse it with the Git community and other Git offerings like GitHub, for example. So, we really need to tell the world what we are doing, and we are much more than just a repository engine, right? We do a lot more.

    And now that, you know, we are out there trying to help other customers with their DevOps challenges, it’s actually a little bit more than what Sid mentioned here; he is being humble. So,  not only are we practicing our own DevOps methodology to develop and roll out our application, but we actually use DevOps in every single aspect of running the company, right? Right from the hiring process when I joined to everything that I do in the company adopts a pipeline—you know, you create an issue and you run it through the pipeline and you merge that issue and it goes to production. If something is wrong, you know, it comes back.

    Amazingly, everything, between signing for benefits to updating the webpages to running our tracking of issues of what we do, it’s all run through pipelines. And I think I see that as a future. You know, DevOps is not just to be applied to delivering IT value, but you know, it is a methodology that can be applied across running your company for all functions.

    So, I think the version of GitLab is much bigger than just helping companies deliver efficient software really fast out there with feedback on the DevOps methodology. It’s almost to pivot and change the way we think about delivering value to our customers, in every aspect of running the company that we do. And I want to be part of that. I think it’s really exciting. I can’t wait to kind of start talking about this to everybody and, you know, seeing how we go down this journey.

    Shimel: Great. Sid, we’re over time, but I want to give you the last word, so I’m gonna ask one last question for you. What can we expect to see next from GitLab?

    Sijbrandij: We detail a really ambitious vision, and the vision is called Complete DevOps. And we said we’re gonna realize that this year, and we’re executing on that. We’re really proud, we integrated a complete web IDE in GitLab, so VS code running in GitLab. No need to check out this autocode base, you can just edit right there and then.

    But it consists of a lot of parts. We’re gonna have real time editing of issue and merge request descriptions. We’re gonna add logging to GitLab. You can already do monitoring, but we’re gonna add something for your logs, we’re gonna add application performance monitoring. Lots of other things that we think are needed to have a complete solution.

    So, if you started a startup, the only things you have to do is incorporate it, get a Kubernetes cluster, and install GitLab on it—job solved. Like, you’re up and running, you don’t need any other tools, and the only thing you have to do is, you push your code and already today, GitLab detects what language is it, it builds your code, it tests your code, it tests for all the security issues that might be there, it tests your code quality. It gives you all that. It gives you a review app to work with, kind of a staging app. That already works in GitLab today and we’re expanding on that, and I’m super excited to deliver that to the market this year.

    Shimel: DevOps complete. Thank you. Ashish, Sid—thanks so much for being our guests on this episode of DevOps Chat. Continued success with GitLab. We’ll be checking in—actually, I’ll see some of the GitLab folks at IBM Think in a few weeks, and we’ll get an update there, but Sid, you’re always welcome to be a guest here, don’t be a stranger, and congratulations.

    Sijbrandij: Thanks so much. Thanks for having us. I enjoyed this. Looking forward to coming back.

    Shimel: Alright, Ashish—

    Kuthiala: Thank you, Alan, for having us.

    Shimel: – good luck, my friend. Be well. This is Alan Shimel for devopsy.kinsta.cloud. You’ve just listened to another DevOps Chat, and we’ll see you soon on another DevOps Chat, everyone.

    — Alan Shimel

  • DevOps Chat: Startup Playbook, Founder to Founder Advice w/ Rajat Bhargava

    DevOps Chat: Startup Playbook, Founder to Founder Advice w/ Rajat Bhargava

    Two old, good friends of mine published a book yesterday called Startup Playbook. The book is “founder-to-founder advice on how to create and build your startup.” In this DevOps Chat, I sat down with my friend and co-founder Rajat Bhargava. We talked about why he and Will Herman wrote this book, what he hopes others can learn from it and Raj gives us 3 tips on what every first time founder should know.

    Between them, Will and Raj have started more than a dozen venture backed companies and have had multiple 8 and even 9 figure exists. If you have ever thought about starting your own company, had a great idea but weren’t sure what to do with it or just thought you could do a better job than the people you work for now, this book could be what you are looking for.

    For this week (Feb 19) the book is available on Kindle for just 99 cents! Here is the link for the kindle download.  Also a few times at the end of our conversation I referred to the book as the “Founders Playbook”. I tried to dub in the correct name, the “Startup Playbook” but my feeble interviewing skills are far superior to my sound engineering ability. Apologies.

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

    Audio

    Transcript

    Alan Shimel:              Hey everyone, it’s Alan Shimel, devopsy.kinsta.cloud, DevOps Chat. We’re here with another great DevOps Chat. Today’s chat is a little different for a couple of reasons. First of all, my guest is a very long-time – did I say long-time? – friend of mine, Rajat Bhargava. Raj, welcome to DevOps Chat.

    Rajat Bhargava:         Thanks for having me, Alan.

    Alan Shimel:               Hey man, thanks. Secondly, our chat today is a little different. Rather than talking nuts and bolts of DevOps and that kind of stuff, we’re gonna talk about Raj’s new book, along with his co-author, another friend of mine, Will Herman, called The Startup Playbook.

    Raj, I’ve known about the project for some time, but tell our audience, share with them what is The Startup Playbook. Why did you write it?

    Rajat Bhargava:         Well, The Startup Playbook is really our founder-to-founder conversation with other entrepreneurs. We’ve seen so many books out there that are from DCs, they might be from analysts, they might be from other folks out there, but we felt that founders out there needed a book from us, from other founders. Whether we wrote it, Will and I, or somebody else, we just felt like somebody had to talk about the tips, the secrets, the tribal knowledge, the stuff that we get by getting together and talking to other founders. We just felt like that was missing.

    We have these conversations with so many other founders on a daily basis because we mentor and advise and help support other founders, we just felt like we needed to write it down. It’s like around the campfire, we have so many of these conversations, we felt like we needed to write it down so that there was a place that other founders could go to to learn quickly.

    Alan Shimel:               Just in the way of full disclosure, you know, Raj, you and I have worked together on at least two or three companies, maybe more. But in the way of background, you’ve actually founded, what, about eight companies now, starting when you were still back at university at MIT, correct?

    Rajat Bhargava:         Yeah, that’s right. So, it’s probably now close to 10 that I’ve helped start, or started myself. There’s just a lot of mistakes that I’ve made and a lot of challenges that I’ve faced, and I wanted to share those. On the same, Will has probably started five different businesses and he’s got tremendous experience, tremendous knowledge. We’ve both been through so many different things that we wanted to share those so that other people didn’t have to go through the same pain that we went through.

    Alan Shimel:               As we used to call it, the idiot tax, right?

    Rajat Bhargava:         That’s right.

    Alan Shimel:               Our audience – I don’t know how many “entrepreneurs” we have listening in, though I hope there are some – is made up of a lot of technical people. People, Raj, not that different, frankly, than you, right? Who have a great engineering background, live, breathe and die in today’s technology.

    I’m sure there’s a big subset of them out there who maybe have a great idea, who see a hole in the market, who see a need in the market, have something that they say can really maybe change the world and make a great company. But they just don’t, they’ve never done it. They don’t know where to start. I know that’s who you are aiming for a lot in this book. Talk to us a little bit about that persona, that kind of person. What’s in the book for them?

    Rajat Bhargava:         Well, this book is absolutely targeted directly at them. In general, the book is a founder-to-founder conversation. The founders we’re really trying to target are those first-time founders, the folks that haven’t been through it before. Like you said, they may not know all the steps that they need to go through. They may not even know if founding a business is the right thing for them.

    So, we actually start before you start a business in the book. We start about whether this is the right thing for you to do for you, for your family, for you as a person. Is founding a company the right thing for you? We start there. So, it’s from the ground up and we build up from there.

    I think our belief is – we’re biased because both Will and I were engineers by educational background – we think some of the greatest businesses are started by engineers, by technical folks. We love when technical folks bring ideas forward, and we think they can change the world. The challenge is that the idea is just not good enough. Ideas are, unfortunately or fortunately, either way you look at it, they’re a dime a dozen. It isn’t the idea that’s so differentiating; it’s all of the other work that you do around the idea that makes it differentiating, that makes the successful business.

    That’s a lot of what we talk about in the book is that the idea really just isn’t enough. It’s a seed. It’s a kernel. It’s where you start, but it’s just the beginning. It’s a long, long journey, but a great idea is a wonderful place to start.

    Even an okay idea is a great place to start because you can iterate on it and you can improve it. You can make it much better. Then, a lot of the stuff that you do around that idea is what differentiates you and helps make you successful.

    So, for your audience, for technical folks who have an idea, we think that’s fantastic. That’s a wonderful, wonderful base to start with, to build a business.

    Alan Shimel:               You know, there’s a lot in there, Raj. I want to highlight a few things. First of all, it’s true, whether you have a job or you’re starting your own company, but don’t underestimate that when you go to start, become a founder, that it doesn’t just affect you, right? It affects your family, your loved ones, your significant others and what have you. Because I’ve never met anyone who is successful with a half-hearted attempt to start a company, or to start a business, or to nurture an idea like that, to nurture a business. To me, it’s either you’re all in or you’re out.

    Rajat Bhargava:         Absolutely, yeah.

    Alan Shimel:               That’s one thing I think people need to think. Let me also hit on one other thing and that is when you speak to people, and you’ve spoken to more than me, but I’ve spoken to my share, what’s the biggest thing holding people back? If I took a poll, Raj, and said, “Hey, who would like to start their own company, be their own boss, and make a lot of money and be successful?” Very few people are gonna keep their hands down; everyone wants to do that.

    What stops people from doing that? Well, number one, it’s a little bit of fear of the unknown, having never done it. But number two, the biggest thing I hear from people is, “My god, I don’t have the money to get there. What am I gonna do until my company makes enough money? How do I bridge from having a job with a steady income that keeps the lights on to the time where my startup is enough for me to support myself?”

    That’s probably the single most scariest thing for first-time founders. What do you think?

    Rajat Bhargava:         You know, I think you’re right. I think there’s absolutely the fear of the unknown and fear of failure which, by the way, 9 out of 10 startups, according to the research, fail, which we actually think is low. We probably think it’s closer to 95 out of 100, maybe even 97 out of 100. Very few companies succeed long-term. The ones that are breakout successes that we hear about in the media are few and far between. It’s so few of the ones that start.

    I think the second point is such an important point, which is how do I go start this business when I need money to live on, and there’s no cash coming in at the beginning? Well, that is a very, very hard problem. The good news is there are so many solutions to it, but some of it is a leap of faith, too.

    The thing I would start with is there is so much prep work that needs to happen before you launch a business. That is where we spent a tremendous amount of time in the book talking about how do you vet your idea? That doesn’t have to happen only with you quitting your day job, and going and working on it. Some portions of that at some point you may need to do full time, but you can do a tremendous amount of research, of vetting your idea, of building your plans, of figuring out whether this concept that you have can be really, truly built into a business.

    We encourage people to spend an inordinate amount of time at the beginning going and doing that. Because if you can build the right foundation at the beginning, you’ve got a shot at making it successful. If you start with a very shaky foundation, those cracks are gonna get exposed very fast and the chances of you succeeding go down dramatically. So, even if you need that job, even if you need that income coming in, there’s still a lot you can do to build out your concept and build out your business, even before you take the plunge.

    Alan Shimel:               Fair enough. So, Raj, if we take that as okay, that’s one tip for prospective first-time entrepreneur founders, ’cause we’re running low on time, give me three or four others, if you can. Maybe a top five of what a first-time founder should…really idiot tax saving tips here that they can really rely on.

    Rajat Bhargava:         Sure. I’ll give you three. The first one is the one we just talked about, but I’ll expand it.

    I think completely vetting your idea before you really go all-in is so critical. That includes things like the value prop, the target customer. How can you build a team, or who is the team? Can you actually build the product or service that you’re proposing?

    Can you differentiate it in the market? How are you gonna go get customers? How can you make money? Can you raise money to support yourself? All those things are the art of what we call vetting your idea. The more you can vet the idea from the beginning, the more solid of a foundation you have. That’s tip number one is completely vet your idea.

    Tip number two is build a team around you. People think that starting a company could be just a single founder. Especially as an engineer or a technical person you might say hey, I’ve got this great idea. Why do I need to have another co-founder until later?

    Well, we encourage you to get other co-founders right out of the gate. At least one, if not two. It’s critical that you have some people who are side-by-side with you as you go through this journey. Find people who have different perspectives, but that you can really work with. It’s one of the most important relationships that you’ll have in the business.

    The third thing is find mentors, advisors, board members, people that have done it before that you can learn from. There is nothing like saving yourself time, mistakes, challenges, problems by hearing advice from others. You have to be open to it, but if you’re open to it, you can really accelerate the progress of the business.

    Those are three quick tips that I would say are things a first-time founder ought to think about really hard.

    Alan Shimel:               Yeah, and those are three good ones, too. I’m sure the book is chock full of more of them.

    Raj, let me throw you a little bit of a curveball. In addition to wanting to start businesses because they see needs in the market, I can’t tell you how many engineers and technical folks I speak to that would like to write a book. Again, I don’t know what stops them. Many do cross that chasm, right, and write a book; many don’t.

    For people who maybe don’t want to start a business today, but do want to write a book…and most of them are not novels. They’re much like Founders Playbook, non-fiction kind of books. What advice can you give to budding or prospective authors out there?

    Rajat Bhargava:         You know, It’s different for everybody, but the thing that I think helped Will and I the most was we just broke it down into a little bit of time every single day. When I initially wrote the first draft of the book, I had a target of 1,000 words a day, which isn’t a lot, as you know, Alan. You can write 1,000 words probably in about 30 minutes, so it’s really not that much time. But if you plug away at that for 90 days, for just one quarter [break in audio]. The typical book is really more like 45,000 words. If you did it for 90 days, you’ve got 1,000 words, and you can throw away half of those words because –

    Alan Shimel:               And still have a book.

    Rajat Bhargava:         And still have a book. Or you could have two books, right? I think that’s the biggest thing is just don’t try and do it all in one sitting ’cause you can’t. That’s not the way it happens. You need to just chunk it up and do a little bit at a time. In my case, what I did was I just started writing. I didn’t even really have too much of an outline. I just started writing 1,000 words a day.

    Then, we took that and we started formulating that into a book. So, we threw out tons of it, we rewrote it a couple of times. There’s just a tremendous amount of editing work. But the editing work turns out to be a lot easier – at least it feels easier; it probably isn’t easier – because you already have something down. It’s the blank sheet of paper that’s really daunting. But if you say, “I have a blank sheet of paper today and I only need to write 1,000 words,” that’s not that bad. You can get there.

    Alan Shimel:               Sounds like an agile methodology to authoring a book. Doing it in sprints.

    Rajat Bhargava:         Exactly. Yeah, exactly. Do a sprint a day.

    Alan Shimel:               Yeah, that sounds cool. A little scrum meeting in the morning.

    Well Raj, we’re about out of time here, but for our audience who maybe are interested in taking a look at Founders Playbook, I know you guys are offering sort of an introductory launch as the book goes to launch special. Where can we get some information here?

    Rajat Bhargava:         You can go to startup-playbook.com and you can also go to Amazon and just search The Startup Playbook. It is 99 cents for the Kindle version for the first week or so; that’ll come up on Monday the 19th of February. It’ll be 99 cents for a week. We’ve tried to make it really accessible for everybody. We really just want to get the knowledge and the content out into the founders’ hands.

    Startup-playbook.com, or look on Amazon, The Startup Playbook.

    Alan Shimel:               Raj, beyond the book itself, I know you and Will have plans to try to nurture a community here with that. If people have questions, are there places on the website where maybe they could ask and stuff?

    Rajat Bhargava:         Yeah, absolutely. You can reach us on Facebook, on Twitter, on LinkedIn. If you go to the website, there’s links to all of that. You can reach out to us pretty easily. You can find us, and we’d be happy to engage and chat with you.

    Alan Shimel:               Sounds great. Hey Raj, I know this was a labor of love, but it was nevertheless a labor, and a long time coming for both you and Will. So, congratulations on the launch of the book, The Founders Playbook. You know what? We’ll keep an eye on it and watch it. I hope some of our listeners out here go check it out. The only thing you have to fear is fear itself. If you’ve got a great idea, the world’s waiting and you can make it happen.

    Rajat Bhargava, my friend as well as author of The Founders Playbook, thanks for being this episode’s guest on DevOps Chat.

    Rajat Bhargava:         Thanks for having me, Alan.

    Alan Shimel:               All righty. This is Alan Shimel. We’ll see you soon on the next DevOps Chat.

    — Alan Shimel

  • DevOps Chat: ASRTM for DevOps with Rohit Sethi, Security Compass

    DevOps Chat: ASRTM for DevOps with Rohit Sethi, Security Compass

    In this DevOps/Security Boulevard Chat we speak with Rohit Sethi, COO of Security Compass about ASRTM, which stands for Application Security Requirements and Threat Management. Gartner has recently released a hype cycle on ASRTM, with Security Compass and its SD Elements offering named a leader in the market. Rohit gives us a good background and foundation on ASRTM and why it is important for both DevOps and security teams.

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

    Audio

    Transcript

    [su_pullquote align=”right”][su_custom_gallery source=”media: 119457″ target=”blank” width=”200″ height=”200″]Rohit Sethi
    Rohit Sethi joined Security Compass as the second full-time employee. As COO, Rohit is responsible for setting and achieving corporate objectives, company alignment and driving strategy to execution. Previous to this role, he managed the SD Elements team. Rohit specializes in building security into software, working with several large companies in different organizations. Rohit has appeared as a security expert on television outlets as such as Bloomberg, CNBC, FoxNews, and several others. He has also spoken at numerous industry conferences s and/or written articles on major websites such as CNN.com, the Huffington Post and InfoQ.[/su_pullquote]

    Alan Shimel: Hey, everyone. This is Alan Shimel for Security Boulevard Security Chat, and this will also be appearing on devopsy.kinsta.cloud under DevOps Chat. So two chats for the price of one, though it’s one chat. Welcome, and we have a great guest lined up for today. I have Rohit Sethi—and I mispronounced that. I think it’s actually Rohit Sethi. But in any event, you can correct me. Rohit, welcome.

    Rohit Sethi: Thank you.


    Related Content:

    How Developers Can Take a More Proactive Approach to Security

    DevOps Chat: Aqua Security Seeks To Secure Containers


     

    Shimel: Just for the record, say your name correctly.

    Sethi: Rohit Sethi.

    Shimel: Rohit? Okay. Rohit, you know, as my mom used to say, “Call me anything you want, but not late for dinner.”

    Sethi: [Laughter]

    Shimel: Welcome to Security Boulevard Security Chat and thanks for joining us. So you are the COO of Security Compass, correct?

    Sethi: Correct.

    Shimel: And there’s probably people in our audience who maybe are not familiar with Security Compass. So why don’t we start there. Can you give us a little bit of background on Security Compass?

    Sethi: Sure. We are a firm that is specializing on software security. And we have three main offerings around that. So we have an advisory practice that does penetration testing, and code reviews, and threat modeling, but also helping people build up their secure software program. And especially more recently building up their dev sec ops program and building security into their DevOps pipeline.

    Shimel: Mm-hmm.

    Sethi: We have a training practice, which is specialized in training developers. We’ve partnered with ISC-Squared and we offer a certificate or batch program on secure development for software developers. And then we have a product called SD Elements, which is an application security requirements and threat management. I know that’s a mouthful. And what we’re going to talk about today is a platform that helps people build security and compliance to some extent into their software development process, and particularly for agile and dev ops processes.

    Shimel: Excellent. Now, so a couple of things that we want to talk about relate. And one of them is recently Gartner’s come out with another magic quadrant or a new magic quadrant where they’re kind of lumping together what I personally always thought of was two distinct areas. And they’re calling it – and I’m going to mess this up. Why don’t you help me? AR –

    Sethi: ASRTM.

    Shimel: ASRTM. Why don’t you tell our audience what that stands for?

    Sethi: Yeah. ASRTM is application security requirements and threat management. And it’s not quite a magic quadrant yet, but it’s on the hype cycle.

    Shimel: Hype cycle. You’re right.

    Sethi: Okay. So they’re identifying it as a sort of an emerging category for people to start paying attention to.

    Shimel: Yep. And so for our audience and for me, talk to me. How did the nexus here between them?

    Sethi: eah. So you can think of [Laughter] anything in this category as being tooling that helps you to build security into the onset of development. Most of the tools that exist in the application security category today are some form of static analysis, dynamic analysis, interactive application, security testing. So really all different kinds of testing looking for security defects, or blocking the tax in real time. Right? So real-time application security protection or web application firewalls.

    And many people their entire budget is on testing and sort of blocking attacks. But really very little focus on building security from the start, except for perhaps in training. So everything in this tool category is essentially some kind of product that will help you to systematically and in kind of a scalable way build security in so that you don’t get those defects when you do your testing. And perhaps more importantly, to prevent defects that perhaps those automated tools are just incapable of finding.

    Shimel: Got it. Got it. Got it. Got it. And so I think we’ve laid the foundation, if you will, Rohit. Let’s jump into a little bit of how this relates to dev ops and what we call dev sec ops. So why –

    Sethi: Yeah.

    Shimel: Go ahead. Why don’t you take a lead on that?

    Sethi: Yeah. For sure. So DevOps is a phenomenon that it’s not just for sort of fast-moving organizations. Even some of the slower or I guess you’d say larger companies are starting to embrace DevOps, as you know. And it’s becoming really quickly sort of a mainstream philosophy. And there’s just really rapid pace of change of tooling that people are looking at – and not just tooling, but processes, to be able to accommodate continuous integration and continuous delivery in all of the mentality changes and processes that have to change to allow that to happen.

    Now, when we think about the traditional secure software development life cycle, there’s a lot of activities that we’ve typically suggested in the security community about following a secure SDLC, that really kind of incongruent with this idea of either having really fast sprints or no sprint, no iterations, just being able to take one ticket at a time, build it, and deploy it. So the idea of doing like an architectural analysis, or a one-week or two-weeks threat model, these things are sort of thrown out the door when the pace of development is too fast to keep up with it.

    And so that kind of opens up the need for automation. Now, there’s sort of a trend, and I would call it, I would label it a dangerous trend, that people are looking to 100 percent automated solutions to sort of take away the security problem. Right? So you’ll see sometimes people will put together presentations on DevSecOps and they’ll say static analysis is sort of your way to handle secure coding. And then perhaps some penetration testing on a periodic basis and you’ve kind of checked off the box for secure development. But the reality is that, in fact, security is a lot more complex than that.

    Static analysis tools and dynamic analysis tools have their strengths, but they also have significant gaps. We actually put together a white paper that talks about the missing parts of what scanners can’t find, false negative gap. And one of the interesting things is if you look at sort of CC plus plus development for a second, one of the most pervasive vulnerabilities is buffer overflows. This is the thing that caused Heartbleed and WannaCry and pet. Yeah. It’s sort of the underlying root cause there was some memory management issue.

    And if you were to take some of the best practice in terms of highly automated scanning solutions and put them all together, they’d still be able to find less than half of all buffer overflow vulnerabilities. Yet, this is what a lot of the industry is converging on as good enough from a software security perspective.

    So not everybody looks at it that way, and there’s a lot of people who realize that there’s a gap here that we need to do more than just scanning. It is an essential part of the solution, but we need to be able to identify what are all of the relevant threats to an application development, and how do we actually build mitigating controls rather than fixing the vulnerability after the fact? So prevention instead of detection.

    And that’s really where the ASRTM category fits in. It allows you to define what those controls are and build them into the software development process. Not only, in fact, from a security perspective, but also like compliance control, some of the GDPR issues that will come up there.

    You have to kind of build data protection by design and default. You need a system, a systematic way to identify these as essentially requirements that go into your backlog, right, and that you can track whether or not they’ve been tested. And that’s quite different than the approach that people have typically taken to finding vulnerabilities after the fact and fixing them.

    Shimel: Mm-hmm. So Rohit, our audience, especially from devopsy.kinsta.cloud, of course, is extremely savvy to the whole DevOps and DevSecOps terminology and kind of what’s happening. One of the issues that we see with this, though, is so many of our security solutions are geared for security professionals.

    Sethi: Yeah.

    Shimel: Where so much of the real responsibility for secure coding and secure apps lies with the developers.

    Sethi: Yes.

    Shimel: Right?

    Sethi: Yeah.

    Shimel: And to that no one – you know what? I’ve never met a developer, Rohit, who raises his hand and says, “I want to develop insecure code.” Or, “I want to have an insecure application.” They all want security, obviously.

    Sethi: Yeah.

    Shimel: But they may not have the expertise. They may not have the support. They may not have the time, frankly, to do it right.

    Sethi: Yeah.

    Shimel: So how does like a Security Compass type of solution help not only the security guy, but the developer, as well?

    Sethi: Yeah. Excellent question. So the way that the work flow in an ASRTM solution works – and I’ll talk specifically to ST Elements, which is our product. But we’re not the only product that does this. Is that somebody in a product team – so we have a lot of clients that use it this way. It’s sort of a self-service model.

    So let’s say like a project manager. And so you mentioned developer, but I would extend that to the entire development team, right? Product owners, product managers, scrum masters, etc., right, who are involved with building software. So you take sort of a lead, whether that’s product manager, project manager, product owner, scrum master, lead developer. And they fill out a questionnaire that’s kind of like a base online ramp up of that software they’re building. So they’ll answer like a multiple-choice questionnaire.

    And then based on the results of that questionnaire, they’ll get a defined set of prescriptive controls that are essentially security user stories, right, that you need to build into your software. And then what they’ll do is they’ll integrate it into gira, or Microsoft Team Foundation server, or whatever it is that the development team is using to manage their backlog. And then the product owner is then responsible for grooming it, just like they do feature or functional stories. Right?

    So now what we’re doing is we’re taking the backlog, which is sort of the de facto list of work that needs to be done, and we’re putting non-functional requirements alongside the functional requirements, which allows the development team to take control of when they’re going to implement security work or security features, as opposed to just reacting to a security defect that’s found later on. So basically you’re turning unplanned work into planned work. So that’s the first thing that you do to sort of empower the development team.

    The other, of course, is that when you take a look at these requirements and these controls, you actually start to bake training into it. So someone might get a control that talks about how to implement a secure password reset. Right? So this is a feature in the system that is the kind of thing that you really can’t find with an automated scanner, but that could lead to significant risk if it’s done incorrectly.

    So you can actually have a Gira ticket that talks about the correct way to implement secure password reset, and you can have an actual embedded training module so somebody could actually learn about well what are the ways that people exploit password reset at the time that they implement the control. So it’s what we call just-in-time training. We think it’s a really important and powerful concept, especially as it relates to fast-moving development.

    Shimel: Absolutely. So Rohit, I’ve always wanted to ask this question, then. And that is it’s incredibly difficult, then, as a Security Compass, let’s say –

    Sethi: Yeah.

    Shimel: To, I mean, number one as a salesperson to, who do I sell to? Who has the budget? Who is my technical stakeholder?

    Sethi: Yeah.

    Shimel: Who is making decisions? But beyond, you know, pity, no one’s going to play hard to the flowers for the sales team. [Laughter] But beyond that, as a solutions provider, serving two masters here.

    Sethi: Yes. Yes.

    Shimel: How?

    Sethi: You know it – go ahead. Sorry.

    Shimel: No, no. I was going to say how does that – I just, it’s gotta be really hard.

    Sethi: It is hard. I wouldn’t say that it’s easy at all. But I think that it’s critical work. Like our vision as a company is a world where you can trust technology. And we really think that if we don’t do security right, that that vision will not be realized. People will be afraid of technology to some extent. We won’t be able to exploit the possibilities that technology affords us because we’re afraid of vulnerable technology.

    And really, when you think about the root cause of most of the security incidents, sometimes it’s an insecure web application, but sometimes it’s a vulnerability in your desktop or operating system, or like a browser component or something. But so often it’s a secure coding issue. And so much of the sort of cybersecurity budget and infrastructure is based on the fact that well, let’s just take for granted that the software is insecure, and let’s find ways to mitigate the risk.

    And of course we’ll never get 100 percent secure code. But we really think that there’s a huge gap between what we can feasibly do, right, versus what’s being done in industry today. And so that motivates us. And I think often when we start to talk about the data, we talk about and when we’re talking to the chief information and security officer, or the chief information officer, we talk about a visibility gap that they have, right?

    Which is that right now the way that most companies work is they have a GRC solutions and sort of a policy departments to talk about what their high-level information security policy is. And then they may have some automated solutions to help enable that policy. But there’s sort of a gap between this high-level policy and then what are the specific things that an IT team needs to do to make sure that that policy is being followed and being able to track that?

    And that’s really, I think, at the heart of what an ASRTM solution provides is the ability to take this policy, turn it into procedure, turn it into something you can track, and ensure consistency, right? Because you can’t rely 100 percent on sort of automated scanners to catch everything. So you need to have this sort of translation there. And we find that that works pretty well. People are receptive to that need.

    And then, in fact, it’s not just application security, but it also involves infrastructure security, hardening servers, and that sort of thing, bender security, bender risk management, cloud security, how secure your cloud applications, and how do you know what to test against? So just like a variety of needs are met by adopting a program, really, that allows you to define your security controls at the granular level that your DevOps teams can implement them and you can track that.

    Shimel: Fair. Fair enough. So what does the future hold here, then?

    Sethi: Well, my hope is that we realize that vision, right? We get to a point – what I would like to see, for me success in the long term is that when we find that there’s a vulnerability that’s exploited in the wild that that vulnerability never creeps into code again. Right? Like if we know how to mitigate it, then it’s mitigated forever. And we’re so far away from that reality right now. Right? Like a lot of the real-world exploits are traced down to what is the root cause? It’s a secure coding issue that we’ve known for 15 or 20 years, in some cases.

    And that’s just not good enough. So we’d like to get to a place where the only hacks that occur are really novel. Right? Like we’ve never seen anything like this before. And some really profound security researcher has found a security issue that they’ve spent a significant amount of time understanding that specific domain. Right? But not sequel injection. Right? Not parameter manipulation. Not things that we’ve known for years. And that’s really, I think, where we want to go. And I think that inevitably that’s the direction that the industry is going to move towards.

    Shimel: Agree. Agree. Rohit, when we started, I told you the time goes quick. And we are coming up on our 15-minute window. But let me give the listeners – we want to find out more about Security Compass. Where can they find out more?

    Sethi: Well, of course, you have, you know, SecurityCompass.com talks quite a bit about what our offerings are. You can feel free to e-mail us, info@SecurityCompass.com. I’m personally on Twitter so you can follow me. Just @RKSETHI. We have a LinkedIn page for Security Compass, as well. So lots of different ways you can interact with us.

    And like I said, we offer training. So a lot of people who are, just want to learn more about application security, we have courses that you can just sort of enroll yourself. And we’ll be releasing more of those in the near-term future, as well.

    Shimel: Got it. All right. So Rohit Sethi, thanks very much for being our guest on this episode of Security Boulevard Security Chat, as well as DevOps Chat. And we look forward to hearing more about Security Compass in the coming months. Thanks for being our guest today.

    Sethi: Thank you for the opportunity. Appreciate it.

    Shimel: All righty. Rohit Sethi, Security Compass here on Security Boulevard. This is Alan Shimel, and we’ll see you soon on another DevOps or Security Boulevard Chat.

    — Alan Shimel

  • DevOps Chat: Rosalind Radcliffe, IBM, on DevOps and Mainframe Systems

    DevOps Chat: Rosalind Radcliffe, IBM, on DevOps and Mainframe Systems

    In this DevOps Chat we sit down with a frequent guest on DevOps Chat, Rosalind Radcliffe, distinguished engineer and mainframe expert from IBM. Rosalind talks to us about the latest generation of Big Iron from IBM, the z14 systems. Also, we discuss some of the new API and functionality that allows you to do just about anything with your mainframe that you do with your other computing platforms.

    Rosalind is always an interesting interview with lots of great information.

    Note: There are references to a video chat throughout the conversation. We tried to record this chat as a video, but unfortunately, the technology just didn’t work out well for us. But, as usual, the streaming audio of our conversation is below, followed by the transcript of our conversation.

    Alan Shimel: Hey, everyone. This is Alan Shimel of devopsy.kinsta.cloud, and you’re listening to perhaps the first video chat or video DevOps Chat from devopsy.kinsta.cloud. And I’m happy to have as my first video chat guest none other than Rosalind Radcliffe of IBM. Rosalind, welcome.

    Rosalind Radcliffe: Happy to be here, as always.

    Rosalind Radcliffe

    Shimel: Well, you’re not going to be able to sit and make faces while you’re talking because we can see you. But thanks for joining us. Let’s jump right into things. First of all for our audience who may not know Rosalind, Rosalind is a distinguished engineer with IBM and works within the IBM Enterprise Systems division, mainframes, e-systems, author, engineer, well-known speaker and just a great resource for anyone who is interested in DevOps, mainframe, systems of engagement, systems of records kind of stuff, and a frequent guest here of ours on devopsy.kinsta.cloud.

    So, Rosalind, the last time I saw you was over at Gene Kim’s DevOps Enterprise Summit in San Francisco. And I thought it was a great show this year. Had a chance to do a bunch of interviews. I did a panel on DevSecOps. But more than that, I really enjoyed speaking to a lot of the people in attendance there, a lot of the attendees. Any key takeaways from you on it?

    Radcliffe: Well, I think it was another really good conference, but it was one year next. So there was a lot of people who really have done the DevOps transformation or are a good long way on the DevOps transformation. And so there were a lot more stories about the value that they’re getting and how they’ve transformed, and more about the organizational transformation that happens after you start a DevOps transformation. So I thought that was very good.

    We also had more mainframe customers talking about their transformations, and it was really good to hear the stories about mainframe is really just part of the DevOps pipeline, and more and more customers are starting to see that.

    Shimel: I think so. And Rosalind, if you don’t mind, I actually wrote an article coming home from Gene’s event called “The DevOps Cha-Cha.” And it’s about this sort of undercurrent. I didn’t necessarily see it in the presentations, but I got it in speaking to people there. And that is this sort of whispered thing that hey, this DevOps thing isn’t that easy. Right? We thought it was going to be easy.

    And you know, my DevOps transformation is not going as planned, and it’s not going as fast as we wanted. And it’s not—there’s a lot of work involved here. And I don’t know what gave people the impression that it’s a hockey stick. You know, it was straight up. Things seldom are. I think DevOps can be lumpy, or DevOps transformations can be lumpy. And it’s a little bit of three steps forward, two steps back, cha cha cha, and so forth. Your opinion?

    Radcliffe: Well, I would absolutely agree. I don’t think people understand the cultural challenge to this transformation. Because it really is all about culture. And it’s not just bringing in tools, and a lot of people think, “I’m going to bring this toolchain in and it’ll all be fine.”

    And maybe some of the teams that works for. But there are a lot of teams that that’s really just not going to work for. And there’s just no way that we can just have this continue in the environment. We really have to make sure we are understanding that this is culture, and that the culture is really, has to change. And it’s across the entire organization.

    I think the other thing people didn’t realize is that it is a … what’s the best way to put it? It’s not just culture and you’re done, or it’s not just do it and you’re done. It really is a continuous improvement process. And we like to talk about the kicks team because they’ve been doing this for 15 years or something, and they know they’re not done.

    Shimel: Mm-hmm.

    Radcliffe: So it’s not something that ends. You learn your lessons. You get better. And you learn a new lesson, and maybe you didn’t get better. And so you learn the lessons. And it really is this continual improvement. And so it’s not easy. It’s not a piece of cake. But it delivers real value if you move down this pipeline.

    Shimel: Yep. I mean, takeaways. Dev ops is never done, right? You’re never done with DevOps. And it’s only a failure if you stop trying, right? Anything else is just feedback loops. [Laughter] Everything else is feedback loops. So I think those are great takeaways from that.

    So I went from Gene’s to another event to another event. And we’re rapidly, you know, Rosalind, approaching event season. And, of course, IBM’s big event this year is a little different than years past. It’s called IBM Think, right?

    Radcliffe: Yes.

    Shimel: It’s in March in Vegas. Can you –

    Radcliffe: Yeah. It’s going to be an interesting event. We’re bringing everything together in one. So we used to have in our connect, and Watson’s event, and internet of things. You take your choice of names. Now it’s all one. So we’re going to have one big IBM event for all of our technology, all of our parts of the product. And they’re really trying to bring it in a focused way to make sure it’s a set of customer stories on what they’re doing and how they’re doing things.

    Shimel: Do you know the exact dates, perhaps, off your head? Or if not we’ll –

    Radcliffe: Yeah. See, it’s March 19th. It’s March 19th. The first day is an inner-circle day. And the next Tuesday, Wednesday and Thursday are the main days for the conference. And so it’s a shorter week this time, not making people come in on a weekend and giving you a chance to get home, which I think is a very good thing. But it’ll be a fully packed set of days.

    Shimel: Fantastic. Hopefully we’ll see you out there. I’m not sure about devopsy.kinsta.cloud’s plans yet around it, but we will be making plans, for sure. So Rosalind, you spoke a little bit about Gene Kim’s event. We spoke a little bit about the upcoming IBM Think event. Let’s focus in now on Z systems, enterprise systems. I know you guys are, you released a new generation. What was it, around September or August?

    Radcliffe: It announced in July, July 16th or 17th, and became available in September. And yes, the Z14 with the latest announce.

    Shimel: Yep. And it’s brought a whole bunch of stuff to the forefront, probably some of the biggest might be around security and encryption from my point—humble point of view—anyway. But you’re excited about some new stuff coming up with the Z systems we were talking. Why don’t you share it with our audience?

    Radcliffe: Yeah. I’m really happy. We’ve been doing a lot of work to make the dev ops pipeline work for z/OS software. And a lot of customers are turning to open source. And so they want to use Git. And so I got Rocket to port Git to z/OS, so that’s the first step. And that’s great. That’s been available this year. But we have to have a build system. And so we have made available something called dependency-based build, and it’s in beta, and it will be GA by Think. The idea is you can use Groovy Scripts to write your build definitions for z/OS.

    So think about that. It’s not, you know, JCL. It’s not different. I can use Git just like any other language. I can use Groovy just like any other language. I could write my build scripts. And it’s not different. It can make our COBAL and PL/1 in assembler look just like all those other modern, fun languages.

    And really they—okay, assembler might be a little hard. But, okay, other than that, COBOL is just English and PL/1 is a pretty good language. So why not? The fact that you have to do things so differently, we want to get rid of all that. And so this new capability, it’s in beta. Anybody’s well—it’s an open beta. Think about this. IBM open beta? Yep. There it is.

    Shimel: IBM –

    [Crosstalk]

    Radcliffe: Go play with –

    Shimel: That would be neat. [Laughter] Where can people go play with it? Did you have a URL or section?

    Radcliffe: We have a URL. I’ll get it to you so you can post it. It’s not a friendly URL.

    Shimel: You know, I can’t help but smile, Rosalind, and think about some of my friends and family who aren’t in the tech industry listening to this, or watching this, and hearing that we’re going to be playing with some Groovy scripts, what’s going through their head. But that is great news. And it’s part of this bigger movement.

    You touched on it a little bit. We started at Gene’s event, and it does show. And that is initially with DevOps we’ve been through the binary IT mode, the multi mode, multi speed, binary speed, all this nonsense where let’s treat the mainframe folks as special, and all of that.

    But I’m glad to see that—and Rosalind, I think I ran into you at CA World, perhaps, right, where IBM was a major sponsor. And that seems to be the message coming out of the enterprise world now, the mainframe world, which is that’s nonsense, that we’re not going to stand for being labeled special or anything like that. We move as fast as the next guy does, or as fast as the other systems do. We use the same languages in a lot of instances. And we’re even updating the languages that we do use to make them more relevant in today’s world.

    So to me that’s a huge message, right? That we need to continue hitting home, though. Because I still hear people talking about multispeed and all of that stuff.

    Radcliffe: Yeah. But bimodal is something that needs to go away.

    Shimel: Uh –

    Radcliffe: It just needs to go away. We’re done with it.

    Shimel: Okay.

    Radcliffe: The idea that things are going to go at different speeds is true, but it’s not based on platforms. If I build an API, I really hope I do a good job of that API. And it doesn’t matter if it’s running on a system of record or a system of engagement, it’s running in Java, or it’s running in Cobalt. If I write good code, I’m not going to be changing it 1,000 times a day. So the point is if you’re building APIs, you’re going to build them. But you need to be able to change them as fast as possible.

    So it doesn’t matter the platform. I should be able to deliver that code today. I need to make a change, let me deliver it. And I really—I guess I want Z to be considered special for its qualities of service, i.e. its reliability, its scalability. Not because it’s different in the way you do work for it. So if it’s just another node in your pipeline, it’s just another node. It just happens to have a different set of qualities of service. And if you build your node, or your Java, whatever, and you end up needing the qualities of service of Z, run it on Z. Why not?

    Shimel: Agree.

    Radcliffe: And let’s get the differences because you think a system of record has to be slow, or the differences because you think Z has to be slow. I mean, it’s funny to me. We call the mainframe an old system, but really with the Z14 and the LinuxONE announcement, it’s the most modern platform that exists out there. It’s the most modern chip. So how is it old?

    Shimel: Yeah. Yeah. I hear ya. A hundred percent agree. Rosalind, you know, we’re almost at the end of our time on this experiment and I do hope the video comes out. But if not, the audio will. And if you’re listening to this without video out there, it’s because the video didn’t work out so good. But at least we’ve got the conversation imparting the references to the video.

    Rosalind, we hope to see you soon. Maybe between now and Think we can do something a little more in-depth, a webinar or something about what we’ll see from Enterprise Systems at Think and what else we have coming down the pike as we move closer to Think. And until then, though, have a merry Christmas, happy new year, happy holidays, and thank you for always being available to us here at devopsy.kinsta.cloud.

    Radcliffe: Well, thank you. Thank you for your time. And you enjoy the holidays, as well as everyone who is listening if they hear this before the holidays. Merry Christmas.

    Shimel: Yes, yes, yes. All right. Rosalind Radcliffe, IBM Enterprise Systems, distinguished engineer, and our guest on our very first video DevOps Chat. I guess they’re not DevOps Chats. All right, Rosalind. Thank you. Have a great day, everyone.

    — Alan Shimel

  • DevOps Pro Tips on Cloud Management

    DevOps Pro Tips on Cloud Management

    In this DevOps Chat we are joined by Andy Richman of Park My Cloud and Samir Mehra of Cloud Health Technologies. Both of these cloud experts give sound advice on how you can best and most efficiently manage your cloud infrastructure, whether it is on AWS, Azure, Google or anywhere else. If you are interested in optimizing your cloud deployments and cloud management in general (who isn’t?), then have a listen.

    As usual, the streaming audio of our conversation is immediately below, followed by the transcript of our conversation so you can read along. Enjoy!

    BTW, we have recorded two other podcasts with Park My Cloud. You can listen to them here and here.

    Alan Shimel: Hey, everyone, this is Alan Shimel, devopsy.kinsta.cloud, and you’re listening to another episode of DevOps Chat. We’ve got a great chat lined up today. We’re gonna be talking a little bit about managing your cloud infrastructure, cost, and how much do you really know about or how much insight do you really have into your cloud infrastructure.

    We’ve got two great guests lined up to join us and help us today. First, I have Andy Richman. Andy is with ParkMyCloud, and Andy, welcome to DevOps Chat.

    Andy Richman: Thank you, Alan. Looking forward to this.

    Shimel: Okay, and you know what, Andy, before we introduce Samir, why don’t we just, for anyone who may not be familiar with ParkMyCloud, why don’t you give us a little background on what your role is there?

    Richman: Sure. So, I’m the Product Manager over here at ParkMyCloud, and I think about all things automation and saving money in the cloud. The way we describe it is cost optimization. We launched the company in September, 2015, so we’ve been around just over a couple of years now, and we work with all manner of companies, from large Fortune 500 type companies, right, all the way through to smaller startups born in the cloud, and we’re helping all of those people effectively manage their infrastructure and get the most bang for the buck out of it.

    Shimel: Excellent. Okay, we’ll come back to you in a second, Andy, but first let us introduce Samir Mehra—and I messed that up Samir, I apologize. Why don’t you correct me?

    Samir Mehra: It’s Samir Mehra.

    Shimel: Oh, I wasn’t too bad, then. And Samir, why don’t you tell us your company and background

    Mehra: Yeah, so I’m Director of Product Management here at CloudHealth Technologies. CloudHealth Technologies is a SaaS platform that provides visibility into all your cloud environments, so customers can really look at areas for optimization, and this can include cost, usage, configuration, security, and performance. And then we also have ways that you can automatically remediate some of these optimizations with our policy engine.

    Shimel: Got it. So, Andy, Samir—not to boil it down to dollars and cents, but let’s boil it down to dollars and cents. Is cost sort of the biggest factor in what companies are looking at in terms of managing their cloud infrastructure? I mean, you guys do similar but different tasks for organizations using cloud. What’s your opinion? Is cost the number one priority there? Andy, let’s go with you first.

    Richman: Sure. So, it depend where you are in terms of your company’s cloud evolution. So, if you’re moving from an on prem data center type operation into the cloud, then no, it probably isn’t. You’re thinking about migration, getting workloads moved over, you know, getting performance in the cloud.

    Once you’re in the cloud, you know, obviously, you’re looking to optimize the performance, you know, you’re probably looking to scale up what you’re doing there. And again, cost is moving up, but it probably isn’t number one or number two. But once you’ve been in the cloud for a couple of years and, you know, month on month, you’ve seen those cloud bills climbing, then typically, yeah, it begins to get a lot of attention. And, for most of the companies we’re working with, they’re all at different stages, but probably the majority are pretty focused, and it probably is in that top three, top five for the company.

    Shimel: Excellent. Samir, how about you?

    Mehra: So, I look at it in a different way. It depends on what type of company you are. If you’re a born in the cloud company, you know about how cloud is supposed to be managed. I think cost is not the important thing, it’s the efficiency with which you want to execute things and how quickly you want to get up with your production infrastructure or your test dev infrastructure. And really, I think those companies are very apt at managing some of their costs and making sure their cost is optimized, because they only have been dealing with opex.

    But, when it comes to enterprise companies, I feel some of them, even though they’ve migrated a bunch to the cloud, they still think of cloud as something which is capex. They generally overprovision when they don’t need to overprovision. You know, cost is secondary for them, too, but they have so much of extra spend in what you call cloud sprawl that they really need somebody to help them visualize it and give them ways to optimize that cost.

    Shimel: Yep. So, you know, I always like to say that the costs are almost symptomatic of something else, though, right? Especially when we talk about things like cloud, guys. You know, the costs are relatively set. You can look up on a price chart and see, you know, what a gigabit of storage is, how much CPU time costs or what have you.

    I think when we talk about the cost of cloud and stuff like that, really, the underlying thing is a question of control. Do we really have insight into what we’re using and how we’re using it, right? And, because we don’t, it translates into a cost we may not understand or expect or even know what the heck’s going on. But really, the underlying issue is control and more management of what this is.

    And both of your organizations kind of play a role in that. Why don’t you—and not to create a knock-down, drag out, but can you give me a contrast, Samir, let’s say, in what your company does versus what Andy and the folks over at ParkMyCloud do?

    Mehra: So, I’ll start with the fact that, you know, from what we’ve seen our customers spend, IAS and virtual machines or EC2 instances are really still the biggest spend. People haven’t really transitioned into a lot of TAS services, though TAS services definitely are picking up.

    The way we do it is, you know, to help prevent cloud sprawl, we do have a policy engine where you can set up a policy which tells you if there’s an instances that is started that is more expensive than what you want an individual to set up. So, if they go spin up a really huge instances, you can get alerted, you can actually set up a policy which turns that instance down, even before it gets to run. And the other thing is, you know, the way we prevent sprawl also is, we give you—we, again, use a policy engine and tell you, “You know what? There’s somebody who spun up an instance,” and they have them tag those instances. So, there’s no way to know who’s actually spun that instance up, and if you don’t know who spun that up, you can actually now go and ask them, “Why did you spin it up, and what’s the purpose of this instance?” if it is an expensive instance that they’ve spun up.

    So, we definitely rely on our policy engine a lot, on making sure we have these governance policies implemented to help prevent cloud sprawl from the beginning.

    Shimel: Excellent. Andy, your take on it?

    Richman: Yeah, sure, so we do have a slightly different viewpoint on this. So, when that cloud bill drops in at the end of the month, typically about 70 percent of it is being spent on compute, just as Samir said. If you actually look within that compute, what you’ll quickly discover is, about half of it is for production systems—these are things that typically need to run 24/7—but the other half is your dev, test, QA, data analytics type environments. And there’s at least the potential to turn those instances off when they’re not being used, and we’re really focused on that half of the infrastructure.

    So, what we do is, we give DevOps, IT Ops, you know, engineers an easier way to get those instances turned off. So, in a week, there’s 168 hours, so if you didn’t know, that’s about 730 hours in a month. And even if your team’s working 60 hours a week, which is a pretty hard working team, it still means you can save 65 percent by just turning things off when they’re not being used.

    And so, what we’ve really focused on is the automation piece of this. So, to ensure that when things aren’t being used and there’s no value being added, they’re just simply turned off. And we have semi-similar kind of policy engines that automate this, but an ability, effectively, to create a simple schedule, have it applied across your various different teams, and throwing off some pretty significant savings pretty quickly.

    Shimel: Got it. So, automation is something that, in DevOps, we understand very well, right? It’s key to what a lot of what DevOps is about. And so, the idea of turning down, shutting off, closing up unused instances, unused resources—I mean, just, it’s a no-brainer, you would think, right?

    But why do you think more people or more organizations aren’t doing that kind of thing? Andy, why don’t you go first, if you’d like?

    Richman: Oh, sure. I mean, some of them are doing it, and they’re writing on scripts, but they tend not to do it in a particularly systematic manner. And when you actually talk to the people—I spend quite a lot of time talking to our customers—a lot of it is because, you know, they don’t want to take away control from the teams who are out there, you know, delivering code, delivering value to the company. And often, they just don’t have the insights in terms of how those various instances, VMs are being utilized. And it really requires buy-in from the teams themselves.

    And so, what we’ve seen in the companies that are doing this well is that they create a lot of buy-in. The thing that people quickly realize is that oftentimes it’s not just about stripping costs out and spending them elsewhere in the enterprise, this is just about efficiency, and that money often will get recycled back into other R&D projects, you know, other things that people wanna be doing.

    So, I think the more progressive organizations get it. I think what they’re able to do with a tool like ours is to do it in a scalable way. So, you’ve got multiple teams, lots of individuals, lots of different workloads. We give them a way to do that very, very quickly, simply. It adds a couple of minutes of work to their week and they can kinda schedule it in place and reap the benefits.

    The other thing that’s awesome is visibility. This may be something that Samir can talk about a bit more. It’s, once you begin to give back the DevOps teams, you know, the actual visibility on the savings they’re getting, it becomes a kind of a, somewhat of a self-fulfilling prophecy or a kinda closed loop. They see the savings they’re getting, they do more of it; they see more savings, they do more of it—that kind of positive affirmation.

    Mehra: Yeah, actually, we—sorry, go ahead, Alan.

    Shimel: No, no. I was gonna say, Samir, what about you? [Laughter] I’m sorry.

    Mehra: No, that’s fine. So, we’ve seen, we use our product, our DevOps engineers within CloudHealth also use CloudHealth to manage the AWS environment that we have for production for our SaaS environment. And our DevOps engineer is definitely not a financial person, but like Andy said, when he sees those cost savings, his eyes do light up. He’s like, “I can really save this much money if I actually right size some of these instances that are being underutilized.” And he does, he’ll do, over the weekends, or when we can, do a right size of some of our instances to drop our costs down.

    So, we actually use our platform ourselves to do it, and our DevOp engineers are using it. And we do have plenty of customers doing similar things, and it’s not just right sizing a particular instance. You can also, you know, look at it from an automatic scaling group perspective. You know, you want to right size the automatic scaling group or the next automatic scaling group that you spin up. You want it to be right sized because you’re gonna have a cost savings associated with it.

    Richman: One of the things, Alan, that’s interesting is that people would often quote you the cost of their infrastructure or say, “This is an instance that’s 25 cents now, or 50 cents now” or something like that. What they haven’t done is the mental math—well, okay, what is that gonna mean in a month? And so, a 50 cents an hour instance is actually $365.00 a month. And if you can save 50, 60 percent of that, it’s a significant amount of money, particularly for customers who have tens, hundreds, or even thousands of instances.

    Mehra: Yeah, I completely agree. I think once you multiply the one instance which costs 50 cents into 100 and 200, that’s where you actually see the huge amount of cost savings that you can have.

    Shimel: Excellent. Good. Guys, as I think I mentioned to you when we got on here, time goes really quick, and we only have time for another question or two here, and I want to focus in on a couple of things. Obviously, looking at both of your company services is a great way to get started along this, getting a handle on what you have in the cloud. But if you had to give, let’s say, a top three things that our listeners should do, beyond just signing up—signing up with your company is obvious. But top three things together between the two of you—what would they be?

    Richman: Samir, do you want to go first, or…

    Mehra: Yeah, I would say, make sure you have visibility into your spend so that you can make sure that you’re not spending where you don’t need to spend.

    Shimel: Excellent.

    Mehra: So, cost visibility, for sure.

    Shimel: Andy, how about you?

    Richman: Yeah, so for us, it’s really—you know, focus where the largest amount of potential savings are. And, based on our experience, that’s in your non-production workloads. So, when we focus on that and then start to look, you know, talk to your QA team, talk to your development team, talk to people running analytics workloads, and really understand, you know, how many hours a week those instances truly need to be running. I mean, even if you’re conservative and you only turn things off in the really small hours of the night, the savings really quickly mount up. And then, to really start to do it systematically, kinda team by team and rolling it across, rather than just more of an ad hoc kind of effort.

    Mehra: Yeah, and I can add a third one along with that is, you can also do it on your production infrastructure, and there’s two ways to really do it. One is, you know, right size your production infrastructure and you can do it during a down time where you can right size during a down time, but also look at reservations, because reservations is a huge cost saver compared to running on demand.

    Richman: Yeah, absolutely. I mean, one of the things that we have recently added to the platform and we’re gonna be adding a lot more in the next couple of months is bringing in the utilization data. So, you know, looking at your CPU, your network, your disk usage and really using that to drive these changes.

    We’ve recently introduced these kind of simple heat maps where people can come in, look at the platform, and see the hours when their instances are actually being used. Rather than just asking people when they’re using, you know, what’s being used when, you can actually see the actual usage and, post-Christmas, we’re gonna be moving into the right sizing space in a similar way using similar kinds of metrics.

    So, there’s definitely a lot of tools out there that can help you do this in a more informed way.

    Shimel: Yep. Agreed. Well, guys, we’re just about out of time, here. Samir, Andy—thanks so much for being our guests on this episode of DevOps Chat. You know what I didn’t realize—Andy, for people who want to get more information on ParkMyCloud, is it ParkMyCloud.com?

    Richman: Yep, that would be ParkMyCloud.com.

    Shimel: Yep, and Samir, URL for your company?

    Mehra: Yeah, it’s www.CloudHealthTech.com.

    Shimel: So, that’s Cloud Health Deck, D-E-C-K.

    Mehra: T-E-C-H.

    Shimel: Okay. Got it. Alright, T-E-C-H. We’ll put it in the show notes as well, in case anyone is not clear.

    Andy, Samir, thanks for being our guests. This is Alan Shimel for devopsy.kinsta.cloud, and we’ll see you on another DevOps Chat very soon, everyone. Thanks for listening. Have a great day.

    — Alan Shimel

  • Third Annual DevOps Dozen Winners Announced

    Third Annual DevOps Dozen Winners Announced

    We are very pleased to announce the winners of the third annual DevOps Dozen Awards. In many ways this year was a watershed year for the DevOps Dozen, as the process of selecting, voting and choosing the winners was much more refined and mature. In each of the 12 (it is a dozen, after all) categories the winners were absolutely deserving of the award and recognition.

    Many thanks to our all-star panel of judges: Jayne Groll, Robert Stroud, Helen Beal, George Hulme and Ericka Chickowski. I was the tie-breaker judge and had to cast a vote in just one category. I should also say that almost all of the categories were very tight. Every one of the finalists was deserving of the recognition!

    These awards are a reflection of some of the great work being done in the DevOps community. They are not exhaustive; there are many, many worthy companies, people, projects and products out there. But here is our take on the best of the best in DevOps.

    So, without further ado, here are the 2017 DevOps Dozen winners:

    Best DevOps Open Source Project

    best open source solution Jenkins is the winner of the Best DevOps Open Source Project for 2017. Originally created in 2004 as a fork of “Hudson,”  Jenkins is one of jenkinsthe leading open source automation servers available. Jenkins has an extensible, plugin-based architecture, enabling developers to create 1,400+ plugins to adapt it to a multitude of build, test and deployment technology integrations. In 2017, Jenkins surpassed 155,000 active installations (these are active installations that report usage back to the Jenkins project—only a fraction of total installations), and approximately 1.5 million users, making it the most widely deployed continuous delivery automation server in the world. Learn more: https://jenkins.io/

    Best DevOps Commercial Solution

    devops dozen commercial solution ElectricFlow from ElectricCloud is the winner of the Best DevOps Commercial Solution for 2017. ElectricFlow is an enterprise-grade DevOpselectric cloud release automation platform that simplifies provisioning, build and release of multi-tiered applications. A shared, model-driven approach to managing environments and applications allows teams to coordinate multiple pipelines and releases across hybrid infrastructure in an efficient, predictable and auditable way using the tools and stacks teams already know and love. Learn more: http://electric-cloud.com/products/electricflow/

    Best DevOps Solution Provider Executive


    devopsdozen SP exec
    The winner in this category was actually a 1/1a entry of the CloudBees team of CEO Sacha Labourey and CTO Kohsuke Kawaguchi. Sacha’s Sacha and KK Cloudbeesbackground prior to CloudBees was as CTO and key person at JBoss. KK was a Sun engineer when he first became involved with Hudson and later founded Jenkins. Together, they have built CloudBees into a powerhouse in the DevOps and CI/CD space. While working closely with the Jenkins community, they also have been instrumental in the continued growth and popularity of the Jenkins project. Together, they are a formidable team worthy of this award!

    Best DevOps Solution Provider


    DD best devops solutions provider
    CA Technologies, which now includes Automic, BlazeMeter, Runscope and Veracode, is the winner of the Best DevOps Solution Provider for 2017. From a toolchain perspective, CA Technologies provides the widest array of highly automated solutions necessary to build and optimize integrated workflows across application development, delivery and operations. Spanning the entire application life cycle—including planning, development, testing, release and operations—only CA Technologies offers the full range of capabilities needed to deliver secure, quality applications quickly with an unparalleled customer experience.

    Most Innovative DevOps Solution of the Year

    most innovative devops solutionThe Most Innovative DevOps Solution of the Year 2017 goes to Habitat from Chef, the leader in Continuous Automation. Habitathabitat is a SaaS-based service that provides the fastest way to package apps simply and consistently for deployment and management across flexible cloud-native architectures such as those comprising Docker Swarm, Kubernetes and Cloud Foundry, both on-premises and in-cloud. Habitat gives developers and operations teams complete control over the containerized application life cycle. Learn more: https://www.habitat.sh/

    Best DevOps Evangelist


    devops evangelist
    Derek Weeks VP and DevOps Advocate at Sonatype (co-founder of All Day DevOps) is the Top DevOps Evangelist for 2017. This year All Day DevOps offered 100 free onlinederek weeks sessions led by DevOps practitioners to 33,000 professionals around the world. Since its founding, the community has attracted, educated and supported more than 40,000 DevOps professionals. The conference also brought attention to more than 250 DevOps-related communities, meetup groups and organizations that are helping to educate practitioners around the world. In 2017, Derek delivered 18 DevSecOps-related keynote addresses, conference speeches and meetup presentations in the United States and Europe. He also produced more than 75 DevOps-related blogs over the year, covering topics from continuous delivery to DevSecOps, modern infrastructure and cultural transformations. The blogs not only delivered first-hand experiences, but also highlighted the work of more than 40 DevOps practitioners from different companies around the world.  The blogs can be seen at Sonatype, All Day DevOps, devopsy.kinsta.cloud and Dzone. In addition, Derek championed a number of DevOps reports and surveys in 2017, including the “State of the Software Supply Chain Report” and “2017 DevSecOps Community Survey,” to shed light on industry best practices and areas in need of attention or evolution.

    Best DevOps Transformation


    devops transformation
    CapitalOne was the judges choice for Best DevOps Transformation for 2017. Over the past few years, the 20-year-old financial services giant capital onehas been transforming itself, tapping DevOps to establish a continuous software delivery cycle. Topo Pal, a senior director and senior engineering fellow, told a packed room at the recent DevOps Enterprise Summit in San Francisco the company’s journey suits its entrepreneurial spirit. “We consider ourselves a startup, and like any startup, we have different DNA,” said Pal. “For instance, we build our own software.” All the better for adopting DevOps. The company does just about everything (including back-end processing) in the public cloud now, with a focus on building microservices using open source technologies. Having spent the previous three years building out automation steps, scaling DevOps, adopting open source and cloud and starting to measure its success, Capital One is now turning its attention to continuous delivery. Learn more:

    Best DevOps Transformation Leader


    devops transformation leader
    Paula Thrasher is the winner of the Best DevOps Transformation Leader for 2017. Paula is Director of Digital Services at CSRA Inc. Paula paula thrasher Thrasher has 20+ years experience in IT and has spent the last 15 years trying to implement Agile culture in the federal government. Her first Agile project was in 2001; since then, she has led more than 15 programs and projects as an Agile developer, technical lead, Scrum master or Agile coach. Her teams have helped two federal agencies migrate applications to Amazon AWS GovCloud and done some other amazing DevOps ninja work along the way. Paula is also the executive lead for CSRA’s corporate giving group’s search for a STEM charity and joined forces with Girls Who Code to bring summer programs and after-school clubs focused on closing the gender gap in IT. She also participated in the DevOps Forum 2017, co-authored a paper on DevOps learning in organizations,”Continual Learning: Building a DevOps inspired Career Track,” and peer reviewed other paper topics produced by the forum this year. Paula has spoken publicly at multiple industry conferences including AllDayDevOps  2017, Red Hat Government Symposium and DevOps Enterprise Summit 2017.

    Best New DevOps Solution Company

    nClouds is a provider of DevOps and cloud services, products, and solutions, specializing in modern infrastructures on AWS — and winner of Best New DevOps Solutions Company for 2017. They work as an extension of their customers’ teams to build and manage modern infrastructure solutions that deliver innovation faster. nClouds is a certified AWS Advanced Consulting Partner with 250+ DevOps AWS implementations, 500+ deployed pipelines, and 10,000+ managed servers. They call their new SaaS offering, nOps, modern change management at the speed of DevOps. nClouds was named to CIOReview “20 Most Promising DevOps Solution Providers – 2017” and “20 Most Promising IT Service Management Providers – 2017”.

    Best DevOps Book/eBook

    best DevOps“The DevOps Adoption Playbook” by Sanjeev Sharma of IBM won the Best DevOps Book Award for 2017. The book lays out a clear “how-to” devops adoption playbookfor DevOps, including topics such as value stream mapping, how to lead the transformation of culture and scaling DevOps to the enterprise. As Sanjeev himself says, the book started from a Powerpoint deck of best practices he created to take in everything he had learned.

    This book represents the culmination of years of learning by not only Sanjeev, but by IBM in general, and includes some of the leading names in DevOps that he learned from during this time. Sanjeev also stays true to the “playbook” paradigm, making references to cricket, soccer and other sports throughout. It is a good read and well-organized. To learn more, listen to this DevOps Chat: ‘The DevOps Adoption Playbook’ by Sanjeev Sharma.

    Best DevOps Presentation of the Year

    devops presentation“DevOps: The New Reality for Enterprise Transformation,” a 45-minute keynote presentation at IBM InterConnect 2017, is the winner of the Best DevOps Presentation for 2017. It features Gene Kim, John Comas, NBCUniversal and IBM execs and  distinguished engineers including David Lindquist, Angel Diaz, CJ Paul and Michael Elder. Are you dabbling in DevOps? Maybe you’ve run a great pilot project or have a terrific two-pizza team that’s innovating new apps. How do you scale their success to your whole organization? The answer lies with a combination of cultural, personal and technical transformations that blend methodologies and cloud-native approaches with proven automation patterns and existing on-prem development. The presentation includes client stories and demonstrations of the latest IBM solutions to help companies transform their teams and build, deploy and manage their apps for large-scale enterprise IT environments.

    Best devopsy.kinsta.cloud Article of the Year

    “Continuous Integration vs. Delivery vs. Deployment: What’s the Difference?” by Chris Tozzi won the Best devopsy.kinsta.cloud Article of the Year devopsy.kinsta.cloud articleAward for 2017. Christopher Tozzi has covered technology and business news for nearly a decade, specializing in open source, containers, big data, networking and security. He is currently Senior Editor and DevOps Analyst with Fixate.io and Sweetcode.io.

    Again congratulations to the winners—well-deserved recognition for all of your efforts.

    For those interested in next year’s DevOps Dozen, information will be out in July or August of this year.

    — Alan Shimel

  • DevOps Chat: IBM’s Cloud Private with Mike Kaczmarski, CTO DevOps and Service Management

    DevOps Chat: IBM’s Cloud Private with Mike Kaczmarski, CTO DevOps and Service Management

    In this DevOps Chat we discuss IBM’s Cloud Private. Cloud Private is the new offering from IBM that encompasses much of the different cloud offerings the company has developed over the years. Our guest on this DevOps Chat is Michael Kaczmarksi, an IBM Fellow and CTO of DevOps and Service Management. In his distinguished career at IBM, he has obviously seen technologies come and go. Michael gives us an inside look at IBM’s Cloud Private offering and how it relates to DevOps, service management, hybrid cloud and so many other contemporary technologies in the market today.

    As usual the streaming audio of our discussion follows immediately below. Below that is the transcript of our conversation to follow along.

    Alan Shimel: Hey, everyone, it’s Alan Shimel, devopsy.kinsta.cloud, and you’re listening to another DevOps Chat. We’ve got a very interesting chat lined up for today, with a great guest. Let me introduce him. We have today Mr. Mike Kaczmarski of IBM. Mike, welcome to DevOps Chat.

    Mike Kaczmarski: Thank you, Alan. Glad to be here.

    Shimel: So, Mike, you have a CV résumé full of accomplishments, and I don’t mean to embarrass you, but why don’t you just share with our audience kinda what you’re doing now with IBM and a little bit of your background?

    Kaczmarski: Alright, I’d be glad to. Well, my title is IBM Fellow, CTO of DevOps and Service Management, in a unit inside IBM called Hybrid Management—Hybrid Cloud Management. I’ve been with IBM—well, in February, it’ll be 35 years.

    Did a lot of work in the storage portfolio—a lot of the Spectrum products, Spectrum Protects, Spectrum Control. I came into a business unit that was called Tivoli at the time, became very familiar with all of the service and systems management products, and then into products like Maximo and others that we acquired or built out organically. And then became involved in a lot of the cloud technology—IBM Cloud and now I’m working very hard on DevOps technology and service management technology in a new offering that we have out called IBM Cloud Private.

    Shimel: Excellent. Excellent, excellent, excellent. And we’re gonna try to get to as many of these as we can, Mike. But in order to do that, I think we need to lay down a little sort of baseline, if you will. And how I wanted to do it was, you know, let’s talk about really what I think is one of the primary drivers behind the whole hybrid cloud transition that we see, and that is that traditional applications—you know, everyone would just like to move everything to the cloud, perhaps, make it easy, and be done. But that’s not the way the world works, right?

    Kaczmarski: [Laughter] Right.

    Shimel: You know, customers are beginning that migration, but that migration will probably take—Mike, you said you were with IBM 35 years. I’ve been around awhile myself. We’ll be long gone by the time that migration is over, I suspect. [Laughter]

    You know, so in the meantime, customers are faced with sort of this hybrid period where, you know, some of the applications and some of the application infrastructure may still be on-prem, may still be maybe a private cloud on-prem, maybe on a public cloud, maybe on a private cloud in a data center. You know, truly, a multi-cloud and hybrid environment. Is that what you’re seeing at IBM?

    Kaczmarski: Certainly what I’m seeing. If you consider things like the importance of customer data, data sovereignty, customers’ concerns over security, proper connectivity—all those need to be addressed, and customers’ businesses are running on their IT, and they’re comfortable at different stages with different aspects of those things being on the cloud, whether public or dedicated, and you often find something, like private cloud is a wonderful way to get started on understanding what operational architecture programming changes and even organizational changes they need to make to best start to utilize the cloud. Whether they take all those capabilities to public or dedicated cloud or not, the private cloud helps them.

    Shimel: No doubt about it. And so, Mike, when we talk about—you know, they may be IBM customers. But when we talk about organizations transforming their traditional—and by traditional, I mean non-cloud, they’re not cloud native apps—and trying to migrate them to the cloud. You know, I think you highlighted some of the things that we run into, but anything else that I think listeners may be interested in or at least gotchas that they should be looking for in transforming these apps and trying to move them to the cloud?

    Kaczmarski: Yeah. Well, I think there’s three patterns that we see pervasively. The ones you hear a lot about are those customers who are building out new cloud services, new cloud native programming models, and extending their business into the cloud using some of these new microservice-oriented programming models—polyglot technologies—and perhaps connecting them to their enterprise from the cloud; hence, the hybrid sense through APIs and API management so they can take advantage of their back office systems and the data and expose other application pieces on the cloud.

    There’s a few other patterns. We see customers who have applications that would fairly easily be optimized by cloud technology, such as container technologies for rapid deployment, rapid scale out, resiliency. There are applications that can be, we call it, lifted and shifted fairly easily. And then there’s a whole area of applications that are built out in monolithic fashion that have very tight interdependencies that have been around for years and years, and customers are making decisions on what they do with those applications, and it kinda depends on how much those applications are changing, how critical they are to the business—I don’t wanna touch it, it’s not changed in years, it’s doing its job. That might be some of their criteria. In other hands, parts of those applications might be changing fairly rapidly. And if that’s the case, then they start looking at refactoring or factoring out the portion of application code that is changing fairly rapidly into, say, microservices and placing those in the cloud.

    So, I think there’s a number of approaches that they’re taking, and obviously, it’s a business issue. What makes sense for me to refactor? What am I gonna gain by the refactoring of these applications and putting them in the cloud? How am I gonna lower operational costs? How is DevOps gonna help me, and what kind of return am I gonna get from that versus continuing to do what I do or even leaving some of my monolithic applications alone?

    So, I think, you know, there’s a broad range of considerations that customers have when they look at moving their applications to the cloud, and hopefully I’ve kind of listed a few, there.

    Shimel: Absolutely. So, Mike, you know, this is all—it’s all happening, and I think we’ve kinda described it well. But now, so IBM has recently come out with this Cloud Private, as they’re calling it, and you know, frankly, I think there might be a little misunderstanding in the market where, hey, you’re talking about hybrid cloud, but now, why are you doing Cloud Private? Right? Is it private cloud, is it hybrid cloud? Cloud Private—where does that fit in? Can you help clear it up for our listeners?

    Kaczmarski: Yeah, sure. IBM Cloud Private is an on premise cloud offering based on Kubernetes technology, optimized by some of our systems group. It does run and allow you to deploy private clouds, what I’ll call on premise clouds, on Intel, on Power, on zLinux, so you can take advantage of the systems you might already have deployed, but it has full connectivity to any services in—cloud services that are running in the cloud public or dedicated cloud. It’s a way for customers to start to either write new microservices or write new capabilities or refactor, as I mentioned, some of their applications into a cloud that is running on premise, allow them to experiment without concerns of data privacy, data governance, data sovereignty, and allow them to figure out what’s the best approach that they want to take for refactoring their applications or moving them to the cloud.

    It is Kubernetes-based. It’s based on the same technology that runs on our public cloud and what we call the container services. So, much of the workloads that can run in the private cloud if the customer chooses can be transparently moved to the public cloud or a dedicated cloud for them. The Kubernetes technology overall, the Docker containerization—everything’s running in Docker. They’re fairly pervasive in the industry, so it does give the customer a choice. I think it gives them a foundation that they can start with. They can move workloads at their most comfortable, keeping them on-prem, and then they can start to extend those workloads to the public or dedicated clouds as well.

    You know, another big difference with IBM Cloud Private is, we’re moving our middleware, our traditional offerings like the WebSphere and message queue and IIB and DB2 and the data science experience—traditional middleware that customers have running on-prem that they’re writing their applications against are now available in IBM Cloud Private in containerized versions, the same service, the same APIs, a lot of the same capabilities. And so, they can actually take advantage of the same middleware that they’ve been running with, now containerized in clouds so that they can take advantage of simpler deployment, AB deployment, a simpler upgrade, resiliency, scale out, and so on.

    So, that’s what I think we bring to the Cloud Private arena is the ability for customers to leverage the investment they have in our middleware and middleware services now in a cloud deliverable. And that also makes it easier for them to move their applications into a cloud architecture, whether it’s on-prem in Cloud Private or in public in IBM cloud or a dedicated cloud, an IBM cloud.

    Shimel: You know what, Mike, that was fantastic, and it kinda made a lightbulb go off for me, here. What really, what Cloud Private is offering customers, or anyone—you know, eventually, I guess, their customers—but it’s portability. It is giving you a cloud ready infrastructure, whether that cloud be on prem, at an IBM data center, maybe in a public private type of situation, hybrid situation or not. And not only is it allowing that infrastructure through containers and Kubernetes to be portable like that, you’re now portable-izing, if that’s a word, [Laughter] that whole layer of middleware that so many have been using for so long—

    Kaczmarski: Yeah.

    Shimel: – and making that also portable to whatever or however and in what combination you want to post your applications going forward.

    Kaczmarski: Yes, that’s sort of a—

    Shimel: And that’s really powerful.

    Kaczmarski: – yeah, that’s a good description, yes.

    Shimel: Yep. And, you know, I think, you know, Mike, it really goes to the heart of what we’re seeing in technology today, which is the—and a lot of it is via Kubernetes; well, microservices and containerization, let’s call it that.

    Kaczmarski: Yes.

    Shimel: It’s fundamentally shifting the IT infrastructure or the preferred IT infrastructure in a way that we haven’t seen maybe since when we moved from client server, or maybe when virtualization and hypervisors first became sort of dominant or started really asserting influence in the market. This is really a shift of that magnitude. Do you agree?

    Kaczmarski: Yes, I do, and actually, those are two perfect storms that kinda come together, the virtualization and the client server. I think containerization is an interesting supporting feature of microservices. It really allows a full stack deployment, and actually changes some of the roles and responsibilities of what developers have traditionally done.

    Shimel: Absolutely on that. So, this is DevOps Chat, though. Let’s talk a little bit about DevOps. I always like to tell people that—hey, DevOps is an umbrella term today. It’s more than just the breaking down of the silos between dev and ops, and there’s obviously a cultural aspect to it. But, you know, the thing about DevOps is, it’s about how things get done today. And so, when we talk about things like microservices and containerization and cloud, right, I don’t know if DevOps is a byproduct of those things or if DevOps is a precursor or an accelerator to those things, but they seem intrinsically linked.

    Kaczmarski: Yes.

    Shimel: What’s your view on that?

    Kaczmarski: Yeah, I think they are tightly linked. I think DevOps enables the kind of automation you really want to be able to understand how your applications are being developed, are integrated, how they’re performing, whether or not you’re ready to go into production with what you currently have, whether or not you’re really ready to support, operationally, the applications you already have—all of those things, as early in the life cycle as possible.

    And, you know, when you talk about containerization and microservices, as compared to monolithic applications, there’s a lot more moving parts. There’s many more moving parts in a microservice container organization of your code. You know, you have business function decomposed into various different microservices. It’s actually an organizational construct as well as an architectural construct. You have teams around those microservices building them. They all have API contracts with each other on their behavior, and now they’re deploying at different times into what should be a running system that’s providing a service. At every point along that line, you wanna understand. You wanna be able to herd all of these microservice teams that are together building out the application in a consistent way and always know where you stand in terms of the application being built.

    By the way, the same applies to monolithic apps, because they undergo change if they’re interacting with these cloud native apps and microservices. So, you need to be able to automate and make sure nobody breaks the builds, you need to be able to do continuous deployment of the microservices in, say, a test cluster or a cloud where they interact with each other. You want to vary the versions that are out there to understand if the API contracts have been violated. You want to have a real good idea of the performance and scale of the microservices that are out there—and there are so many of them in a traditional application now, manual tasks would never be able to keep up. So, automation through DevOps in terms of build, deploy, the manageability, the testing of the microservices is paramount in being able to scale a true microservice architecture to a product that has reliability and can be easily updated and can actually iterate very quickly to meet customers’ needs.

    Shimel: Absolutely. Mike, let me introduce another term into our term goulash today, and that’s service management, alright? So, service management is something that has certainly been on the IT agenda, right, on the IT menu for longer than the word DevOps has been used, right?

    Kaczmarski: Yes.

    Shimel: Service management is an important piece of it, right? And there’s been somewhat, frankly, of a disconnect on the nexus or connection of DevOps and service management. Are they compatible? Do they work together? Is there a continuum with them?

    What’s your view? I mean, you have both under your portfolio, here. What’s your view on that?

    Kaczmarski: Well, I think that integration of DevOps into Ops, if you will, relative to DevOps I just talked about in terms of automating, you know, build, deployment, test—integration into Ops is more about making sure you can monitor the application, making sure that if there are outages, you have procedures, run books that can quickly bring things back, supporting things like site reliability engineers, understanding who’s going to be notified if there’s a problem with a particular service—all of those kinds of things push back operational characteristics on the DevOps and even the development team.

    You know, as our teams were building out IBM Cloud, a lot of the services in IBM Cloud are managed by, developed by individual squads, so a logging service or a particular database service or whatever we make available in that cloud, there’s a squad behind it. Obviously, they develop it, they go through regular DevOps deployment and testing, they determine when it goes into production a lot of times based on analytics from a lot of the automation that they have.

    When it goes into production, they’re immediately also responsible for the ongoing operation of those services. This is the development team. They’re now responsible for the ongoing operation of those services. Now, they have site reliability engineers as well, but if you take some development teams and make them responsible for the operational characteristics of their services, a lot of interesting things start to happen. You start seeing development not around the application itself, but also around, “Oh, hey, I have some Selenium scripts that I’m gonna use to automatically monitor response time of the application. This needs to get deployed with the code.” “Oh, I have some run books for the SREs or automated scripts that, should certain events show up, will automatically restart or scale out services appropriately.”

    You start seeing operational artifacts as part of the development of the particular microservices or applications that are being built. And of course, as that starts to occur, you start seeing standards for handoff of these kind of artifacts between DevOps and Operations teams so that not only are they deploying application, they’re deploying the management around that application and they’re ready to go when that application goes to production.

    So, I think that’s the biggest cultural change I’m seeing with DevOps going into Ops is really integrating the management capabilities and intelligence into the application and the awareness that now the developer and the DevOps team have in providing what is needed to properly manage the application and operations.

    Shimel: Mike, that was one of the best answers to that particular subject that I’ve heard. Thank you very much for that.

    Unfortunately, Mike, as I told you before we started, the time here goes really, really fast. I promised you we’d be done in 15 minutes and we’re on 20 minutes already, so I know we had a lot of other topics we wanted to cover. Maybe we’ll have you back on at another time and we can do a part two on this, but we’re about out of time right now.

    Thank you so much for being our guest on DevOps Chat today, Mike.

    Kaczmarski: Oh, thank you, Alan, I really enjoyed it.

    Shimel: Not a problem at all, and as I said, I’d love to have you back on here soon, and we can continue the discussion. But before we go, for anyone who wants to get more information on IBM Cloud Private, where can they go?

    Kaczmarski: Well, actually, the easiest thing you can do is Google IBM Cloud Private, and there’s a number of references out there, and tools. There’s cloud reference architectures, developers, communities. If you want to engage with some teaming with IBM on what’s the best way to move some of your applications to the cloud, there’s IBM Cloud Garage, and there’s some wonderful blogs out there where developers will take you through how they actually move some of the applications to the cloud. So, I would just Google IBM Cloud Private, and you should see, in the first two things that come up, some really good references.

    Shimel: Fantastic. Mike Kaczmarski, IBM Fellow and CTO for IBM Private Cloud, DevOps Service Management—thanks so much for being our guest on this episode of DevOps Chat. To everyone listening, hope you enjoyed it, and we’ll see you soon on another DevOps Chat. Have a great day.

    — Alan Shimel

  • 2017 DevOps Dozen Finalists Announced

    2017 DevOps Dozen Finalists Announced

    We are today announcing the 2017 DevOps Dozen finalists. When I first came up with the idea of the DevOps Dozen 3 years ago, I hoped that one day it would grow into an award that really did recognize the best of the best in the maturing DevOps space. In its third year, I am happy to report that the DevOps Dozen has achieved its mission. This year our categories, the votes, the process and the judges are all aligned to bring you what we think is the strongest DevOps Dozen finalists ever.

    We had to go through thousands of votes, many of them write-ins to pick out the six finalists in each category. It was not an easy task as we couldn’t automate it, we had to do it by hand. We opened nominations back in early October. Many thanks to the team here at devopsy.kinsta.cloud for going through them all. We have notified the finalists in each category and they are submitting information which we will pass onto our panel of judges, who will pick the winner in each of the 12 categories (it is the DevOps DOZEN). We will announce the winners in early January, so stay tuned.

    Before I give you the lists of finalists though, a quick thank you to our panel of judges who will now pick the winners. George Hulme, Ericka Chickowski, Jayne Groll, Helen Beal and Rob Stroud, along with myself will now have the tough job of picking among the best group of finalists we have ever seen. BTW, you can see a much better version of this finalist list by jumping over to the DevOps Dozen site.

    Here are your finalists:

    Category 1 – Best DevOps Open Source Project

    1. Jenkins
    2. Cloud Foundry
    3. Taurus
    4. Artifactory
    5. Open Stack
    6. Docker

    Category 2 – Best DevOps Commercial Solution

    1. CloudBees Jenkins Enterprise
    2. IBM Cloud Garage
    3. CA Automic Release Automation
    4. Datical
    5. XebiaLabs DevOps Platform
    6. Electric Cloud Electric Flow

    Category 3 – Best DevOps Solution Provider Exec

    1. Sacha Labourey/Kohsuke Kawaguchi
    2. Steve Robinson
    3. Jeff Scheaffer
    4. Jennifer Tejada
    5. Rachel Reinitz
    6. Todd DeLaughter
    7. Yoav Landmen

    Category 4 – Best DevOps Solution Provider

    1. CA Technologies
    2. CollabNet
    3. IBM
    4. PagerDuty
    5. Electric Cloud
    6. JFrog

    Category 5 – Most Innovative DevOps Solution of the Year

    1. CA Continuous Delivery Director
    2. CloudBees DevOptics
    3. Chef Habitat
    4. IBM DevOps Insights
    5. Electric Cloud DevOps Insight
    6. Tricentis Tosca

    Category 6 – Top DevOps Evangelist

    1. Brian Dawson, CloudBees
    2. Sanjeev Sharma, IBM
    3. Aruna Ravichandran, CA Technologies
    4. Robert Reeves, Datical
    5. Baruch Sadogursky, JFrog
    6. Derek Weeks, Sonatype

    Category 7 – Best DevOps Transformation

    1. NBC Universal
    2. Lincoln Financial Group
    3. Capital One
    4. Bendigo and Adelaide Bank
    5. Westpac New Zealand

    Category 8 – DevOps Transformation Leader

    1. Brock Beatty, Capital One
    2. John Comas, NBC Universal
    3. Dawie Olivier, Westpac
    4. Alice Raia, Kaiser Permanente
    5. Paula Thrasher, CSRA Inc.
    6. Pauly Comtois, Hearst Business Media

    Category 9 – Best New DevOps Solution Company

    1. ShiftLeft
    2. Harness
    3. LightStep
    4. AppOrbit
    5. Heptio
    6. nClouds

    Category 10 – Best DevOps Book/ebook

    1. A Seat at the Table, Mark Schwartz
    2. DevOps Adoption Playbook, Sanjeev Sharma
    3. DevOps for Digital Leaders, Aruna Ravichandran,‎ Kieran Taylor,‎ Peter Waterhouse
    4. Starting at Scaling DevOps in the Enterprise, Gary Gruver, Jez Humble (Foreword)
    5. The Science Behind DevOps, Nichole Forsgren, Jez Humble, Gene Kim
    6. Making Work Visible, Dominica Degrandis

    Category 11 – Best DevOps Presentation

    1. Next Generation of Continuous Delivery Containers, Robert Stroud, Eric Minick
    2. The 10 Commandments of Continuous Delivery, Viktor Farcic
    3. Is Your Testing a Trick or Treat?  The New Paradigm of Testing in a DevOps World, Adam Auerbach 
    4. DevOps: The New Reality for Enterprise Transformation, Angel Diaz, Gene Kim, John Comas, David Lindquist, CJ Paul
    5. What We Learned from the 2016 State of DevOps Report – Nicole Forsgren and Jez Humble, RSA DevSecOps
    6. What Legacy government organizations need to advance the state of DevOps, Suzette Johnson and Robin Yeman

    Category 12 – Best devopsy.kinsta.cloud Article

    1. Why DevOps Requires a new operating model, Mustafa Kapadia
    2. Continuous Testing: Solving the Biggest Bottle Neck, Aruna Ravichandran
    3. Get the Full DevOps Picture with the CD Map, Scott Wilson
    4. Should You Go Serverless, the pros and cons, Asaf Yigal
    5. 7 Best practices for continuous delivery success, Yani Yehuda
    6. Continuous Integration vs. Delivery vs. Deployment: What’s the Difference? ,Chris Tozzi

    Good luck to all of the finalists!

    Also if you want to be included in next years DevOps Dozen awards you need to subscribe to devopsy.kinsta.cloud and look for announcements next September.

     

    — Alan Shimel