devopsy.kinsta.cloud

Category: Podcasts

  • 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: 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

  • 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

  • DevOps Chat: Chef Habitat Project Continues to Mature

    DevOps Chat: Chef Habitat Project Continues to Mature

    When Chef Habitat was released a little more than two years ago (good devopsy.kinsta.cloud story on Habitat here and a good DevOps Chat on it here), many people in the DevOps community wondered where Chef was going with Habitat. It was a really ambitious vision, but could it meet its lofty goals?

    Habitat is now made up of many different packages that provide different functionalities. There is, of course, much more to Chef Habitat. This DevOps Chat will tell you all about it.

    Joining us on this DevOps Chat are Jaime Winsor, a co-author of Habitat, and Tasha Drew, senior product manager of Habitat, and Blake Irvin of SmartB, a Habitat user. Between the three of them, there is a ton of great information here. If you are interested in Chef Habitat or would like to find out more, this is a great place to start!

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

    Audio: Chef Habitat

    Transcript: Chef Habitat

    [su_pullquote][su_custom_gallery source=”media: 118811″ target=”blank” width=”250″ height=”250″]Blake Irvin
    Blake has spent over a decade working in systems and software engineering automation, on platforms ranging from on-premise metal to containers-as-a-service, BSD and Solaris systems to embedded Linux sensor platforms. He lives and works in Berlin, Germany, where he’s Senior Operations Engineer at smartB, GmbH, an energy-efficiency and sustainability startup.[/su_pullquote]

    Alan Shimel: Hey, everyone, this is Alan Shimel from devopsy.kinsta.cloud here for DevOps Chat, and we’ve got a really great chat lined up for this episode. It is all about Chef Habitat, and we’ve got some really-we actually have three guests on the show today, so we’re gonna move it along to keep it moving.

    Let me first of all introduce my two Chef guests or from Chef. One is Tasha Drew, who’s a Product Manager for Chef Habitat, and one is Jamie Winsor, an engineer with Chef and one of the co-authors of Habitat. Jamie, Tasha-welcome to DevOps Chat.

    Tasha Drew: Thanks so much. Happy to be here.

    Shimel: Thank you.

    Jamie Winsor: Yeah, thanks for having us, man.

    Shimel: Hey, it’s my pleasure. And then, joining Jamie, Tasha, and myself today, all the way from Berlin, is Blake—and I hope I’m not gonna mess this up—Irvin. Blake, are you there?

    Blake Irvin: Yep.

    Shimel: Okay. Thanks. Hey, Blake, I appreciate you taking the time to join us. Blake, you’re with, is it BusyBee, is that what’s the name of the company?

    Irvin: It’s called smartB.

    Shimel: smartB.

    Irvin: Yeah, and the B essentially stands for business, because we are building, because we focus on providing energy efficiency analysis for businesses—small to very large businesses and the buildings that they operate.

    [su_pullquote align=”right”][su_custom_gallery source=”media: 118812,118813″ target=”blank” width=”200″ height=”200″]Tasha Drew
    Tasha Drew is the Product Manager for Habitat. She previously launched Chef Automate’s analytics capabilities, was Head of Product at Rentlytics, was responsible for product for Engine Yard Cloud, and spent several years in various data center endeavors on behalf of Lockheed Martin. Tasha holds an M.S. in Management from RPI and a B.S. in Computer Science from USC. When not in front of a computer, Tasha prefers to be cruising around Napa or at the beach with her dogs—all while having intensely deep thoughts about how to save application developers from tedious rework via the wonders of application automation with Habitat.
    Jamie Winsor
    Jamie Winsor is a lead engineer at Chef Software and the coauthor of Habitat, an open source project built upon distributed system protocol Butterfly to provide a self-healing, self-configuring, stack-agnostic, frictionless abstraction for running applications—regardless of their complexity—to software developers. Jamie has been a software engineer in the video game industry for 10 years, focusing on networked application servers on such titles as League of Legends, Lord of the Rings Online, and Dungeons and Dragons Online. One of Jamie’s responsibilities in his game development tenure was to bring what we today know as DevOps into the daily lives of the other developers on his team, which Jamie accomplished by building, evangelizing, and teaching methods to his peers. He draws on that experience today in building Habitat, as he helps enable all software developers, regardless of their experience, bring their ideas to life without investing in the details of operationalizing an application.[/su_pullquote]

    Shimel: Wow, that’s really good stuff. Jamie and Tasha, you both work for Chef, no need to introduce who Chef is to our DevOps audience, but Blake-welcome. And we have you on today because we’re gonna talk a little bit about Habitat, and Blake, if you don’t mind, I wanted to start with Tasha and Jamie and talk a little bit-just a little background. Maybe we have some folks on here who are not familiar with Habitat.

    So, Jamie, you’re a co-author. Why don’t you take that one, right? What’s Habitat, for people who may not be familiar?

    Winsor: Yeah, sure. So, the Habitat project is a number of pieces of software, and the overall goal is to, I hope, redefine what application automation means by focusing on the application instead of the infrastructure. In the past, we have been building computers in service to host our applications, and what Habitat does instead is it says, “Let’s focus on what the applications are that we need to run our application, what software we need down to a bare minimum, and then provision the machine around it,” and Habitat runs exactly the stuff that you need.

    It does so with a packaging system and a build system and then a process supervisor. The process supervisor runs the packages, the process supervisor communicates to other supervisors using a gossip protocol to share and spread information about what software they’re running, which allows us to enable things for free, just by packaging your software with Habitat, such as service discovery, leader—follower failover, rolling configuration updates, rolling software updates—and it’s all coordinated using the gossip ring.

    Finally, the piece that we built, the last piece of Habitat is simply called Builder, which we can also chat about today, which we just launched about a month ago. And Builder is a hosted Software as a Service build service that’s currently in preview mode. It’s free, and it builds your software that’s packaged with Habitat and hosts it as well in release channels, which allows you to have supervisors subscribe and then receive automatic updates using a complete CI/CD process of promotion between an unstable branch to a stable branch and so on. That’s basically it.

    Shimel: Yeah, no, more than basically-that was a great description and great stuff there, Jamie.

    Tasha, now, Habitat was released as an open source project by Chef, and it’s probably about two years ago now, right?

    Drew: Yeah, yeah.

    Shimel: And so, Tasha, tell us kinda what’s been the latest with Habitat.

    Drew: Sure. So, basically, we have been working nonstop since the initial reveal of Habitat about two years ago, just adding functionality and capability across both that Builder system and that process supervision system that Jamie’s been talking about.

    We’ve also been working on the deployment piece of the overall integration between those two which, in Habitat’s world, is highly agnostic. So, the idea is, use whatever tools you need to deploy those artifacts and supervisors that you’re using with Habitat. And so, we’ve been working with partners to have a really great cloud foundry ecosystem story, Kubernetes ecosystem story, AWS and Azure story, and then Terraform as well.

    So, the idea is, we have been making it easier and easier for people to come get started using Builder, and that’s why we’ve released Builder in free preview mode, it’s because we just want to have this very low friction way for people to get started with Habitat and start rebuilding all of their workloads, and then deploy using your favorite technologies and then start seeing the benefit of the supervisor in Builder, communicating between the two.

    Shimel: Absolutely. And as you mentioned, Builder is in free preview right now. You know, some people look at things like Habitat and some of the other great open source projects Chef is kind of shepherding, and they say, “This is all great, great, great, but how—you know, where does, how do they stay in business? Where do they make money?”

    So, Tasha, can you talk a little bit about sort of where Chef sees commercial opportunity with Habitat?

    Drew: Yeah, absolutely. So, for our enterprise customers, having on prem solutions that integrate with all of our open source products in order to have that really strong control plane management layer is super important. And so that’s, with Chef Automate, something that we continue to invest and see incredible success with.

    And then, with Habitat, Habitat becomes the technology that continues to support enterprises while they want to move fast to deliver applications to production at scale. And so, having this part of the technology suite be adopted by our core set of enterprise customers will continue to be part of our strategy, but then we also have Builder to enable smaller shops to just get started—really low friction point, really easy to use. And how we monetize Builder itself over time will be something that we investigate as we see how people adopt and use the technology.

    Shimel: Excellent answer. Great, Tasha. So, Blake, I didn’t wanna leave you too long in the cold. Let’s bring you into this now. First of all, Blake, I don’t think I asked you, and I don’t know if our audience is savvy to it, but what exactly is your role at smartB?

    Irvin: So, I—we have a team of sort of multidisciplinary, polyglot engineers at smartB. We do all kinds of things because we’re a small shop and a small company, still. But the focus that I have—and this has been my focus and my interest, sort of, for the last, it’s actually been a little bit over 10 years is on all manner of operations engineering.

    So, what I used to do would be something more like traditional systems administration, and now I would say I’m more of a software engineering operations specialist. In other words, I’m focusing on improving and streamlining the process of software engineering and less focused on things like racking servers.

    Shimel: Sounds like you’re doing DevOps to me, man. [Laughter] But Blake-

    Irvin: Yeah, you could say that.

    Shimel: Yep. So, Blake, smartB is using Habitat?

    Irvin: Yeah, that’s true.

    Shimel: Let’s talk about why.

    Irvin: I would say, for the moment, about-sorry?

    Shimel: I was gonna say—why? What are you using it for?

    Irvin: Well, we’re using it for almost everything. We have one—yeah, we have one production service that is not yet what I called Habitized or wrapped up in the Habitat package, and we’re just waiting for some work in the community to be finished before we can do that. But yeah, like, 85, 90 percent of our services are running under Habitat, using the Habitat supervisor, and we’re using as much of that workflow that Jamie and Tasha were describing as we can at the moment.

    And that’s actually been a pretty good process for us, I think, because the way that Habitat’s designed, the adoption process can be incremental. So, when Tasha was referring to giving Habitat users the freedom to pick and choose how they want to deploy or how they want to go about adopting, that’s definitely something we’ve leveraged a lot to make our story good for ourselves.

    Shimel: Got it. And so, Blake, I mean, when did you guys adopt, start with Habitat?

    Irvin: So, when I saw the launch video, which was, I think, Adam speaking in Seattle-Adam Jacob, the Chef CTO. I was sort of, I was watching it originally just out of curiosity and then, as the talk went on, my mouth started hanging open further and further, I think. Not because I thought it was the most groundbreaking thing that I’d ever seen, but more because I couldn’t-I was surprised to see how many of the check boxes that I had in my mind from 10 years ago around this kinda stuff, all this kind of operations work, how many of those check boxes were getting checked off by the project as the architecture and the behavior of the tools was described.

    So, we really started looking at the feasibility of adoption within weeks, I think, of that launch video.

    Shimel: Wow.

    Irvin: And started doing the rollout probably a few months afterwards. So, we’ve been doing it like a very slow, incremental rollout to, you know, ensure that we don’t disrupt any of our current software development process or our current production environments. That’s what’s been going on. It’s been a continual process for, I’d say, like eight months now, but just done very slowly.

    Shimel: Very cool. So, Blake, you know, I have a long history of working in open source-related projects and stuff, and I’m always curious, you know, as a consumer, if you will, or a user of this open source project, have you guys—what have you contributed back? Have you contributed any code, bug findings, suggestions for new features? How are you giving back to the community, here?

    Irvin: Yeah, sure. I think the thing, since we’re a really small team, what we’ve really focused on is trying to use the tool in the way that it’s been designed to be used and then giving feedback to the community and/or to the core maintainers whenever we find bugs or places we want to see improvements, and just keeping that conversation really open and fluid, which has been great. It’s one of the reasons that I’ve continued to use Chef software stuff for—not quite my whole career, but a sizable majority of my career. It’s just that, I think, as an organization, Chef believes that community is very important, and in fact, perhaps, one of the most important things about building a company. And compared to other experiences I’ve had with other open source groups, I think that’s been a real win for everybody involved.

    So, in terms of code contributions, I think mostly what we’ve done is put out a lot of plans, which are the sort of blueprints for packages that Habitat uses when you set up like a set of dependencies for your application. So, we’ve definitely published a lot of those back into the community. I think you can find them if you look on the Builder site under the smartB origin, you’ll see all the packages we’ve published. And we’ve also published some stuff back into the core plan side, just the ones that the Habitat team maintains.

    Shimel: Got it, got it. So, Jamie and Tasha, does Blake and smartB sort of represent the kind of prototypical Habitat user?

    Winsor: I’d say so. You know, with Habitat, you can pick and choose what pieces you want, and it’s been great to watch Blake and smartB grow from—back to the packaging manager and the supervisor and gradually moving toward adopting Builder. They’ve been great to work with in the community. They gave us a lot of great feedback. You know, they’re users, so one of the things that is really important is, you build a feature or you build—you know, you fix a bug, and then you immediately get the feedback from the community, and they’ve been unbelievable to work with.

    I’d say that Habitat would work for any team that ships software, though. So, they’re absolutely a typical user, because they ship software, right?

    Shimel: Mm-hmm. Cool beans. Guys, we’re almost at the end of time, unfortunately, leading up here over 15 minutes. But Tasha, for people who may want to, you know, go explore Habitat themselves, where can they go to get information?

    Drew: Yeah, we would love them to visit our website, Habitat.sh. There, you can see, we have a quick, you know, just kick the tires, 10-minute kinda step-through demo. We have more in-depth tutorials if you want to start just playing around with both the run and build time features of Habitat, and our community is very active on our Slack channel, which you can find a link there to join, but it’s just at Slack.Habitat.sh. So, as you get started, if you wanna just jump in that Slack channel, the entire core team is there, our community is there, and we seek to be super welcoming to new people. New questions are very welcome in the general channel. So, you can just hop in and get support and ask whatever questions you have.

    Shimel: So, it’s Habitat.sh?

    Drew: Yeah, yeah.

    Shimel: Excellent, excellent. Guys, listen. Thank you very—all three of you, Blake Irvin, Jamie Winsor, Tasha Drew—thank you so much for being our guests in this episode of DevOps Chat. Continued success, Blake, with you guys in your bigger business as well as using Habitat, and Jamie and Tasha, with you guys continuing to develop and make Habitat, you know, an indispensable tool for companies around the world. Alright?

    Drew: Thanks so much.

    Winsor: Thank you.

    Shimel: Alright, everyone, have a great day. This is Alan Shimel for DevOps Chat. We’ll hopefully see you soon on the next chat. Until then, take care, everyone.

    — Alan Shimel

  • DevOps Chat: ParkMyCloud Saves Wolfpack App Over 50 Percent on Cloud

    DevOps Chat: ParkMyCloud Saves Wolfpack App Over 50 Percent on Cloud

    In this DevOps Chat, find out how the developers of Wolfpack (wolfpack.run) are saving over 50 percent in cloud costs by using ParkMyCloud’s cloud management platform.

    Though the cloud offers many benefits to app developers and others, controlling the costs can sometimes elude organizations big and small. Cloud sprawl can quickly lead to large cloud bills. In this chat, we speak with Jonathan Chashper, CEO of Wolfpack, about how his company got a handle on the cloud and is spending less than 50 percent of what it was paying before.

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

    Audio

    Transcript

    [su_pullquote align=”right”] [su_custom_gallery source=”media: 118815″ target=”blank” width=”200″ height=”200″]Chris Parlette
    Chris Parlette is the Director of Cloud Solutions at ParkMyCloud. Chris helps customers reduce their cloud waste and manage their hybrid infrastructures by drawing on his years of experience working at various software startups. From SaaS to on-prem, virtualization to cloud, monitoring tools to cloud management platforms, and small businesses to large enterprises, Chris has seen it all and loves helping drive improvements to IT management.[/su_pullquote]

    Alan Shimel: Hey, everyone, it’s Alan Shimel of devopsy.kinsta.cloud, and we’re here for another DevOps Chat. Today’s chat is actually a great behind-the-scenes look at ParkMyCloud and how an app provider named WolfPack is using Park My Cloud to really kinda get a handle on their cloud costs, their cloud usage and optimizing the cloud for their applications.

    That being said, let me introduce you to our guest for today’s podcast. Our first guest is the CEO and founder of WolfPack, and his name is Jonathan Chashper. Jonathan, welcome to DevOps Chat.

    Jonathan Chashper: Thank you, Alan. Thank you for having me.

    Shimel: Thank you. And then our second guest is from ParkMyCloud, it’s Chris Parlette, and Chris, I hope I don’t mess up the title, but it’s director of Cloud Solutions?

    Chris Parlette: Correct, yes. And thanks, Alan, for having us—appreciate being here.

    Shimel: Not a problem. So, guys, this is gonna be a fun one, I think. Jonathan, why don’t you give our audience a little background—what exactly is this WolfPack app?

    Chashper: Sure. So, WolfPack, we are—you can look at us as a connected vehicle technology focusing specifically on helping individuals move together. Think about how much fun it is to move as a group. Imagine you are, you know, maybe several families moving in a few cars. It’s a lot of fun, but there are two major problems—one, keeping everybody together, making sure people don’t get separated, don’t get lost. And the second one is actually communicating with each other while traveling and doing it safely.

    Now imagine you are now doing it on model cycles, which is the first niche we’re focusing on. So, we’re solving those two problems with WolfPack, and by the way, people can take a look at WolfPack.run-R-U-N-to see how it works. But generally, what we do is, we provide, with a turn-by-turn navigation, to every one of the people driving or riding, while providing a radar showing the location of everybody else.

    So, we actually make sure that everybody gets there without being killed, without being lost, without getting into a ditch, and making the experience much less stressful, and much more fun.

    Shimel: And that’s a good thing. But Jonathan, well, you know, WolfPack represents sort of this new—it’s not really new. I’ve seen them now for a couple years, but I call them these instant group type of applications where you can create a group on the fly and that group can have two people or 200 people or more, right? And this group then does something. In the case of WolfPack, you know, they’re on a run or a trip of some sort, and you have Google Maps built into it or underlying it and, you know, all of these things, and they’re great.

    The problem is, as you probably are well aware, is you never know from moment to moment, you know, what your load is gonna be, right? How many groups, how big a group, you know, what’s going on?

    And so, in resource planning, that can be a problem. Talk to me—

    Chashper: Correct.

    Shimel: —yep. Talk to us a little bit about what you’re doing with ParkMyCloud and how that’s helping you.

    Chashper: Mm-hmm. Yeah, so you’re absolutely correct. What you said at the beginning, it’s true. We can—our users can immediately generate groups, it can be, they can generate any number of groups. It can generate—any group can have any number of people. They can plan a ride which can be as short as 10 miles or as long as 1,000 miles, so you’re absolutely right.

    And so, when we’re building the system, obviously, it’s a cloud based system. We are on top of AWS. What’s important for us is that the development costs, being a startup, is being-you know, kept to the minimum. And so, what we did, we actually looked into ParkMyCloud, and with ParkMyCloud, we got to the point that we control our development costs very, very tightly. Generally speaking, when you’re using a server in the cloud, as long as you don’t turn it off, it still works and you’re still being billed for it. And if your development teams go home-say, they work 9 to 7 every day, they go home at 7. If the servers are off, you’re still paying for them.

    So, what we did with ParkMyCloud, we actually manage the up time of those servers, so we only pay for the time we’re actually using those servers for our development for our staging.

    The other good thing we’re having is that we actually have quite good visibility. True—a nice supporting feature, which I think is pretty new, where we can see very, very quickly, you know, when is our load high, what is actually being used, what is not being used, if anything needs to shut down. So, we can manage that very, very easily. And specifically, on the park management, it’s almost a file and forget. Once you set it up once, you never need to go back to it, and it just does it for you.

    Shimel: Got it. So, Jonathan, let me just be clear, I want to make sure we’re talking apples to apples. So, when you say, you know, you’re not using the server overnight or something like that, are you saying that, with ParkMyCloud, you can schedule your instances to close? So, in other words, I’m only gonna use this instance from 9 to 5, and at 5:00, retire that instance, close it out, don’t keep it on my billing account, and when I start up again tomorrow at 9, I’ll start a new instance with that same configuration and kind of pick up where I left off, or is it something else?

    Chashper: So, first, we need to understand that you can use ParkMyCloud on your non-production instances. Production instances obviously need to be up 24/7, so you don’t want to shut them down.

    Shimel: Yeah, you’re right—I should have said that. [Laughter] No one wants to shut down their production.

    Chashper: Yes. So, what I was referring to, I was talking about our development and staging nonproduction systems.

    Shimel: Mm-hmm.

    Chashper: Yeah, so that’s for that.

    Shimel: But are you actually—I guess what I’m asking, are you retiring those instances and firing up new ones the next day, or is it—

    Chashper: Oh, this is—yeah, so this is done automatically for us. That’s the beautiful thing about ParkMyCloud. We actually, once you set up the parking schedule, it will shut down the server, say, 5 p.m. today, and it will turn it on back tomorrow morning, say, 9 a.m. We don’t need to do anything. This is done for us automatically, and so you know, where the developers come back into the office, as far as they’re concerned, nothing changed, they just keep working.

    Shimel: That’s fantastic. Chris, I just want to confirm with you—those instances are actually, you know, it’s sort of like immutable infrastructure, right? Those instances are retired, done, and then re-fired up the next day?

    Parlette: Yeah, so what this is—and it’s not terminating the instances, it’s actually just stopping them and then turning the same ones back on. And the nice thing is about that, is that now, you know, as people are working on these servers, you know, if you haven’t fully gone with data, you know, not being stored on those servers, you know, as you’re working on these same servers over and over and over again, you know, we stop them and then start them right back up again. So, even if people like your finance department or your QA department maybe have some things, you know, spun up, we can actually turn them off to save on the CPU and memory costs, and then we just turn them back on again.

    Shimel: I got it. Okay, because I was gonna say, you know, I mean, the immutable infrastructure angle is great, but in this sort of circumstance, it’s not just a configuration of the server, it was the state of the data that you were working on, and how the heck would you re-create that every morning? [Laughter] But that explains it—got it.

    So, Jonathan, you know, so ParkMyCloud is making you guys a lot more efficient here in the cloud and your use of cloud resources. Have you been able to quantify a percentage savings or anything like that?

    Chashper: Oh, absolutely—most definitely. If I want to be, you know, conservative, I would probably say that we’re saving around 55 [percent]to 60 percent.

    Shimel: Really?

    Chashper: At least. Frankly, I think we probably save close to 70 percent. We’re really very tight. We really manage to do that in a very tight manner.

    Shimel: So, beyond just closing down and firing up the instances the next day, what are some of the other things you’re doing with ParkMyCloud?

    Chashper: Oh, so—well, for us, the first thing is reporting and notification. If something happens, we get notified, we can actually control what we get to be notified about. So, then we’ll get notification about maybe a server that needs to be shut down or something like that.

    Reporting is very important to us so you can see your usage, you can see what is up and what is down.

    Shimel: Got it.

    Chashper: One of the cool things we just started using is actually a mobile app. So, there is a mobile app on iOS for ParkMyCloud. People can download it at the iOS store. And it actually happened with me, I was at dinner, and we—my guys had to stay a little later, and we had to, what we call, snooze one of the parking, you know, schedules, and I just did that through the mobile app, I didn’t even have to go online.

    Shimel: Fantastic. Very cool. So, guys—look, 50 percent or better savings, all these other benefits is certainly nothing to sneeze at. I think anyone would jump at it.

    But, Chris, let’s dive in with you now a little bit, if we can. You know, we have an audience here of DevOps sort of folks from all over the world, right, who would love to save 50 percent on their cloud bill. How is ParkMyCloud working with these DevOps engineers and DevOps teams to realize those kinds of savings and efficiencies.

    Parlette: Sure, yeah. So, we work, you know, plug into a lot of DevOps processes and toolkits straightaway. I mean, that’s something that we do internally, and then, you know, we certainly have all of our customers, from large enterprises down to small startups, all doing this same kind of thing.

    And so, there’s a few different ways to do that. One of the big things about DevOps is automation, and so, we have a full policy engine so you can set up the policies to look at tags, to look at locations to different regions that these servers were in, naming schemes—all these different kind of factors, and you can automatically apply schedules and assign to teams and decide on different actions to take based on these policies for any new instances that you spun up. So, that’s one automated way.

    We also have a full API, so you could plug into DevOps tools like Atlassian, Bamboo or Jenkins so that these tools can kind of reach into our API, temporarily override schedules, change schedules—all this as a part of an automated thing.

    One of the other things about, you know, DevOps—not just automation, but also just thinking whole business, kind of a holistic approach to this thing—and so, we also have a full, a very easy to use UI. So, if your users are, maybe are a little less technical or you don’t want them to necessarily have direct access to a database console or Azure or Google consoles, this can kind of be sort of a proxy for that console so that other users can come in and manage their end servers. They don’t have to ask IT to turn things on for them. They can kinda manage their own servers and do all this, but you can decide who has access to what through this approach.

    So, there’s a couple different ways we plug into these teams and these processes so that users can get their best bang for their buck.

    Shimel: Got it, got it, got it. Now, so, Chris, when you talk about plugging into things like Bamboo or Jenkins, what you’re really—I mean, I just wanna make sure I’m clear. You can build sort of the ParkMyCloud—not sort of, but you can build the ParkMyCloud policies right into your CI/CD pipeline. Is that what you’re saying?

    Parlette: Yes, so if you do things like using tags, especially as instances are spun up or spun down, a lot of people say, you know, “Hey, I put a million tags on every instance.” And so, that’s what the ParkMyCloud policies can read off those tags and kinda decide on the actions based on those tags.

    And then, as far as things like—you know, specifically, if we were to talk about Jenkins or some other build processes, you know, you can have these environments built out and shut down. And then Jenkins, at the beginning of some sort of build process, can call into ParkMyCloud and say, “Hey, I need these servers up, and so I wanna override these schedules.” Spin ’em up, the servers are up, it does all it needs to do, and at the end, it just either shuts them down or, if you don’t shut them down, then basically, if you only did an override, let’s say, for two hours? At the end of the two hours, we’ll revert back to our original schedule, so that way you don’t have to remember to turn the lights out when you leave the room, right? So, we actually can shut things down for you.

    Shimel: Excellent. And Chris, give me an idea of—so, when you guys are engaged, I mean, with that kind of API, with that kind of integration into the DevOps toolset, you’re probably getting a decent view of how DevOps teams are using ParkMyCloud. And you’ve given us some examples, here.

    Are there any—I guess what I’m trying to ask, are there any special things that the DevOps people are doing that perhaps waterfall or other types of technologies are not doing? Is there commonality? Is it very easy to say, “Oh, these guys must be doing DevOps, because here’s, you know, what they’re doing?” Have you noticed any of that?

    Parlette: Yeah.

    Chashper: Alan, before Chris answers, maybe I can jump in and give a quick lead-in to this.

    Parlette: Sure.

    Chashper: Sorry, Chris—hope you don’t mind.

    Parlette: Sure.

    Chashper: Actually, one of the things I wanted to say is that we don’t have DevOps people at all, and one of the reasons we’re using ParkMyCloud is because we’re actually—we’re not DevOps people. We don’t know what needs to be done. We don’t speak, you know, Chef or any one of those guys.

    So—but the fact that we could actually use ParkMyCloud and then the user interface they provided us with, the web client, at least it did for us, went away, and everything is handled at that level. So, for us, that was a big, big move forward.

    Shimel: Yeah, no—and that actually is a great point, Jonathan. And Chris, I’m sorry we hijacked you here for a second.

    Parlette: No problem.

    Shimel: But the problem is, in today’s market, frankly, hiring people who have Chef or Puppet or Jenkins or, you know, DevOps skills sets is (a) hard to find, and (b) very expensive, right? And so, if you can deliver benefits like 50 percent savings on cloud usage or allowing some automation like this, it certainly is a lot easier. I don’t know of any engineering team that wouldn’t like that.

    But, you know, Chris, what do you see? I mean, are most of the people using the UI, or are they just you know, kinda going to APIs and stuff like that?

    Parlette: Yeah, and you know, as we get into larger customers, you know, it definitely is a mix of the UI and the API. The other change that we see, the mindset shift that we see from people is, especially as they’re moving from on-prem to cloud, a lot of people, when they’re used to—a lot of people, when they’re coming from a [Dog barks].

    Shimel: Hey, Jonathan, I think Chris might have shut off there for a second. Chris, you there?

    Parlette: Here we go. I’m back—I’m back. So, one of the things that, you know, as people are moving from on-prem to cloud, you get a lot of people who are used to leaving things on 24/7, because you know, on-prem, as things are left—you know, if you spin things up, it’s not an additional cost, really, to leave them on 24/7.

    And so, in this shift to the cloud, they have this shift of mindset where, if they’re being charged by the hour or it’s something that, you know, every hour that it’s left on is additional cost.

    Chashper: Yeah.

    Parlette: And so, when people are used to leaving things on 24/7, now the shift we have with people using ParkMyCloud, especially in an automated way, is to leave things off 24/7 and then kind of spin them up on demand. And so, that’s really where I think, you know, Jonathan and his team use that a lot, where things can be off, you know, turn on a schedule, but also just turn on on demand so, as the users have access to the UI and the API, they can turn things on on demand, as opposed to having to turn things off on demand.

    Shimel: Fantastic. Well, guys, you know, as I told you off mic, the time here goes really quick. [Laughter] We’ve already been on 18 minutes, beyond the 15 minutes I told you we would do, so we’re gonna need to wrap this one up right here. But first of all, Jonathan Chashper, CEO, Founder of WolfPack, it’s WolfPack.run is the URL, correct?

    Chashper: Yes, absolutely—thank you.

    Shimel: Thank you. Thank you for sharing with us today and giving us a little peek behind the kimono of how you guys are using ParkMyCloud. Continued success for any of our motorcycle riding friends or any group out there who—you know, I encourage you to check WolfPack out, it’s a pretty cool app.

    And Chris, thanks so much for sharing a little bit more, you know, a little behind-the-scenes look and a little bit more of a peek at, you know, ParkMyCloud and how it’s helping companies. Thanks for being on today’s DevOps Chat.

    Parlette: Yeah, Alan. Thanks for having me. I really appreciate it.

    Chashper: Alan—thank you very, very much. It was a pleasure.

    Shimel: Thank you, guys. You know what? We’re recording this right before Thanksgiving—have a happy holiday. Happy holidays to everyone listening! You’re probably listening to this after Thanksgiving, but it’s the start of the holiday season, so happy holidays, everyone.

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

    — Alan Shimel

  • DevOps Chat: Microservices & Containers – Mastering the Replatforming of the IT Infrastructure

    DevOps Chat: Microservices & Containers – Mastering the Replatforming of the IT Infrastructure

    The replatforming of the enterprise IT infrastructure utilizing microservices and containers is no small undertaking and is usually provoked by a shifting set of key business drivers. That is precisely the case today. The term “digital transformation” is in the hearts and minds and on the lips of top-level business executives and IT leaders alike. The underlying traditional or legacy infrastructures that have dominated enterprise IT for nearly 30 years simply cannot handle the workloads or power the applications that will drive business decisively forward.

    Microservices & Containers

    Both microservices and containers are destined to play a major role in this enterprise replatforming, for different reasons. Containers, for their part, hold significant benefits both for developers and the development effort as well as for the organization itself. Understanding this range of benefits is instrumental to securing IT budget for containers going forward.

    In this DevOps Chat, Jim Scott, director, enterprise strategy and architecture at MapR, discusses the most promising and compelling tools, technologies and solutions destined to play a major role in this replatforming of the enterprise. Jim highlights how to stay one clear step ahead as IT undertakes what is arguably its most mission-critical task in a generation.

    You can also download a great ebook on this topic by Jim at here.

    As usual, the streaming audio of our chat is immediately below, with the transcript of our conversation below that.

    Audio

    Transcript

    [su_pullquote align=”right”][su_custom_gallery source=”media: 118809″ target=”blank” width=”300″ height=”300″]Jim Scott
    Jim Scott is Enterprise Strategy & Architecture at MapR Technologies and is very active in the Hadoop community. Jim helped build the Hadoop community in Chicago as cofounder of the Chicago Hadoop Users Group. He has implemented Hadoop at three different companies, supporting a variety of enterprise use cases from managing Points of Interest for mapping applications, to Online Transactional Processing in advertising, as well as full data center monitoring and general data processing. Jim also was the SVP of Information Technology and Operations at SPINS, the leading provider of retail consumer insights, analytics reporting and consulting services for the Natural and Organic Products industry. Additionally, Jim served as Lead Engineer/Architect for Conversant (formerly Dotomi), one of the world’s largest and most diversified digital marketing companies, and also held software architect positions at several companies including Aircell, NAVTEQ, and Dow Chemical. Jim speaks at many industry events around the world on big data technologies and enterprise architecture. When he’s not solving business problems with technology, Jim enjoys cooking, watching-and-quoting movies and spending time with his wife and kids. Jim is on Twitter as @kingmesal.[/su_pullquote]

    Alan Shimel: Hey everyone, this is Alan Shimel devopsy.kinsta.cloud, and we’re here for another DevOps chat. We’ve got a nice chat lined up today. Lucky enough to be joined by Jim Scott of MapR. Jim, welcome to DevOps Chat.

    Jim Scott: Thanks, Alan.

    Shimel: Thanks for having – thanks for being with us today, Jim. So Jim – well, let’s start with this. Our audience may or may not be familiar with MapR, but let’s assume for the moment they’re not. Can you give us a little bit of background about MapR?

    Scott: Sure. So MapR is a converged data platform. The operable words being “data platform.” So MapR provides a data platform for all data. All types of data, all locations, cloud on premise, and it can run in all of those locations simultaneously. The premise of the platform is to deliver a standard open API architecture on top of our data platform, so that customers can reap the benefits of our platform, but not have to worry about being locked in to the vendor, MapR, for the software that we provide through those open APIs, or even the infrastructure that you choose to run on.

    So if you wanna run on your hardware in your own data center, or if you wanna run your software in the cloud or multiple clouds, you can run your software on top of MapR on any of that infrastructure, anywhere you choose, any time.

    Shimel: Great. So Jim – and just for our audience information, what’s your role with MapR?

    Scott: Oh, so for MapR I’m in charge of enterprise architecture, both internally and externally.

    Shimel: Excellent.

    Scott: So what that means is internally, I’m basically lining up and showing how we’re using MapR to solve our own problems, and then externally, it basically means I work with our customers a pretty substantial amount, helping them work through how to be successful with a big data platform. So what is the right way to do something. I’ve personally worked in a large number of different industries, and so my experience comes to the table quite often.

    Shimel: Got it, got it, got it. We got a little vibration there, but I think it went away. And Jim, as we were talking off-mic before we started today, I was telling you I had covered MapR back in Network World when you guys launched, and I’m gonna guess that was around 2008 or so. Correct? 2009, maybe?

    Scott: Yeah, the company went in – or was founded in stealth mode in 2009.

    Shimel: Yep, I remember it. So certainly there’s been a lot of water under the bridge in terms of in 2009, cloud itself was quite the rage. It was relatively new, still, and people were still figuring that out. The whole big data market – there wasn’t a market for big data, frankly. Hadoop and these things had just come out.

    But Jim, probably one of the biggest innovations or changes in infrastructure over the last two or three years, maybe four, has been the big move to containerization of microservices. I would imagine you’re seeing this at MapR as well.

    Scott: Yeah, absolutely. So if we look historically, just say maybe eight, ten years back, message-driven architecture started becoming popular; service-oriented architecture, things of that nature. And that popularity was great – eh, maybe even 15 years back. But the problem was scaling out the messaging platform itself was difficult, it was expensive, and it was really just a pain from an administration perspective, to be able to scale out.

    So we’ve seen this transition over the last handful of years, moving more towards a microservices model. And the term – a lot of people like to throw it around loosely and call something a microservice when it’s not, but the less monolithic in nature, the more difficult to handle the large scale.

    Which is why the Kafka API and what MapR provides with MapR Streams helps enable the customers, because they have the ability to push through massive volumes at a linearly scaling cost model, so they know exactly where they’re going. So it’s pretty easy to push through something like 1.5 trillion events per day on a platform like MapR with as little as five servers.

    And the more micro in nature, the higher the volume you’re going to need to be able to handle. And so those messaging systems of the past – just not there. Just couldn’t handle it. I mean, I remember being excited when we were getting 50,000 to 60,000 messages per second through the system.

    Shimel: For good reason, Jim. You’re talking to someone who was excited when the 386 came out. So yeah, I hear you. But Jim, fundamentally what my – and I just had this discussion, because we actually have a little microservices journal, Microservices Neighborhood, within devopsy.kinsta.cloud. And I was talking to JP Morgenthal, who’s a CTO at DXE, actually, about this just yesterday.

    Fundamentally, fundamentally – and we’re talking about real microservices now, not nonsense, right? But fundamentally, it has such promise to change the way we do development and to change the way our infrastructure runs, right? Especially when you marry it to containers.

    Scott: Yep. Yeah, and I think what you’re alluding to, and this is one of the things that I have the biggest problem with when talking with people about microservices, is the fundamentals are that a microservice is really more about the deployment model than anything else.

    And without a container to be able to put it in and deploy it, it becomes a very difficult and unwieldy thing, even though it’s so small.

    Shimel: Got it. So Jim, you mentioned before you were working on both the internal and external aspects of this. Internally, if you can – let’s not give away any company secrets – but internally, is MapR utilizing your container-based infrastructure with microservices?

    Scott: Uh-huh, absolutely. Yeah, matter of fact, we talk about it pretty regularly. So for our own website, we have implemented customer 360 capabilities. We run our software inside of containers, and we run it currently on one cloud, but we have on-premise hardware, and we will be in the not-too-distant future running multicloud and on-premise all simultaneously. And in order to do that you need a technology like a container to get that type of isolation from your infrastructure.

    Shimel: Yep. An abstract, if you will; an abstraction – I had an interesting conversation, Jim, with I think it was at _____ recently, or another site, another large organization who had totally moved to a containerized infrastructure, and he was talking about what a profound change it was.

    And I asked him about patching containers versus immutable infrastructure, just standing up new ones, replacing the old, rather than actually patching the existing ones. Where are you on that question, if you don’t –

    Scott: Well, I love the concept of being able to go back to my base, default image and be able to run it through my entire devops process, continuous integration process. So I can go patch one instance in my dockerfile, I can test the core out, make sure it’s doing what it’s supposed to, and then I can let all of my downstream builds run, pick up the new container, and run them through their integration tests.

    Shimel: Excellent. So Jim, I don’t know if everyone in our audience understands this whole idea of eating your own dog food, and what it means. But can you maybe give us an example or two of how things you’ve learned by using them internally at MapR have translated into better service, better product, better results for end users?

    So how you’ve taken it out, how you’ve taken certain processes or waves of technology that you use yourself, and translated that into a customer experience.

    Scott: Yeah, so there’s a couple that pop to mind, and number one is actually containers. We only introduced support for containers around the beginning of this year.

    Shimel: Really?

    Scott: But we’ve been using – yeah, it was – I think our press release that we did on it when we officially released support was around February time frame this year. But technically speaking, we have a number of customers who’ve been using containers with MapR for two, three years.

    And little secret here: We use it internally, and have been for two, three years as well. So making sure that we had it fully vetted and very well baked from a support infrastructure perspective was really critical, but getting that out there for customers, really important.

    Because it solves such a major problem with containers, which is you look at something so simple as security, right. If I am responsible for the web server for my company and you are responsible for the financial systems of your company, or of my – or our company, that software in a container has the ability to run on the same server.

    But if they run on the same server and we are utilizing local storage on that server – because you can’t save data inside a container; it blows up. It’s gone when the container dies. So if you save data locally on that server, what happens? Well, suddenly I run these security risks of my web server having access to financial information – probably not a good idea.

    Shimel: No.

    Scott: So we implemented, within our MapR persistent application client container, the ability to talk to MapR from within the docker container. And because MapR offers NFS support, it’s almost invisible and there’s hardly anything to do. And you give it a ticket from your authentication environment, and you’re good to go.

    Whatever’s running inside that container has a user ID, and when it talks to MapR, the data is saved and protected. You don’t have to worry about oh, well, if I’m gonna save data, I’ll save it to the local server. You get rid of that whole problem. It isolates where the data goes, already being protected and highly available, if your server physically dies, just like if your container dies, you don’t care. You don’t have to restore the server to try and get the data off of it.

    Shimel: Got it, got it. That’s 100 percent – that’s the beauty of that whole abstraction layer, if you will.

    Scott: Exactly.

    Shimel: Jim, here’s an interesting question, and I don’t know if you have this info, but I figured I’d ask anyway. We’ve been doing a bunch of surveys about container adoption, and it’s funny, we’ve done several of these surveys now over, let’s say, the last two years, and when we first started, a lot of people had plans of looking at docker and containers.

    Other people, a decent amount of people, had containers in their – they were in the testing dev environment kind of thing, not production. Few had them in production. Then recently, like our most recent surveys, let’s say, over the summer, that number shot up. Probably 40, 50 percent of respondents have containers in production.

    That may be because it’s devopsy.kinsta.cloud, we’re in a devops bubble, and so you get people using this kind of new stuff. But I’m curious, out of the MapR customer base, a gut check if you don’t have the real number, what do you think the percentages are that are using containers in production these days?

    Scott: It’s a pretty big number. I don’t have a hard-and-fast number, but if I just go by the customers that I talk with, I feel like it’s gotta be over 50 percent.

    Shimel: Really? Wow.

    Scott: Yeah. Yeah, we’ve got one extremely advanced customer in Australia, their name is Quantium. And they talk about how they use MapR all the time, and they’ve basically reinvented their entire operating model, and they’ve done it on top of MapR. There’s an enterprise architecture I documented that they talk about periodically; it’s called the zeta architecture.

    They basically use an orchestration layer, they use MapR for persistence, and then they use containers to launch and deploy anything anywhere arbitrarily across their cluster of hardware for their customers. And they turned their entire internal platform to an as-a-service model for internal and external customer consumption.

    Shimel: Got it, excellent, excellent. We’re hearing stories like this all over now, and the interesting thing is it’s almost wherever you see containers, you’re seeing microservices. But you’re also seeing microservices in places where you don’t necessarily also see containers.

    And it reminds me of when I was in school, we used to learn all pasta is macaroni, but not all macaroni is pasta, or something to that effect. But microservices has a place outside of containers, though they seem to just go really well together.

    Scott: Yeah, absolutely, and I think when you start looking at the different types of use cases that you would fit into a microservice, this is where you start seeing how people are going to choose to deploy and manage. If you’re looking at event-driven, message-driven, where it’s taking a message in, it’s doing some work and it’s dropping a message back out, versus it’s a restful service endpoint, where it’s a synchronous response.

    Yeah, people are choosing to do things in different ways, but nearly – everyone that I talked to, they’re using containers in some fashion.

    Shimel: Yep, yep. It’s true in my case too, but like I said, I always figure well, I’m in a bubble, so of course I’m gonna see that. Jim, what’s next for MapR?

    Scott: Oh, that’s an in intriguing question. Recently, we announced our 6.0 launch, and we have greatly enhanced a number of features around our database capabilities. I seem to have this conversation a lot with people, is they start looking at big data technologies, and they say well, this is great and all, but I’ve built this software to work with mySQL or Postgresql or Oracle or whatever RDBMS.

    So that’s fine, you can containerize those applications if you wanna start changing your infrastructure and how you orchestrate your software, and if it’s important enough to you, you could migrate it over onto a no SQL database like MapRDB document database, or you can just leave it running in a container so you have a more flexible infrastructure.

    And the database technology enhancements that we’ve been making are really critical to kind of driving the future of getting people off of those super-expensive to scale RDBMSes that are being used for non-relational purposes.

    Shimel: Excellent. Just time frames – when might we see some more on this stuff?

    Scott: Well, it’s been announced in the last few weeks, and so we’ll start our 6.0 general availability very soon. I forget the exact date. Then we’ll just continue plugging along, adding more new, fantastic features to help enable the customer base.

    Cloud integration with our platform is another really big one, making sure that we can help enable customers to benefit from the concept of cloud neutrality. Cloud providers are never just gonna get together as a consortium and say hey, why don’t we standardize our APIs to the benefit of our customers?

    It just doesn’t happen. It’s not gonna happen. Google, Microsoft, and Amazon are never just gonna call each other up and say hey, what do you think about this?

    Shimel: I agree. Agreed. Well, not – you know what – well, I was just, I’ve seen a lot of changes over the years, but that’s probably a pretty safe bet, Jim.

    Scott: Yeah.

    Shimel: Unfortunately. Anyway, Jim, believe it or not, as I told you when we started, the time goes really quick, and we’re about out of time for this version of DevOps Chat. But we’d like to maybe have you back on in the future. We’d love to keep up with what’s happening with MapR, especially as it relates to microservices and containers and some of the new stuff we have going on.

    Jim Scott: Yeah, sounds great.

    Shimel: Great. But in the meantime, if people wanna get more information about MapR, where can they go?

    Scott: Well, I would recommend they go to MapR.com.

    Shimel: Okay.

    Scott: Or of course, you can always follow MapR on Twitter and/or any of the other social networks that you join and work with. But the website is always my favorite, because there’s a lot of great material there, including the MapR blog, and all of the ebooks, including the “Microservices and Containers” ebook that I wrote is out there, for free.

    Shimel: Got it. Got it, got it, got it. All righty, well, we’ll have to maybe get some links to those we’ll put in the show notes of this as well.

    Scott: Yeah, that’d be great.

    Shimel: Fantastic. Hey, Jim, thanks for being our guest on this episode of DevOps Chat. Look forward to having you back soon and finding out more about MapR. Continued success, and keep us posted about what you guys are doing.

    Scott: Thanks, Alan. Appreciate it.

    Shimel: All right. Hey, everyone, this is Alan Shimel for DevOps Chat on devopsy.kinsta.cloud. Thanks for joining us, and we’ll see you soon on another chat. Take care, everyone. Bye-bye.

    — Alan Shimel