devopsy.kinsta.cloud

Tag: podcast

DevOps Chat: Microclimate and IBM Cloud Private with Toby Corbin

IBM Cloud Private has cemented itself in the DevOps space as a personal cloud environment, which is great for developers who need the agility and computing power of the cloud but don’t want to step into a public cloud setting. Tony Corbin, technical lead for the Microclimate Project, describes IBM Cloud Private as “a cloud specifically targeted at individual customer.”

In this DevOps Chat, Corbin and I talk more about IBM Cloud Private and its role in DevOps. As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

Transcript

Alan Shimel: Hey, everyone. It’s Alan Shimel, DevOps Chat, and you’re listening to another DevOps Chat. I happen to be joined today by a first-time guest on a podcast. So this’ll be an experience for him. It’s Mr. Toby Corbin of IBM. Toby, welcome to DevOps Chat.

Toby Corbin: Thanks, Alan. How are you doing?

Shimel: Doing great, and happy to have you on today’s show, Toby. Rather than introduce you to the audience in terms of your title and role and everything, I thought it would be a good icebreaker for you to kind of introduce yourself. So why don’t you kind of share with the audience, if you will, what your title is and what that means and kind of what you do with IBM?

Corbin: Sure. So at the moment I’m Technical Lead for one of the squads in the Microclimate Project. Microclimate is our developing experience, which we’re targeting to help onboard customers and developers into the IBM Cloud Private. So my role and my squad is – we sort of deal with the backbone of Microclimate. So we deal with making sure everything runs smoothly. We add in things like analytics and the sort of analysis application. But we make sure the whole thing sort of runs. So we’re kind of the backbone. So the squad that I lead, we’re the backbone of Microclimate.

Shimel: Excellent. So Toby, this sounds sort of like an Ops role, if you will, right? When we talk about the Microclimate – and you know what? Let’s back up. Some of our audience out here may not even be familiar with IBM’s Cloud Private offering. And I don’t claim to be an expert. I’m going to assume you know much more than I.

Corbin: A little more.

Shimel: Yeah, a little bit. I would hope so, so you’re not collecting your check under false pretenses, correct?

Corbin: [Laughs]. Correct.

Shimel: So Toby, let’s start with that. How would you describe Cloud Private to our audience?

Corbin: So we’ve all heard of public cloud – things like Amazon have a cloud and Google have a cloud and IBM also has their public cloud. And these are quite large deployments. They’re hidden in the ether somewhere, no one knows where they are, and that’s where all the really, really clever analysis goes, and that computing power that IBM can bring. Cloud Private is sort of the onboarding into that. So Cloud Private is a cloud specifically targeted at individual customer. So they won’t be sharing that with anybody else. It will be an instance just for them and they’ll have the very similar applications and things on there that the public cloud would have. The intention being that when our customers are happy using this Cloud Private installation – so they don’t have to have their own machines. They can have the Cloud Private stuff working for them, doing all of their processing. When they’re happy having that working, we can then take them up to the public cloud, where they get even more of IBM’s processing power and they have an even better experience.

So it’s kind of taking them from a private cloud that’s just for them up to the bigger public cloud, where although it’s still for them and they don’t share with other people, they have bigger computing power available to them.

Shimel: Got it. So is it sort of a way station along an upgrade path? Or can someone stay on Private Cloud indefinitely?

Corbin: Oh, you can absolutely stay on Private Cloud. You’re not forced to go up. But obviously as we go up through the clouds, the capabilities IBM can offer you get a lot greater. So that’s why often you’d find that the customers would want to move up to the next level, because there is an even greater amount of processing and a greater amount of options available to them and to their customer deployments.

Shimel: So they grow into it, I guess. So Toby, I was under the impression, and maybe I’m wrong, that in Private Cloud there was also – I thought it was a Kubernetes-based offering. Is that –

Corbin: That is correct, yes. So IBM’s Private Cloud is all based around Kubernetes. It’s IBM’s flavor. So it’s Kubernetes under the covers and IBM have made it sort of into their ICP, their private cloud offering. But it is Kubernetes-based, that’s correct.

Shimel: So it’s containers with Kubernetes and this whole sort of – you know, the _____ _____, obviously, but now we’re starting to see the domination almost of Kubernetes kinds of architectures.

Corbin: Yeah, and that’s how IBM’s helping our customers. So you think of the old way of doing things, you’d have a _____ application that was a huge monolith, a giant application that couldn’t really go anywhere. With IBM’s Private Cloud what we’re looking at is, how can we take these applications, deploy them on the cloud, free up all of the hardware – in a customer’s site they don’t have to worry about those things – and take these large-scale applications and deploy them into a cloud environment? And then it’s not just make them work in a cloud environment. How can we work with customers to actually make them change their applications and sort of rebuild them, if you like? Strip them down, put them back together again, as a microservice opportunity?

And that’s where Microclimate comes in. That’s what we’re doing for the developers. It’s how you create those microservices.

Shimel: Perfect. And of course, Toby – I think a lot of our audiences are familiar with the term “microservices,” and we see microservices being mentioned a lot around Kubernetes, around containers, around DevOps and cloud and so forth. And you anticipated my next question, which was, when we talk about a microclimate, is that sort of the climate in which we do microservices or perform microservices.

Corbin: Yes. Well let’s say for this, yes. Effectively what microclimate is, it’s the environment that we want to give to our developers to go from having absolutely nothing to being able to develop their very first microservice, test it and then deploy it up into production through things like the Jenkins Pipeline and using Travis, and get it running in their cloud, all without actually having to need any prior knowledge. We sort of do this all for you. So in the past there was always ways of being able to create an application and there was always ways of pushing an application into a cloud, but it was several steps, different technologies. You had to rely on the customer having various knowledge themselves. So Microclimate is aimed to make this really seamless. You don’t have to leave your web browser; it’s entirely web-based. But we give you the ways to easily create an application, develop it in the cloud in a web-based editor, test, adding in these performance issues that we’ll talk about in a second, and then when you’re really happy, then get it run in production environments, all with the under-the-covers work being done for you by Microclimates.

Shimel: That’s fantastic. So this whole Microclimate, if you will – excuse me, microenvironment and Microclimate, this is all managed via web browser? All web-based, huh?

Corbin: Exactly. Because this gives you the opportunity that if you are fully running in the cloud, you don’t actually have to have anything on your laptop at all. Everything can be based in your ICP installation. You need nothing on your laptop to run it, which means then you don’t have to have Swift installed or Node installed. But you can still go and create and generate Swift and Node and _____ applications without having anything local to your machine. It frees up your environment to do everything in the cloud, so you’re straightaway using the power of the cloud to do your development.

Shimel: hat’s fantastic. And Toby, it sounds to me, even more than that – you know, so I’m old, right? So I’ve been around for a while. And wen we first saw microservices and containers, to me this was like Heroku – better than Heroku. It was truly moving from infrastructure as a service to platform as a service. So that if you’re a developer and I want to write stuff let’s say in Swift or JS or whatever, I didn’t have to worry about, “Was that installed? What was the infrastructure like? What was going on? Was it installed in the OS level?” I could work directly on my application. Do these sort of Microclimate, microenvironments – is that what this really represents?

Corbin: Absolutely yes. So that’s one of the beauties. Before coming on to work on Microclimate, I was doing Swift developments and Node developments, and I would have to have the latest versions of Swift on my machine and I had to keep up with them to make sure that I would have the latest bug fixes done or whatever it was to make my application run smoothly. With Microclimate, we take care of that whole environment for you. So when you say, “I want to create myself a Swift application,” you get a container running with the latest version of Swift. All of the security patches for that run are already applied. You don’t, as a developer, have to worry about, “Do I have the right installer? Do I have the right version of he compiler?” All taken care of. As a developer you can now just write code and we will do everything else in the background for you, so it really frees up the developer to do their job and not have to worry about keeping their machines up to date with all of the latest patches and run-suns and everything else to do that.

Shimel: That’s pretty nifty. Good stuff right there. So then, Toby, as part of your – you know, you’re a team lead with portal, you had mentioned, and – but you know, but your whole team and what you’re doing – would you say most of the people you’re serving are developers? Or do you kind of correspond with their Ops team, who are still servicing the developers within their organizations?

Corbin: So this is where Microclimate has nicely evolved. We started off s being the developer experience. So we were the developer experience _____. And we were aimed at, how do we nicely onboard the developer from having nothing on their laptop to being able to write their first microservice and deploy it to the cloud? But then we quickly realized that we need to have DevOps. So we brought on a whole DevOps pipeline to the backend of Microclimate. So Microclimate is really _____ _____ as an end-to-end story of two either distinct parts, if you like, but they actually work in one. You start with, “I’m on my laptop, even though I’m running in a cloud environment.” So I’m coding on my laptop and I’m writing my first microservice. And then when I’m happy, I’ll use Microclimate to actually send it to my preconfigured Jenkins Pipeline, and the backend of Microclimate that deals with DevOps will take that and will build you on your Jenkins Pipeline, it will push towards your production and you’ll actually go the full end-to-end now.

So Microclimate is not just really about writing your first piece of code now. It’s taking any application and pushing it right through to deployment at the other end and have it run in production.

Shimel: It’s end-to-end. That’s beautiful, man. That’s really nice. So share with our audience, if you can a little bit, what are the kinds of things that you and your team are actually doing as part of maintaining this environment?

Corbin: So one of the things that we brought – so as I said before, my background in this, I actually came from doing tools monitoring for things like Java and Node. We now bring that to Microclimate. So we can think of things like a performance issue that you would typically see. You know, my CPU is going mad and it’s at 100 percent, or my disk is thrashing or running out of memory. And often it’s very difficult to know why that’s happening or even if it’s supposed to be happening. So what we do, what we bring to Microclimate is, we bring to the table our analysis tooling that we have outside Microclimate. So when you use Microclimate, we actually build in our monitoring stuff. So that means that when you write your very first line of code, we actually start monitoring it straightaway.

So you don’t even have to think about, “Okay, do I have to monitor my application for performance problems?” or, “I’ve got my application written. We normally have a performance team that does this.” We give it all to the developer. Because if a developer can see a problem with a line of code they just put in – for example, they’ve just coded a new function and when they run that function their fan goes mad on their MacBook and it’s thrashing away and they think, “What have I just done?” If we can tell them what they’ve just done at the point they do it, this speeds up development in the future and your testing gets quicker, because you don’t get a performance team two months down the line saying, “Hey, we’ve just run your stuff and it performs like a dog,” and then it comes back to the developer to have to re-find-out what they’ve done. We show you straight away. As you type your code in and hit Run for your first test, we can show you what performance was, so you can see, am I regressing? I can see where my CPU is going mad or I can see where my hard disk is lighting up or I can see where I’m running out of memory.

We build that in for you. So hitting the developer experience right from day one means that hopefully when you get to the end and your application deploys, there’ll be no surprises around, “Well it’s not running anywhere near as well as I thought it would.” So that’s what we bring to Microclimate.

Shimel: Got it. Like you’re the developer’s best friend.

Corbin: We’d like to think so, yes.

Shimel: So Toby, as I mentioned before, I’ve been around the block a little bit. You know, one of the problems with what you’re describing is territorial issues, let’s call them, right? “Hey man, I’m the Ops guy here from my org, and I’ll help my developer, thank you. Don’t be giving away our secrets, telling the developer some of these performance things.” You know, performance kinds of insights. Do you run into having to deal with pre-existing performance teams as part of the Ops at these organizations?

Corbin: Well not so much, because we actually find now is that the sort of dynamic of a team is changing. As we go into this sort of more agile world where each team is intended to be self-directing, we find by having smaller teams with sort of jack of all trades, we get away from this developing, developing, developing, testing, testing, testing situation that we _____ _____ five or ten years ago. And this means that much smaller teams can deliver functionality that’s fit for purpose a lot quicker, because you’re not waiting for a longer test run at the end or other sort of testings that happen that would typically end up in this loop of sort of, “I deliver my code, someone tests it, it comes back to me to make changes, someone tests it and it comes back.” This is a sort of way development has now evolved. So with the agile world, smaller teams can do things a lot faster, and that’s why giving them the tools they need means they can do that.

But this doesn’t mean we put testings out of business, as it were. Because we aim our stuff at the developer, for like the piece of function they’ve just written or for what that application is doing as a whole. There will always be a need for sort of larger-scale teams that need to oversee the entire application. So whereas before, if we take the example of the giant _____ monolith that was one giant application, you might find in today’s environment that that’s actually seven, eight, nine, ten small microservices. So a developer would be working on one microservice and he’d get the performance stats back from that microservice in isolation. But what about the bigger picture? What about when all ten of those are working together? How do you get the overall view of your microservice environment that’s 10, 20, 30 things all talking to each other? So that’s where you still have DevOps teams and other teams working on that. And there’s software for that as well.

So as an example, there’s Prometheus, that’s an open source monitoring solution that’s very good at taking data from different sources. And then what we do with the stuff that we add into the applications at the developer level so that the monitoring solutions we put into Microclimate for the developer, that will actually talk to Prometheus. Which means that if the developer is happy seeing their code running and their single microservice view of the world all looks good – “Yes, my database function is performing as I expect it too.” I’ll now put it into the cloud where there’s 20 other microservices running, all talking. And Prometheus, that sits over and above all of this, can now take the data from each of those 20, and the data they’ll be taking will be the same data that the developer has already been seeing when running it locally or in the small view. We just pass it up through. So this again gives the developer an easy way of seeing – or actually in fact _____ ____, the SysOps guys, what their applications are doing without any additional changes. Because the code has been in there from day one to provide this information.

Now that’s one of the hardest things about monitoring. It’s, how do we get at the data? If you can get at the data, there’s plenty of ways to visualize it. All sorts of fantastic tools, even the simplest of just writing out to the screen. It’s always the case of, how do we get to the information? So we build the information in from day one, and that’s what makes Microclimate so cool, as it were, because it’s just there for you. And no matter what sort of environment you run in, we’ll be able to make the data available to see the performance at any level.

Shimel: You know, Toby, that’s excellent. Hey, when we started – before we started recording I told you, “You’re going to be surprised when I tell you, ‘Hey, we’re going over time.’”

Corbin: [Laughs].

Shimel: So we’re really way over. That was a difficult interview. It was pulling teeth to get you to talk to us.

Corbin: [Laughs]. I’m sorry.

Shimel: No, not a problem. Toby Corbin, IBM’s Microclimate Developer Experience Tribe, thanks for being our guest on DevOps Chat today, and continued success with the Cloud Private team at IBM.

Corbin: Thank you very much for having me on, Alan.

Shimel: My pleasure. This is Alan Shimel. devopsy.kinsta.cloud. You’ve just listened to another DevOps Chat.

— Alan Shimel

November 5, 2018
DevOps Chat: Security in the Cloud with Dome9’s Zolar Alon

Dome9 is in the business of cloud security, so it’s no wonder some of the world’s top companies rely in it to secure their sensitive data and applications in Amazon Web Services, Microsoft Azure and Google Cloud environments. And with last week’s announcement of Check Point’s aquisition of Dome9, an even greater number of users will be able to take advantage of its SaaS solution.

In a recent DevOps Chat, Dome9 co-founder and CEO Zohar Alon spoke with me about what he sees in the cloud security space as many organizations embark on their second generation of public cloud expansion.

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

Transcript

Alan Shimel: Hello, everyone. It’s Alan Shimel, devopsy.kinsta.cloud, Security Boulevard, and we’re here for another DevOps Chat. Today’s DevOps Chat features and old friend of mine from the security world, Zohar Alon, CEO and co-founder of Dome9. Zohar, welcome to DevOps Chat.

Zohar Alon: Alan, great to be here.

Shimel: My pleasure to have you here, my friend. Zohar, let’s get this out of the way first. Some of our listeners are not necessarily from the security world. They’re from the DevOps world. They may not be familiar with Dome9. So let’s first let them know a little bit. You know, you live and breathe it, but tell them who Dome9 is.

Alon: Sure. So Dome9 is a SaaS solution that helps security organizations and some DevOps and development organizations secure their public cloud environments as they grow and prosper from the single cloud to the multi-cloud focusing on AWS, Azure, and Google Cloud platform. A multitude of solutions.

We’ve been in the market from the very beginning covering elements like network security in the cloud which is a bit different, governance and compliance, continuance compliance, and how our customers can tie continuance compliance to their development processes and their build processes and things like identity and access management protection for public cloud that prevent attackers from targeting the developers as the weak link as a vector of attack for compromising the credentials in real time by hacking into their laptops and pigging-backing on their authenticated and trusted sessions to create mayhem and havoc in the public cloud environment of the customer. Just celebrated joining our hundred employee and going strong in both our headquarters in Tel Aviv and Mountain View, California.

Shimel: Absolutely. Very good. So Zohar, and I should mention, look, I know you and Dome9 pretty much from the year you started if not the day you started, right? I think it was an RSA event?

Alon: Yes, yes, 2012, very early on.

Shimel: I was going to say, you know, in a previous – you have a long history in the InfoSec world. Look, the topic for today is really have we seen, you know, the classic, you know, crossing the chasm model of early adopters, early mainstream, late mainstream, laggards, where are we with this in cloud adoption as it relates to cloud security? And at this point are we confident in saying that, look, it’s basically just the laggards at this point who haven’t already at least started their cloud migrations?

Alon: I can say this for certain, that the level – at Dome9 we focus on the top segment of the enterprise customers, let’s say the global 5000 organizations and their cloud deployments; and there’s not a single industry, there’s not a single geography that we are not seeing a race to the cloud, in many cases, multi-cloud deployments very early on. What I’m sensing is that we have a lot of organizations that already completed their kind of version one of public cloud experience that was comprised of some lift and shift and some building of new systems in the cloud. They are now busy architecting their next generation, their second generation of public cloud expansion where elements of making not just the default but actively working to decommission the old infrastructure.

And remember the motivation is you always have a software or a hardware refresh cycle happening somewhere, whether it’s for your switching fabric or for your compute fabric, in your various data centers or you need to upgrade those Windows 2008 and it’s all involves some interesting costs with it. So the drivers are already there. Once you already get the momentum and the velocity and the confidence, it’s something that is inevitable and it actually happens faster and is encouraged by kind of the known technical people, whether it’s the procurement or the finance people that realize that their support to this activity could save the organization actually a lot of money.

We saw that AWS revenue run rate, just AWS is around $40 billion now, and we just saw that the big Cisco revenue run rate is $48 billion. So the reality that we have crossed the chasm and even kind of gotten to the late point. The late majority is already feeling it quite seriously. I can say this for certain with a lot of certainty.

From our perspective at Dome9, we are also seeing organizations already architecting their second generation of what is to deliver continuous security and compliance and governance to their new architectures in the cloud. This is kind of it goes hand in hand. This is where we also see this kind of the maturity in the level of the people that we talk to and their requirements and their understanding that there’s not just a single or few parameters you need to take care of, but if you count them there are about 10 different areas of attention that you need to be very well covered with in order to provide to continue that trend and complete the migrations and sell those data centers as Intuit just did. I think they announced about two months ago that they sold their last data center. I believe we’re going to see a lot more of those announcements. We don’t need to worry. This real estate is not going away. Amazon buys it through Equinox and its partners on the other hand. So it’s not as if we need less compute. We just need a better, more resilient, more focused compute environment.

Shimel: Understood. Couple of things you mentioned in there that I want to bring to up or I’d like to kind of dive a little bit. First of all, yes, I do agree with you, even the late majority has moved to the cloud; but I think one of the things we’ve discovered about cloud migration is no one up and picks their entire – or very few people but some do – up and pick the entire infrastructure en masse over to the cloud, right? It’s a phased sort of migration, if you will. Some faster than others. And I’m talking now for large enterprises. I’m not talking startups. Larger enterprises. How long a migration do you think that usually is?

Alon: Look, so the key is the data. You know, when Amazon announced their Snowball device to lift and shift a couple of petabytes, I think it was three, four years ago at Korean event, people were in shock and like about the thinking of getting the data to AWS is, you know, FedEx is faster than the largest wipe you can find. And then they surprise last year with the full-blown semitrailer that has essentially storage on it that can take essentially any amount of data from your premises to the public cloud. So this is one thing.

Once you get the sense of trust with some data, then trusting the public cloud with your entire dataset is not something that is inconceivable, right? Trust is very binary. If you have it and if it’s good for the backend of my mobile application with the replication of a lot of my banking stuff, for example, then it’s good for everything. Then it’s just the technicalities on how we get there.

Now, I think one example I want to give is that other than data that can there are no barriers, sometimes the database can be a barrier and that’s why you’d see solutions like AWS will sell you migration services to move from your own – they’ll practically give it to you to move from your Oracle to their cloud-based RDS system whether it’s Aurora or whether it’s any of the other SQL versions that they offer as a service. You can say that probably what’s left is the big old mainframes.

I was fortunate enough to see that in real time about a year ago where Vanguard – so essentially after we figured out how to migrate data and databases, the only thing you might say may prohibit us from flying at speeds to the cloud may be an old system of record that sits tucked in in a mainframe computers in some data center at an unknown location. We have been able to see, to experience, and to help also several financial institutions in the process of securing a lot of replication process where they showed how they create using serverless computing and the AWS DynamoDB, a replica of their system of record of their big old mainframe, in the public cloud to provide essentially zero latency backend to their entire application framework. And I’m certain that one of the examples is Vanguard. There’s a very famous video of their heard of architecture describing how they used I think seven steps to create that replica of their mainframe.

It’s an amazing—and this was announced, this was shown a year ago, so you’d probably think that they’ve been working on it for two years before, and this is the reality, that when it started making sense, you know, the technological barriers to live in tandem until you are forced to make a decision about those old systems or those legacy systems is something that any organization should strive for.

And, you know, you don’t need to work hard, you know? Just, your public cloud rep, whether you go with Google Cloud or Azure or AWS, they will help you with providing the perfect architecture and how you’re baking security into it and how you optimize it for cost—they will pull in the partners that will help you on those things to kind of tie them across the board. And the reality is that—and that’s why I can say that, unless there is real slowness and some legislative or some other reason that could prevent an organization from starting its exploration, most of them are already picking it.

And sometimes it’s not advertised. I’m surprised to see, you know, industrial companies that come to us and, you know, I ask them how much is their public cloud spend, and they say, “We just crossed the $10 million-a-year mark.” And that’s a serious business. That means that the current way that things are going, they’re gonna get to ($50 million) or to ($100 million) in the next two years. And this means that you’re not investing in your on-prem systems any more. That’s what I’m seeing in the market.

Shimel: You know, I’m not gonna argue with what you’re seeing. You’re out there talking to people doing it. Zohar, unfortunately, we’re way past our time, but you know what, I’d love to have you back on. I know we had a little bit of a technical glitch; hopefully, it’ll be ironed out where people are listening to.

But let’s continue this discussion. I think it’s fascinating stuff, and I think people are interested to know. And we didn’t even—I really wanted to touch on what does this mean for cloud security? What does it mean for DevSecOps? Let’s do that in part two, if it’s okay with you.

Alon: Absolutely. Looking forward.

Shimel: Okay. Zohar Alon, Founder and CEO of Dome9—thanks for being our guest on DevOps Chat. This is Alan Shimel. You’ve just listened to another DevOps Chat.

— Alan Shimel

October 29, 2018
DevOps Chat: The State of Software Security with Veracode’s Chris Eng

Every year CA Veracode publishes its “State of Software Security” report, chock full of research about how well software is being secured during development and beyond. It’s eye-opening stuff and definitely worth a read for anyone even remotely interested in helping make software more secure.

In this DevOps Chat, Chris Eng, VP of research at Veracode, recently discussed with me this year’s report findings and some takeaways that are worthy of noting.

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

Transcript

Alan Shimel: Hey, everyone, it’s Alan Shimel, devopsy.kinsta.cloud, and you’re listening to another DevOps Chat. Joining us on this episode of DevOps Chat is Chris Eng of Veracode. Now I’m proud to say, actually, that I know Chris, actually, before there even was a Veracode. But – so it goes back a while. Chris, I don’t remember your exact title, but don’t you head up research at Veracode?

Chris Eng: That’s right, yeah. VP of research at Veracode.

Shimel: Yep. Welcome and good to have you back on, Chris.

Eng: Good to be here.

Shimel: Yep. So, Chris, you know, I’m gonna assume, if people wanna know who you are, it’s Chris Eng – E-N-G. You could look him up. He’s a bonafide cybersecurity warrior, with a long track record of accolades and just being a great guy in the community. On top of that, though, I’m gonna assume people know that Veracode, for the last couple years, has been putting out a report called “The State of Software Security.” In fact, this is volume nine, so which assumes there was eight before then, right, Chris?

Eng: That is correct. [Chuckles] We do this every year and it gets bigger and better every year.

Shimel: Yep. So volume nine, you know, it’s CA Technologies Veracode now, of course. Some changes. And, Chris, it’s kind of your baby, right? You shepherd this report every year, no?

Eng: I’ve been involved in it since the first year we did it. I mean, certainly, going back to the early years, there were a lot fewer of us sharing the burden and doing all of the writing ourselves. And now, thankfully, we can spread that out among more people and get more eyes on it. And that’s actually one of the things that we did this year that was kinda different, is, in addition to ourselves, we worked with some data scientists, over at Cyentia Institute, to actually help us dig into some of the things we really wanted to probe, around remediation work and looking at different organization behaviors. And I’ll get into that in a little bit.

Shimel: Absolutely. Chris, before we dive into maybe the specifics of this year, let’s just take a minute and talk about, look, nine years running, my god, how the world has changed in nine years. Right? I was talking to the CIO of Box, Paul Chapman, earlier today, and we were just talking about how the world’s changed, let’s say, in the last 20 years but even in the last 9 years. I mean, what we can – you know, security’s still security, and, unfortunately, we still have incidents; we still have vulnerable software; we still have buggy and have trouble closing up vulnerabilities. But the game has changed, though, too, has it, Chris? When you look back, what do you think that some of the biggest changes are?

Eng: Yeah, it’s definitely undergone a huge evolution. When we started Veracode in 2006, application testing primarily was companies doing penetration tests, maybe once a year, against their most critical applications. And, if anything changed between those, you know, in that one year, you kinda only had a point-in-time assessment. You had a lot of applications, a lot of pieces of software, that were just never being tested at all. And, since then, companies have realized that, number one, they need to test more frequently. That’s the only way that they’re able to release software that is going to be secure and also be able to drive the speed that they want to release new features and new products. Right?

The other, I think, realization is that you can’t just focus on the most critical applications to the business because attackers don’t really care how they get in, right? If they find a weaker way to – an easier way to get in, through some weaker application that’s not maybe core to the business but is still connected to the same infrastructure, well, they’re gonna go after that. So there’s been a realization that it’s important to understand everything that you have and to actually build software testing and security testing into all stages of the life cycle, right? Fix early and it’ll be a lot cheaper than fixing later on.

And, you know, we were looking at some of our stats the other day – this isn’t in the report, but to do the first million application scan for our customers took 10 years; the second million scans took one year.

Shimel: Wow.

Eng: Right? So that huge rate of increase is just showing that, across the board, across all industries, company sizes, organizations are realizing that they have to scale their software security programs to cover all the bases. And they have to do it continuously, in order to not rack up security debt. So I think that would be the biggest thing that’s changed in how we approach the problem.

Shimel: I agree. I agree. But, Chris, really, our time’s limited. Let’s jump into this year’s report. I’ve had a quick look through it, the executive summary and some of the other stuff. Boil it down for our listeners. What do you think are the three biggest kinda metrics or facts that jump out here, that they should be aware of?

Eng: Yeah. Let me give you just a quick –

Shimel: Sure.

Eng: – review on – so, like I said, we do this every year. And we take about 12 months of data, so this is across all of the assessments that we do for all of our customers, and it’s anonymized down, of course, and then we look at trends and try and see what’s going on out there, in terms of application security. This data set is about 700,000 application assessments during a 12-month period, and the one big thing that we’ve been able to do this time that we weren’t able to do in the past is actually look at how long flaws are sticking around once they’re discovered. Right? How long is it taking organizations to fix these flaws?

And so, when we detect something, we’re able to kinda track it across multiple assessments, so let’s say we scan an application today, we find a bunch of flaws, we fix some of them and not others, and then we scan it again in a week. We’re able to identify that certain of those flaws, the ones that we detect the second time, are the same as they were the first time. And so that allows us to actually track the life cycle of each individual flaw until it’s fixed, right? And so we’re able to look at “What does that flaw persistence look like?” Kind of a survivability analysis.

And, if you look overall, just across all the flaws that we look at, the numbers are not great. It takes 21 days on average to close 25 percent of the findings, 121 days to get to the halfway point, and 472 days to get to the 75 percent point. So that’s a long time, right? That’s over a year, so it’s not a very rosy picture overall. And so we broke this down and, you know, once the report is out, people can kind of look at “What does that look like in terms of different severities, different industries? What kind of patterns do we see there?” But I think the most interesting one, and the one that’ll be most interesting to you, is around the effect of DevOps or DevSecOps on fix velocity.

Now we don’t have an easy way of saying, for any given application, “Is this a DevOps shop or not?” Right? We can’t – we don’t have that information, so we have to figure out whether or not we think they are, and the proxy that we’ve been using for that is scan frequency, right? If you’re doing CI/CD, you’ve got your scanning baked into your build process or you’ve got it, some way, baked into your automation. And so, if you’re doing a nightly build, for example, you’re doing a test every night. And so we looked at scan frequency to identify that – you know, we think that probably these applications that are being scanned 300-plus times a year, those are probably DevOps shops, right? And the ones that are scanning one to three times a year, probably not.

And so we’ve got this broken down into buckets. If you have this in front of you, you wanna jump over to page 39 – it’s Figure 43 – and this is what I really want to – this is sort of a – our hypothesis was like, “Yeah, I bet DevOps shops fix faster because they’re scanning more frequently and they don’t wanna rack up as much security debt.” And, in fact, it does show that. Right? We see this one line on the report that says, “Applications that are scanned 300 or more times a year are fixing – they’re getting to the halfway point of fixing in five days and they’re closing 75 percent of flaws within seven days.” Right? So that’s a huge amount better than those averages that I just described to you.

And we have this broken down by bucket, right? So you have the 300-plus scans per year, you have 51 to 299, all the way down to one to three scans per year, where it takes close to four years for them to get to the 75 percent close mark. So I think that’s actually – this is what we hoped to see. This is what we expected to see. But it’s nice to see the data prove out that, in fact, yes, when you scan often, when you scan early and you stay on top of the findings, this is actually a very doable thing, right? To fix flaws in a reasonable time frame.

Shimel: Absolutely. Two things there, Chris. No. 1, I would think hand in hand with the DevOps is automation.

Eng: Yeah.

Shimel: Right? I’m wondering if part of it is that, in DevOps-enabled cultures and organizations, organizational cultures, whatever – companies doing DevOps – are they automating the scan process and that’s why we’re seeing them doing 300-plus scans? Right? And then they’re deploying more and, if their MO, if their standard process is “Nothing gets deployed without first being scanned,” right, that’s where you start racking up 300-plus scans. Right? I mean, when you –

Eng: Oh, yeah. Yeah, we’re –

Shimel: – build that into your pipeline, right, you build that into your CD process, those scans get done.

Eng: Yeah, we’re assuming that these – you know, we’ve gotten – I think, at the maximum point, there’s one app that was scanned over 1,000 times and, certainly, that’s – I mean, I really hope that’s not a human uploading something or pressing –

[Crosstalk]

Shimel: Right, _____ – hitting the “Scan” button –

Eng: – a button every time, right?

Shimel: – every time. You would hope not, right?

Eng: Right. Right. I’m assuming that even the ones that are scanned 50 times a year, right, which I assume to be every week, I assume that those are also –

[Crosstalk]

Shimel: Are still better than once _____ –

Eng: – _____ _____ through a build pipeline. Right? And, any time you can – I mean, and that’s been a big focus for us, just in general, is “How do we remove any human effort required to do the testing? How do you make it easier and more transparent and just remove any barriers to doing that?” And so –

Shimel: No, heck, how do you – you gotta build it into your CI/CD pipeline. I mean, it has to be part of that. The same way you breathe air, right? If you stop breathing, you die; you don’t deploy software that’s not been tested and scanned. And –

Eng: Right. Right.

Shimel: You know, it sounds so simple, us talking about it, Chris, but here’s the fact, right? And not everyone listening to this in our audience has been in security as long as you have or even I have. And a lot of people see the reports, Chris, and they say, “Oh, my God, this is year nine,” and I forgot how many years Verizon is doing their report, and, every year, it’s hard to show progress in some things, right? We do show “Hey, if you scan more, you’re gonna have less vulnerabilities go out the door that aren’t fixed and that were at least – they don’t stay – you know, they get fixed faster.”

Eng: Yeah.

Shimel: But the fact is we’re still seeing – you look at the executive summary here, Chris, and it’s not a rosy picture, as you – I think those were your own words. And we still read about breaches every day and 30 million records here and 20 million here. You know, the non-security person says, “What are we gonna do? When does this fundamentally change?”

Eng: Yeah, I mean, things don’t get solved overnight, right? I mean, if companies have only realized a few years ago that they need to kinda get a handle on all the things that they have and start understanding what their risk posture is, and they’ve got 10, 20, 25 years’ worth of software, thousands of applications, it doesn’t happen overnight; it’s baby steps. Certainly, starting any new greenfield projects with a proper SDLC that’s identifying and fixing issues early is gonna prevent them from building up even more security debt.

But, yeah, a lot of these – the way I explain some of these things – for example, pass rates on OWASP Top 10 not getting a lot better or the prevalence of certain flaw categories, like cross-site scripting and SQL injection, staying relatively constant – is that some of the more mature apps that have been scanned for a while now, those are actually decreasing. If we sliced those separately, we would see the rate going down. But, when we look at it in aggregate, out of those 700,000 applications that are part of this data set, a lot of those are things that are just being scanned for the very first time ever. And so they’re gonna have a higher prevalence of some of these issues, that the more mature applications will have gotten rid of already. Right? And so they kind of balance each other out.

And we see this every time. In fact, we should probably start to report on some of those things separately – it’s kind of a difficult thing to do – but I think what’s happening is some of the newer applications are bringing those numbers up and that’s why we see the lines staying relatively flat. There’s a long way to go, but we do see – you know, and things like the DevOps remediation case I just described. I mean, we see little points of optimism, where you can see a clear correlation between a certain behavior and a certain outcome. And so we like to focus on those things, and, yeah, it’s gonna take a while for most companies to really start to chip away at the legacy applications and getting those locked down.

Shimel: Absolutely. Absolutely. Chris, we’re just about out of time. I should – we should put this out there: for people who are interested in really kinda digging in on the report, where can they get it from? Go to Veracode.com?

Eng: It’ll be on Veracode.com, starting on October 24th, and, yeah, they can download it there. There’s a huge amount in here. We break it down into different flaw categories. We look at different industries against each other. There’s even a little geographic breakdown and then, of course, like I mentioned, a huge amount of data around flaw persistence and how long it takes organizations to fix flaws, which, I mean, ultimately, is what’s important, right? Doesn’t matter how often you scan if you don’t fix stuff. Right? You don’t reduce your risk unless you fix stuff. So there’s a lot of great data on that, that we’ve never been able to report out before, so we’re really happy to get those out there.

Shimel: Absolutely. Well, Chris, you know what? I know I got a little hard on you about the – and it’s not your fault that the security industry – and it’s not the security industry ’cause, God knows, we wanna fix the issues and the problems that cause these breaches and things; it’s really just the state of software and where security lies as a priority in a lot of these organizations and managing their risk and so forth.

But, by the same token, Chris, you know what? First of all, thank you, thank you, thank you, for being involved enough to do this report every year, and, whether the metrics paint a rosy picture or a sad picture, nevertheless, it’s a picture that needs to be told, right? We need this kind of insight; we need the metrics to understand where we are and where we need to be. And so great job, once again, in putting this together. You know, I think it’s as important for non-security people to read these reports as it is for security people. Right? To really –

Eng: Yeah, we hope –

Shimel: To –

Eng: Yeah, we definitely hope people will get something out of it and, hopefully, kind of use that to think about how they are building their own programs, right – how they’re remediating, what do their numbers look like – and, hopefully, kind of informs how different organizations think about scaling up their programs. That’s what we’re hoping, anyway.

Shimel: Good. All right. Chris, let’s call it a wrap on this; it’s a Friday afternoon here. And, again, thanks for your insight on the report. Thanks for managing this report year in, year out and being involved with it and helping. And we’ll see you soon. We’re coming into conference season; I’m sure you’ll be busy presenting and getting more –

Eng: I’m sure, yeah. I’m sure we’ll be bumping into each other pretty soon.

Shimel: Absolutely. Chris Eng, VP of research at CA Technologies Veracode, our guest on this episode of DevOps Chat. This is Alan Shimel, everyone. Have a great day.

— Alan Shimel

October 24, 2018
DevOps Chat: JFrog Expands Platform with Trainologic Acquisition

It’s always great to see companies in the DevOps space grow and expand their breadth of services. JFrog is the latest to fit that description. The company last week announced its acquisition of Trainologic, a Dev and DevOps technology consulting company, to expand its reach by helping new customers start their DevOps journey and supporting existing customers along the way.

In this DevOps Chat, we speak with JFrog CEO and co-founder Shlomi Ben Haim and Gal Marda, founder and CEO of Trainologic, about the acquisition and how Trainologic fits into the JFrog vision of end-to-end continuous updates.

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

Alan Shimel: Hey, everyone, it’s Alan Shimel, devopsy.kinsta.cloud. You’re listening to another DevOps Chat. Today’s DevOps Chat is around some big news coming out of our friends at JFrog, and I’m happy to be joined by my friend, Shlomi Ben Haim, CEO and co-founder of JFrog. Shlomi, welcome.

Shlomi Ben Haim: Hey, Alan. Thank you for having us.

Shimel: Thank you. And joining Shlomi is a new member of the JFrog family, Gal Marda, who is the, I guess, founder and CEO of—or was the founder and CEO of Trainologic, correct?

Gal Marda: Correct. Great to be here. Thanks, Alan.

Shimel: Welcome, and welcome to the JFrog family.

Marda: Thanks a lot. It’s very exciting for me.

Shimel: So, I’m gonna let—Gal, I’m gonna let you tell our audience the big news coming out today. What went down here?

Marda: So, what went down, as Alan said, it’s very exciting, actually. Shlomi had this great idea of JFrog coming out with this platform, the EPlus platform, which is a complete revolution in the DevOps industry, in my opinion, and he thought that DevOps and the vision of liquid software, to make it successful, it’s both tools and practices. And taking out this platform and making sure it’s successful requires some consulting services as well to make sure that JFrog customers are making the right decision on the way they used the Enterprise platform.

So, the idea was to join forces together and bring us on to make sure the customers are being successful with the use of the Enterprise Plus platform.

Shimel: Excellent. So, Shlomi, let me ask you—JFrog as a company has had tremendous success, tremendous growth. Last year, you moved, really, to a platform type of solution in the marketplace, right, offering the platform. Why Trainologic, why now?

Ben Haim: That’s a great question, Alan. So, as you know, and we spoke about it in the past, the real pain that DevOps is here to solve is not about the milestones of continuous integration and continuous deployment and continuous delivery and continuous testing. These are all very important milestones that created and ________ revolution.

But, basically, if we will all have a solution that helps us to get to a place that we have continuous updates, that software is being released fast and secure, then the DevOps evolution would be at the procurement level. What we released this year, the Enterprise Plus, is a bundle of seven different products, and it’s not any more one product that you install and run at the server side, then serve your developers. It’s more than that. It’s an end to end binary solution.

And what we figured out is that we need some experts to help us with the adoption and the know-how and the knowledge transfer among our users. So, we have 4,500 Enterprise customers today. We need Gal’s team to work with us in the field, on customer sites to support that goal.

Shimel: I wholeheartedly agree, Shlomi. You know, I’m reminded of, back in my days at Interliant, where we did early cloud hosting—things like Lotus Notes and PeopleSoft and Oracle applications. And what we discovered then was, you can never take a sophisticated application like that out of a box, plug it in, and say it’s gonna work, right? There was always, at best, 75 percent, it worked. You always needed professional services, 25 percent, to come in, customize it, fine-tune it, make it work.

And, really, that—you know, even in the security space, so many of the most successful security companies, when you look at their revenue breakdown, it was the professional services, because security is hard. And people just can’t do it, and so, to me, anyway, there’s no surprise that this is a DevOps problem as well is that you still need those experts to come in and do it.

My question to you is, though, is that, as a CEO in your position, you’re always—you’re gonna need to balance how many bodies do I want, right? How do we scale this? Because it’s a body intensive, it’s a people intensive business model.

And so, you know, what—and Gal, you may have experience, having led the charge at Trainologic. What do you do there? How do you keep it in check?

Marda: So, I—Shlomi, are you taking this, or me?

Shimel: Either of you.

Ben Haim: Yeah, I’ll speak about the ratio, and Gal, you will speak about the best practices coming from your experience. I think, Alan, you are right. When you come with—it’s not just the technology, it’s not just the new things that are happening in the market. And the DevOps market is booming. You see it from everywhere, from fundraising to technology adoption, new things, innovation, every morning we are waking up to some DevOps news. So, this is a very exciting day for companies like JFrog.

But what you also see is that a lot of companies are starting to onboard giant organizations, thousands of developers to a new methodology and new tools. Therefore, we have to keep the balance between what we release to the market and how it’s being adopted. Because otherwise, we will overwhelm our users with technology that nobody understands how to use, and they will—you know, the first reaction will be a reflex reaction of just dropping it and have this mantra of what works should be, stay as it is. If we want to keep innovation, if we—sorry, to push innovation—if we want to keep the market momentum, then we also have to support the market with the onboarding. This is one thing.

The second thing—JFrog is a product company. JFrog is not a service company. But building the product without helping our customers to better use them is meaningless. It’s just like having a great technology with the wrong execution. So, we are looking up to companies in our field that did this stuff two years ago, three years ago, and how the market adopted their platform. And we learned a lot from it, we did the analysis. So, when we reached out to Trainer Logic and asked Gal to join the team to the swamp, basically, the first thing that we looked at is, is this company already installing ________ Factory and Xray and Bitray and the JFrog pool? Second, is it a big enough team? It’s a TS Super Command Unit, so not too big, and if Gal and the team will be able to build a community, not just with the JFrog professional services, but also with the community of professional service companies around us, and to be some kind of a business development within these units around the world to help us spread the JFrog technology.

Shimel: Excellent. Gal, do you want to add to that?

Marda: Yeah, sure. So, you asked about scaling, so I think Shlomi has it correctly. We are going to be a relatively lean and mean command force. We’re not gonna be like thousands of people, but we’re, we can scale in several ways. One of them is, as Shlomi mentioned, by partnerships, okay? We tend to create a network of partners and a community that will help us work together. We’re not going to deal with it all by ourselves.

And, in terms of scaling inside and taking people and training them, that’s something that we’re very used to doing. We are making sure that young people are shadowing, and we’re grooming them, and we’re teaching them a lot more of our practices, and we’re making sure that they see a lot of different architecture and a lot of different customers with different ways of thinking. And with this kind of activity, they become very experienced in a relatively short time because they see a lot of stuff, and if you take talented people, you give them the right mentoring, you let them see a lot of different solutions and approaches, they become very efficient in a relatively short period of time.

Shimel: Excellent. So, is this, the commando teams going in and stuff, Gal, do you envision them—so, is every job a one-off, or is there a sort of standardized package that you’ll develop for most customers?

Marda: Well, it’s still in the making, but I am—we are planning to create some packages, because during our experience in last year’s meeting, a lot of different companies and providing them with different services, we realize that there are the same needs that are returning again and again.

One of them, for example, would be some kind of DevOps analysis, like a gap analysis of where you should be or where you want to be, and what’s your current DevOps state? So, for sure, there will be different types of packages, and inside those packages, of course, a lot of the work will be tailor made because every company is different, and as you know, DevOps is also very culture related and related to many other things in the company. So, for sure, it can’t be the exact same thing that will be provided, but the general framework in the packages will be, different packages will offer off the shelf.

Shimel: Excellent. So, Shlomi, Gal said the magic word—culture. How does this—you’ve done other acquisitions. You’ve acquired JFrog China, I saw awhile I was in China, I saw them at an event. Some other acquisitions you’ve done over the years. But those were kinda product related companies; this is clearly a service one. How does that—I mean, you have a great culture at JFrog, right? I’ve witnessed it firsthand. It’s admirable. How do you make—

Ben Haim: Thank you.

Shimel: – ________ Froggers in the swamp?

Ben Haim: Well, first of all, thank you, Alan. You know, we acquired four different companies, from Conan with the C++ package manager for DevOps and then CloudMunch, that becomes the JFrog Insight product. And then DMon and now Crenologic, and the one thing, one rule of ________ is the fact that you always, you should always seek for the combination between the strategy and the culture.

And, the first time that I met Gal, under the idea of the acquisition was at swampUP, in our user conference. So, for me, there is no better place to bring someone and show him JFrog, not just from a technology point of view and a product point of view, but also community relations and also the Frog vibe and the Frog DNA.

And then, when we started the discussion between us, actually, the two groups that worked hard on this deal were the HR group and the Operations group. And the first thing that we shared with Gal was the JFrog products. So, I think that Gal wouldn’t join JFrog if he would feel that this is not the right fit on the cultural point of view, and the strategy moving forward can be something that will change the world of the Enterprise culture.

So, the liquid software vision, together with the JFrog culture, I think kind of blended into what Gal believed in and what his team already is doing for the past 10 years. And what we have seen there was an identical picture of JFrog. It was almost like a glove to a hand, and now, after we signed and they are part of JFrog, I can say that this was a love story from the first moment we met.

Shimel: Alright, and it was a happy ending. [Laughter] So, I have to ask you, Shlomi—so, now, you’ve acquired a services company, Commandos, what’s next? What’s next at JFrog?

Ben Haim: That’s a perfect question. Actually, you sound like my ________ now. [Laughter] So, on the service level, I think that what Gal and Tali, our VP of Worldwide Sales, are working on now is how to merge these capabilities now with the Enterprise class, the JFrog class from adoption. This is one thing.

The second thing for JFrog is the extension of our technology. We see the consolidation in the DevOps market happening. There is two buckets that consolidate all the technology. One of them is the code repository, so you see what happened with GitHub and Bitbucket and so on. And the other one is the artifact repository. So, those two buckets are kind of consolidating all the technologies into it, and we are looking at it and we are looking at the landscape, and with the universal solution we provide and with the hybrid solution we provide and with the freedom of choice philosophy to be a developers first and DevOps first company, we will extend the technology.

So, stay tuned. I promise you that, at the beginning of 2019, we will have more news about technologies that support our goal.

Shimel: Fantastic. Gal, I’m gonna give you the last word.

Marda: Okay. Thanks for that, first. I must relate to what Shlomi said about love at first sight and the culture. It was amazing to see. When Shlomi called me, first of all, I was very flattered and surprised. But what I’ve realized very fast is that it’s kind of where we’re seeing the same thing but we were trying to help our customers in different ways. JFrog was doing that with creating great technology, and we were doing that with providing them with the best services we could.

But we tried to reach the exact same goal, the exact same way—developer first, technology first, and while we appreciate and we are all people persons and see the people and try to say, to maintain a very special culture. So, I think that’s a great fit in that matter, and I think it’s the most important one. So, I totally thank Shlomi for this opportunity to be part of JFrog, and I feel that we’re very much alike to begin with, but it’s a great honor to join a company like JFrog.

Shimel: Well, congratulations.

Ben Haim: Alan Shimel? Alan?

Shimel: Yes, Shlomi?

Ben Haim: You saw JFrog growing, and I’m very—you know, I’m very excited to have this conversation with you, because it’s like seeing different generations in JFrog. We will make the world of software liquid. We will liquefy software. This is our vision, so stay with us, I promise you we will have more news for you.

Shimel: I’m not going anywhere, and I have every confidence in you.

Ben Haim: [Laughter]

Shimel: Gal, to you, as they say in Boca Raton, Mazel Tov.

Marda: To dava. [Laughter]

Shimel: [Laughter] Alright. Shlomi Ben Haim, Gal Marda, JFrog—congratulations, good luck. We’ll check in early in 2019. This is Alan Shimel for devopsy.kinsta.cloud, and you’ve just listened to another DevOps Chat.

— Alan Shimel

October 2, 2018
DevOps Chat: Container Security and More with StackRox’s Ali Golshan

Security has many faces, which is why it’s so difficult to implement effectively. Each environment is different; each security solution is different; the needs of each organization is different. That’s why, as Ali Golshan, StackRox founder and CEO Ali Golshan put it, security has gotten a bad rap.

Golshan and his company are approaching security from a more DevOps-focused view, providing the necessary tools to enable DevOps teams to include security throughout the entire process. In this DevOps Chat, he and I discuss the many facets of DevSecOps, container security and more.

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

Alan Shimel: Hey, everyone, it’s Alan Shimel, and you’re listening to another DevOps Chat. Today’s chat is a little DevOps, a little security, a little containers, little bit of everything. Happy to be joined by StackRox founder and CEO, Ali Golshan. Ali, welcome.

Ali Golshan: Thanks for having me.

Shimel: And, Ali, I think I mispronounced your name. It’s “Golshan.” Correct?

Golshan: Correct. Yes, thank you.

Shimel: Cool. I try to do it right. So, Ali, let’s start with the obvious, though, maybe some people out here have not yet heard of StackRox, so, before we dive in, just a quick sorta elevator pitch so they have some context.

Golshan: Sure. We started StackRox three-and-a-half years ago. The premise for the company was we saw a couple of major shifts in the industry. One happened to be the introduction of containerization and microservices, which is a sub-effect of this larger trend that we’ve been seeing, which is application security and development becoming full product life cycle, so ensuring that you can cover security and compliance and requirements from build to deployment to runtime. And containers provided, really, a great packaging and a construct for building applications and microservices.

And then the second part of it is is that, when you look at this model, we realize that there’s really three fundamental things that are disrupting a $30-billion security industry. This is the whole notion of a full product life cycle needing to be automated. It’s immutability and ephemerality. And, because you can’t forklift traditional security solutions and deal with these three constructs, we decided to go after solving this much bigger problem for what we like to see is for the future of cloud.

And where we started was containerization just as the fundamental building blocks. As time and market has progressed, we’ve progressed with it, which is focus more on things like APIs and orchestrators and managed cloud environments, but very much with kind of a host-application-centric view of the world. We’re not a network-based tool. We’re not a log-ingest based tool. We tend to focus a little bit more on security automation, detection, and creating a multifaceted risk view of your environment, specific to containers and microservices.

Shimel: Got it. So, you know, there’s a lot in there and we’ll come back to StackRox maybe a little later in our chat today, but I wanted to – let me hit on a couple of things you mentioned. So the first thing is this whole idea of cloud-native, container-native. You know, when we first saw the shift to the cloud, the security industry’s response was what some analysts called “cloud-washing” existing security solutions. So they took their existing security solutions and they said, “Okay, now it could run in the cloud too. It’s a cloud security solution,” but it really wasn’t. It was a on-prem security solution moved to the cloud. It wasn’t cloud-native and it really was a little bit of a round peg in a square hole.

I think we’re seeing the same thing when we talk about security solutions built or trying to provide security for containerized applications. Right? What’s involved? Can you – you know, I don’t wanna coin the phrase, but can you “container-wash” an existing security solution and make it a container security solution, Ali, or do you really need sort of container-native-designed security?

Golshan: To your point regarding traditional cloud environments, I think that was a smaller chasm, where security companies had to cross, because that original movement was a little bit more about virtualizing your environment. So there was still some kind of applicability of running things like WAS or endpoint solutions, to be able to broaden your security posture to the cloud. Obviously, the fundamental problems we saw were created were around how do you automate and provision workloads and then the nature of those workloads remaining. Those were kind of – the new capabilities in the cloud were actually the pieces that created gaps for security.

So, if you then think about that and expand that further, the capabilities and designs for containers are even kind of another order of magnitude different than traditional. It’s not just virtualization and then outsize your boundaries. It’s virtualization; it’s microservices, every function broken down into a particular service; controlling it end to end. So, if you think about that there’s a large portion of the security industry that doesn’t even look at some of the most critical components of this process, which is the build and deployment. Building constant context there. Building declarative policies from that environment and then using it further. So I think that’s one of the major reasons we don’t see the applicability of traditional security solutions, even more so in containerized environments.

Shimel: Yep. I mean, Ali, I agree with you and I think that’s why, frankly, a lot of what is today passing for container security seems to be people doing vulnerability scans of containers or, as I think I had spoken to you about the last time we chatted, you know, network IDS for the container. It just doesn’t – it seems very much square peg, round hole. And I’m not saying you don’t need vulnerability management, whether you’re in a container or not, and I’m not saying you don’t need intrusion detection, whether you’re in a containerized environment or not. But to say that that is, quote unquote, a “container security solution” seems just pushing it and just trying really hard to sell.

But wanted to come back to another thing you mentioned in your opening remarks. And that was around this whole idea of not only are we living in a containerized age, but we’ve seen the rise – and I don’t wanna say the dominance of – but, you know, the whole CI/CD software factory pipeline model of which DevOps is an integral part of and we talk about shifting security left into the software development life cycle. And this is yet another way that traditional security has to give way to how things are done today, so how does that influence or how does that play itself out, in terms of StackRox?

Golshan: The way we think about that is, if you think about who were the first companies who moved towards containerization and microservices, they were all companies that needed to deal with massive scale, building velocity in their development and to the offerings they have for their customers. And, as a result, they realized that kind of traditional model of building and deploying and managing was just not sustainable because it wouldn’t scale with the human element. So this notion of DevOps, and even containerization as a result, were really tools and methods for companies to be able to increase their level of automation and sophistication as to how they managed and run their infrastructure.

So the way we look at this is is that, also, it’s the same reason why a lot of those first movers build their own security models around this environment ’cause nothing like it existed. So we see security kind of mapping to the same model, which is, if you think about it, things used to be a little bit more around a model of batch process, respond, do analytics, take those sorts of options. And, again, the way we look at this is is that what containers have done is break that fundamental workflow. That fundamental workflow isn’t kind of “Build something. Check. Build. Check. Build. Check. And have all these gating factors applied by security.” It’s a lot more fluid now. So, as a result, security has to kind of integrate into that whole workflow.

And this is one of the big things we talk about, which is is that the reason you can’t take traditional security solutions and apply ’em here, it’s not just the form factor of what they’re applying to, but it’s also the entirely new workflow that’s been created by DevOps and these types of environments that impact how a security tool should run. Because it’s not just tying it to a form factor or choke point. It becomes more of a service mesh – not to borrow the word “service mesh” from kind of the service mesh project, but that’s why it lends itself very well. It’s a number of services integrated across the process and then, as you automate these processes, they become force multipliers for each other. That’s how DevOps works and that’s how security should work as well. You can’t break that workflow model just because your security tool.

Shimel: Agreed. And you’re using the term “workflow model” and I think that’s a great descriptor of it, but, you know, a lot of goes back – and, again, part and parcel with DevOps – a lot of it goes back to the whole sort of Lean IT, based on Lean manufacturing. Sort of, it really is a factory pipeline kind of workflow model. And, when you think about it, the fact that, all this time, we’ve always kinda just stuck security on at the end, at the end of the packaging, so to speak, and then wondered why it didn’t work so great. It’s kinda obvious when you look at it that way, isn’t it?

Golshan: No, absolutely. I mean, that’s a interesting analogy, right? If you think about it. If you have kind of a industrial environment and you have manufacturing, if you move from a manual workflows to robotics and automated work flows, the sort of security you apply is gonna be very different – how you look for bugs, how you look at, for example, applications. This is a good analogy because it’s a very indicative kind of model of what the current industry’s going through.

Shimel: Mm-hmm.

Golshan: So I’ve become a big believer that you can’t – this is where I think security goes wrong, trying to cover too many things at once. If you have a completely new emerging model, like containers and microservices and DevOps, it’s okay to say that our security or our approach deals just with that particular area. And, as small or as big as it may be, it’s important because it adds credibility that you actually understand what it fundamentally is built from and what it’s doing ’cause, if you say anything other than that – “Well, no, mine can cover network and end points and VMs and containers and Lambda.” – well, that’s just a lot of the reasons why the security industry got the bad rap it did. It’s just things fundamentally work different.

Shimel: Agreed. Agreed. So, Ali, I think we’ve done a great job here, in the first ten minutes or so, of laying out these sort of macro-factors that are affecting not just the tech or even just the security industry, but the – it’s really affects the whole world because we’re all – every company’s a software company now. And so this really has worldwide bedrock kind of effect.

But let’s turn back to StackRox, right? Full circle back to the beginning. So how are all of these things manifesting itself in –

Golshan: Yeah, so the way we look at it is –

Shimel: – in what became StackRox?

Golshan: – is have one solution that has two modules to it that interoperate. We have the StackRox module that covers build and deployment and StackRox that covers runtime and production. And the way we look at this entire flow is very basic – on one side of the equation, you get to look at all the static and declarative information and you get to use it to say what things should be able to do, and then, any time you run it, be it in deployment, QA, or production, you get to learn from that application more and more and see what it actually can do.

So our mission is really bridging what it should do versus what it can do. And the reason, for us, the automation part of it is a big part of it is, you know, as companies mature their overall workflow, they will have additional tools that are gonna be provided by their platform providers, by their cloud providers. As an example, you touched on vuln-scanning. Absolutely everybody should do vuln-scanning, but, more and more, we’re seeing it cloud providers and platform providers provide it, so the key there is not to provide vulnerability; it’s to be able to do vulnerability management.

And the way we look at vulnerability management, it’s either being able to provide the customer the scanner or ingesting the data from all the scanners and then helping them prioritize it – “Where is this running in production? In production, what services are accessible by this?” So, if you have a low vulnerability that is running in a production environment, in a mission-critical app that is exposed to the Web, it should be valued higher than a high vulnerability that is running in dev in a closed-off EPC that has no access to any other services.

So context is what helps you prioritize, but it also flows the other way. So, in runtime, if you’re doing detection, it’s important to understand, if an attacker, for example, shelved and broke into a – broke out of a container, grabbed some tokens or credentials, you wanna be able to go back and look at the, for example, the secrets that are being managed through the orchestrator and see where else those particular credentials or secrets are available, where else that deployment has happened.

So, if you think about it, on the left side, you get a lot of really great insight. On the right side of the process, with the runtime and production side, you can make use of those to build very good boundaries and gating factors, and that naturally reduces your attack surface. So, as you feed this information back to the build and deployment, remove credentials or privileges or tools that are unnecessary, you’re inherently making your infrastructure and applications more secure. And, as a result, we have a much better landing zone for what we apply detection to. We don’t have to detect everything; we know where the weak points or where the gaps are in the system, to focus our detection.

So that’s kinda how we think about the overall StackRox product. Give the customers, especially the build and deployment and dev teams, the right security, auditability, automation tools on the build and deployment side, and then give the right runtime detection, alerting, response, forensics, and enforcement on the runtime protection side, for security folks.

Shimel: Excellent. And we’ve got a few minutes left here, Ali. I wanted to – for people who wanna get more information about StackRox, is it stackrox.com? S-T-A-C-K-R-O-X?

Golshan: It is. Yeah. We have all of our information on our website and we actually offer free risk assessments using one module of our product, where a customer can just grab it and understand much better as to what they’re dealing with when it comes to their container infrastructure.

Shimel: Okay. Let me come back one other thing to you and, you know, the proverbial “Let’s see your roadmap” slide, but I don’t really want you to show me your roadmap. But what do you think is next, not only for StackRox, but as a result of this macro environment that we’re living in? What’s the next shoe to drop here and how do StackRox sort of – I’m sorry about the noise there – how do StackRox respond?

Golshan: Sure. I think it’s a couple of things. One is we’re seeing more maturity across this entire stack, so we’re seeing convergence around orchestrators; we’re seeing kind of the standards around runtime engines being built; we’re seeing how public cloud providers are consolidating certain services and making other services much easier to use. Perfect example’s all the efforts around, for example, Kubernetes, between AKS, between EKS and GKE.

So, when we look at these trends, it shows a couple of different things. One, not only are the containers different, but the entire attack surface is going to look very different, so the way you approach this world is gonna look very different in the future. We’re not gonna make the same mistakes we did with traditional security, which is we’re not gonna make the host overly exposed with a lot of user accounts and credentials and privileges and tools and packages. So we think that that host will obstruct the way and the orchestrator will become kind of a new cloud operating system, with APIs.

And, as a part of that, you’re gonna end up seeing a lot more complexity, so, as companies get more comfortable running applications as microservices, more containers, better grasp of the orchestrator, they’ll get more comfortable running more complex operations and applications on top of it. Naturally, that comes with maturity. And once you have that, you end up going from kind of what right now is, which is very early stages of this ecosystem, which I would consider to be low entropy, to a very high entropy environment you’re gonna end up seeing.

As a result of that, the way we see security being built is, one, that’s why it’s very important to focus on automation, integration, and the workflow, but, secondly, we see security having to be built in cloud native as a form-factor-agnostic model, meaning leverage the existing frameworks to – if it’s collecting data, for example, from the system, use, for example, things like the extended Berkeley Packet Filter to use that. If you’re running on Amazon or Google, you can use things like Pub/Sub or Kinesis.

So it’s building more modular, programmable, and pluggable architectures, versus building a binary that deploys in a container and then you replicate that container against a bunch of hosts. It’s about building a sensory model that can understand different environments and make sense of them, not single agents that unilaterally take action, because, as complexity, heterogeniality grows, naturally, there’s gonna be a lot more gray area, as far as use cases go. And that’s where you run into the old problem of alert fatigue, noise, false positives, and then, eventually, you end up with 50 security solutions.

Shimel: Excellent. Excellent. Well, Ali, we’re about out of time, but I gotta tell you, man: I love this chat. This was great. I’d love to have you back on the –

Golshan: Yeah, same here, Alan.

Shimel: We’ll dive into some more of this stuff. Good stuff. Ali Golshan, cofounder and CEO of StackRox, here on DevOps Chat. This is Alan Shimel. You’ve just listened to another chat. Have a great day, everyone.

— Alan Shimel

October 1, 2018
Continuous Discussions, Episode 90: Gene Kim and DOES18 Speakers

In a recent episode of the Continuous Discussions (#c9d9) podcast, we hosted Gene Kim and several speakers from the upcoming DevOps Enterprise Summit Las Vegas (DOES18) conference. We’re proud Founding Partners of the event and always enjoy having IT thought leaders join us ahead of the show to talk about DevOps, the conference program and more. In this episode, we discussed an emerging conference theme of next-gen operations and infrastructure.

The panel of DOES18 speakers included: Cornelia Davis, senior director of technology at Pivotal; Damon Edwards, co-founder and Chief Product Officer of Rundeck; Mik Kersten, CEO of Tasktop; Tom Limoncelli, SRE at StackOverflow.com; Gene Kim, founder of IT Revolution and co-author of “The DevOps Handbook,” “The Phoenix Project” and “Accelerate”; and Electric Cloud’s Sam Fell and Anders Wallgren.

Continue reading for some of the top takeaways from the discussion!

Next-Generation Operations: Programming and Insights

As we continue to evolve, the best is yet to come for operations teams, per Kim: “If we follow the course of what the development languages and development frameworks have done for development productivity, and extend that to operations, I think the best time for operations and infrastructure and platforms are to come.”

Davis encouraged operations teams to treat their platform like a product instead of infrastructure: “When I speak with the IT operations folks, they’re still largely short order cooks. They’re very reactive, doing things that people need them to do. It’s about being able to apply some of the same principles of continuous delivery to the way that you do ops. At the core of that is this philosophical notion, which is to treat platform just like you treat any other product.”

The way enterprise operations teams do work is unique, per Edwards: “For enterprise operations, you have to fundamentally rethink the conventional wisdom of how you think about, approach and do operations work. DevOps Enterprise Summit started in the early days of the DevOps explosion. This is distinctly an enterprise discussion because it’s all about that history of success that we have to account for.”

Kersten on the different ways development and operations teams measure outcomes: “I so often see the development side of the organization and the infrastructure operations side collecting completely different metrics and telemetry. The development side uses the more familiar telemetry that comes from DevOps. And the operations side is still in a burnup, burndown world. There are no common metrics or languages for what really should be an internal value stream.”

Great operations management advice from Limoncelli: “Get one team to do it well, and let people copy that success. And do it in a way that creates cultural minimums or cultural ways of doing things, so that people are competing to make things better instead of being told you have to make this change.”

Moving away from legacy operations is a dauting challenge especially for the enterprise, explained Wallgren: “The things that we refer to as legacy are the things that keep the lights on and bring the money in. It’s a big leap to move away from that and it’s going to take a lot of work and quite a lot of time. It’s like changing the engine and tires on a car while you’re driving down the highway at speed.”

Functional Programming, SREs and More Musings

Davis on functional programming, something she will be talking in-depth about at DOES18: “Treating function as a first-class citizen is absolutely essential because you start to create these functions very dynamically, and the functions now encapsulate the state. So instead of having state and then having side effects against a state, what we have are these functions encapsulating a sequence of changes that are going to generate a state.”

Kim described an “aha” moment he had during Davis’ talk at DOES18 London about sidecars in Kubernetes: “The ability to liberate developers and address cross-cutting concerns like logging was one of the primary impetuses why people flocked to Spring from orthodox frameworks that were so unsatisfying. And that was, for me, that was one of the biggest aha moments of the conference.”

Edwards discussed the implications of toil work and how to spend more time doing things of value: “Toil work is work that we should have automated, it’s repeatable, and not adding enduring value to what we’re doing. Versus work that requires human ingenuity, the engineering work that adds enduring value to our organization. Set a limit as an organization to not accept more than 50 percent of time being consumed by toil and figure out how to help those organizations where they have too much toil and not enough engineering work.”

Most organizations don’t have $2.5 billion in their back pocket to build a product-oriented value stream, but Kersten said we should take a page from their book: “This is a testament to how invested the tech giants are in their own platform as products. If we don’t at least adopt their thinking around having this connected end to end platform that supports all your products and value streams, you’re just not on the right path.”

Limoncelli on the ability of SRE’s to reach across silos: “In the SRE model, you can reach across silos. I like to think of it as you have the CICD pipeline and the SRE’s stand at the end of the pipeline asking, ‘What are the operational problems that we’re having? What’s the constraint? What’s the bottleneck?’ They fix that by asking how they can collaborate with the other team within our organization. And either sit with them for a week and fix it or collaborate with them to fix the problem.”

Wallgren elaborated on treating pipelines as code: “Treating your pipeline as code is something we’ve been evangelizing. And really, that should be the first thing that you really worry about in some sense, because you’re not going to ship anything unless you have a pipeline.”

The DOES18 Las Vegas agenda is now live! Check out the sessions from Davis, Edwards, Kersten, Limoncelli, Wallgren and dozens more. Tickets to DOES18 are running low, so be sure to register before it’s too late.

Watch the full episode:

— Anders Wallgren

September 6, 2018
DevOps Chat: SRE w/ Stig Sorensen of Bloomberg

Many people say that site reliability engineering (SRE) is “putting the Ops in DevOps.” In this DevOps Chat, we speak with Stig Sorensen of Bloomberg’s SRE team. Stig tells us how SRE is helping Bloomberg keep pace with the fast moving world of news and information.

Great discussion with a real-life practitioner about how SRE is being deployed in a real-world company. As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

Audio

Transcript

Alan Shimel: Hey, everyone. It’s Alan Shimel and you’re listening to another DevOps Chat. We’ve got a really good DevOps Chat lined up today on a really hot topic, and it’s SRE, site reliability engineering. And my guest is Stig Sorensen, who heads up – a member of the SRE team over at Bloomberg. Stig, welcome to DevOps Chat.

Stig Sorensen: Thank you very much. I’m glad to be on.

Shimel: So let’s get formalities out of the way. Stig, give our people your title and background here so that we can get started.

Sorensen: Okay, so my name is Stig Sorensen. I am the manager of the production visibility group at Bloomberg, responsible for building our CMDB tools and also building telemetry assay as a platform. I’m also one of the main evangelists for rolling out SRE as a role and as a – a new movement across Bloomberg.

Shimel: And Bloomberg is, of course, no small company, so rolling out this new role, this new way of looking at Ops and so forth, is – is of course not a – you know, it’s not something we should take lightly or think it’s easy.

Sorensen: Well, that’s very true. It’s – across our 5,000 engineers, it’s – that supports everything from our commercial website to – to market data feeds, to obviously our main product, the Bloomberg Professional Terminal which hundreds of thousands of the key influents around the world rely on. And, with various states and various different tech stacks, it’s actually quite – quite a challenge.

Shimel: Excellent. So, so Stig, why SRE, why now at Bloomberg?

Sorensen: So SRE in, like, what we do isn’t really new to Bloomberg. It’s always been sort of the engineers that own production and sort of own the – the availability of production, and own the process around it.

What we’re sort of trying to do now is sort of really more divide the responsibility between the application engineers and the SREs such that we can have people that are experts on – either of them, but it’s sort of unfair in today’s complex world for everyone to know everything from how a – how an instrument trades on the street to figuring out how to – how to run and manage a high availability system. Right? So it’s more fitting it into infrastructure and making people experts.

Shimel: So an interesting point you bring up, Stig, and you said, we’ve always been doing this kind of thing. And it’s true. A lot of what we now today are calling SRE isn’t necessarily brand new in terms of task and responsibility. It – it may be there’s more of the packaging and some of that mixed in.

When – when did Bloomberg, let’s say, start referring to this role, to this, you know, needs as, you know, quote/unquote “SRE”?

Sorensen: So we sort of started small about two years ago and it’s really sort of – really caught fire in, I would say, the last year where we really made it sort of a more firm-wide. It’s always been pockets of where it’s sort of been done, but then we really, like, part of the puzzle is really sort of internal branding as well in terms of labeling the – not labeling the people, but identifying who is there creating the right environment for these people to learn, to share ideas. Right?

I think, as you said, the – it’s not necessarily the new thing to do. What’s new for us is sort of really trying to do it in a more – more standard way and a more persistent way across the – across the firm.

Shimel: Yep. So Stig, you know, 5,000 engineers. How many are, you know, quote/unquote “on the SRE team”?

Sorensen: So they – we don’t actually have a centralized SRE team today. We sort of rolled it out in a way where we aligned the SRE teams with the application teams. The reason for that is really a lot of – in order for the SRE teams to be successful, the applications also have to change. Sort of separating the responsibility too far away makes that harder.

So we sort of put them parallel, side-by-side, two equal teams with the different responsibilities and – and that’s really sort of how we kick start the teams. Most of the SRE – a lot – quite a few of the SRE teams are seeded from – from the application teams and a lot of, like, the – the core infrastructure teams and so on.

So all-in-all we have about 75 people that are in sort of the – in the sort of teams that we have sort of – the teams that are SRE teams. As I said, we have a lot more people doing it across the firm, but they’re doing it as a part-time – part-time job.

Shimel: Got it. And so Stig, you know, SRE – this concept of an SRE – as you said, though they – we’ve been doing these kinds of things forever, the idea of calling them SRE and labeling them as such is relatively new.

Is there any particular training or skill sets that you’re asking people to – to make sure they’re, you know, proficient in in order to be quote/unquote “an SRE”?

Sorensen: That – I think – I think sort of – the answer is that we are hiring and we’re trying to hire many, many more. They sort of come from two different camps. It’s either people within operational or system admin background that’s sort of picked up programming and moving that way, or we have application engineers with an – with a more active view towards systems and towards availability – because we see SREs as software engineers just doing something – building a different type of software.

And I sort of jokingly tried to sort of classify SREs versus application developers in a way, sort of – I see application developers as inherently optimistic, they think everything will work all the time, and SREs are sort of the opposite, they think everything will break all the time. And that sort of relates – I think it’s more of a mindset than necessarily the skills. Skills you can always learn. And then I think some – as long as you have the right mindset, the right aptitude to do it, that – well, that’s what’s key to us. Right?

And I think there is – I think there’s way more SRE jobs than actually people that have done SRE before out there now. So we can’t go out and try to hire the – the ready SRE. We need to figure out how we get smart people with the right aptitude and training them.

And people mention training, we sort of try to do it in sort of like a lot of meet-ups, a lot of sort of internal meet-ups, external meet-ups, attending conferences to figure out what’s happening in industry, talking at conferences such that we also show what we’re doing.

And I think it’s – I think it’s really sort of a lot of on-the-job training, working with the application team, working with other SRE teams, and you realize that you’re not alone. There’s always – there’s always someone doing something very similar to you. You don’t need to invent the wheel every single time.

Shimel: Yeah, and Stig, we should not underestimate the importance of what you just said there. With a new field like SRE – and we saw this in DevOps, early on in DevOps – because there’s no sort of codified best practices, right? There’s the book from the Google team, and there’s other stuff coming out now but there really isn’t a – a best practices. There’s emerging practices. And so the idea of peer-to-peer sharing and – shared learning is – is really important to continue advancing, you know, the state of the art, if you will.

In addition to my DevOps dot com duties, I’m also one of the co-founders of DevOps Institute and this is exactly what we – the fact pattern that we saw in DevOps. And it’s the same fact pattern we’re seeing in SRE and frankly it’s one of the reasons why we are working, and expect to have out soon, an SRE course that kind of starts, you know, pulling together all of these emerging practices and having a common body of knowledge around it.

Sorensen: I think that’s great, that – that we’re sort of trying to standardize these things, but – because a lot of it also becomes sort of – you have to be flexible when you roll it out because not every application or every system can be rolled out – can – can get an SRE team and roll out in the same way because there – there’s different maturity of the systems, there’s different problems. Right?

Like, in terms of, like, do you focus on monitoring and a production environment or do you focus on more sort of the classic DevOps things and how you get things into production. Like, you really have to look at it from a holistic point of view. The goal of the SRE team is to improve availability of production. There’s multiple ways to do it. You could pick one and make it better, you’d probably – you’d probably improve it. Right?

And the – thinking – like, it has to do everything to make a difference is also probably not the right thing to think about.

Shimel: Yeah. Absolutely. So, Stig, let me – let me kind of pivot here a little bit and let’s talk about – what’s in it for Bloomberg with SRE? Why are they supporting you?

Sorensen: Well they – it’s – I think it’s really just looking at the services we provide. Right? Like, we’re providing real-time financial information to 300,000 of the most influential people around the world and it’s not really just about availability, it’s also about performance and latency of this – the data going around the world. Right? We – we process something – what, like 100 billion market data picks a day and one-and-a-half million news stories a day. Right? So it’s – so in order to keep all these pipelines going, it is actually quite a big job. Right? And I think just – just making sure that we are available and don’t influence the financial markets by not being there.

Shimel: Yeah. I mean, that – you know, and that brings home the, you know, we’re not – sorry, Bloomberg doesn’t sell widgets that no-one cares about. Downtime and performance there is – is, you know, teamed up or, you know, ingrained with financial market performance and reporting. You can’t afford – you can’t afford downtime. You can’t afford, kind of, mess-ups.

But Stig, we spoke a little off-mic about this and it’s a topic I want to bring up is, you know, at Bloomberg, you guys have been doing this SRE thing now and you think it – you’re making progress and it’s good, but we really haven’t done any sort of formal ROI analysis or, you know, similar type of work. Correct?

Sorensen: Yeah, no – that’s very true. It’s – it’s probably one of the biggest challenge in terms of, we have support and everyone believes it’s the right thing to do. You have the gut feel that this is – we have to do this to make it better or to be – or to keep the service going we’ve always had.

But I think it’s sort of a – for us it’s – for us, like, measuring – _____ measuring availability is actually not black and white. It’s not like, how many – how many failures you had on a website. Right? Because if you are a certain market player and the real-time market data is delayed by a few – by one millisecond or hundreds of milliseconds, it could make a big difference for you. Right? And it’s – is that complete failure or partial failure? And, sort of, all these things in between.

It’s sort of something we’re – we’re really working on to try to define better metrics around it such that we can track our progress effectively to see if – if we had – if we – if we are succeeding. It’s – if you go by the gut feel, it only lasts so long but at some point you need to really ask yourself, you need to make sure that the return is there

Shimel: Absolutely. Stig, I mean, and let’s be clear. This is not a Bloomberg issue at all. I – you know, we haven’t really seen it across the board yet. You know, formal ROI type of analyses for SRE, but as you said, it – you know, it obviously makes sense or, you know, logical to think that it’s good for – for organizations and I think this is why we’re seeing so many organizations starting to adopt this.

Another thing I wanted to touch on, though, Stig, was the idea of, again, paralleling the DevOps experience, originally everyone said, oh, DevOps is great for unicorns. It’s great for Google, it’s great for Facebook, it’s great for the Twitters of the world, but it doesn’t really work on the horses. Right? On the just regular, large enterprises.

SRE, well, yeah, that’s a Google thing and it’s great for Google but is it going to work for Bloomberg. Right? Or similar kinds of things. And, you know, you’re living proof, if you will. But every road, Stig, there’s – it’s – you know, I call it the DevOps cha-cha. It’s never linear, one step in front of the other and it’s just, you know, smooth sailing. There’s always a failure here, a lesson learned here, a step back, two steps forward, one-two, one-two-three.

Give us, you know, I’m sure you could give us plenty of successes. Give us a failure or two that you guys really learned from. Lessons learned.

Sorensen: Cool, yes, it’s – I think sort of in – the lesson learned in failure of the transformation was really, I think – some of the teams that was – that was labeled SRE was given too much operational work such that they didn’t necessarily have enough bandwidth to get themselves out of the quagmire they were in. And that sort of created, like, a new pattern in terms of that, like, SREs are operations, and they’re not. SREs are developers. But developing things to get rid of operations work, but if you don’t have time to develop, you’re never going to get out of it.

So I think that’s probably about the biggest lesson learned in terms of – in terms of the building the culture and getting sort of the – the optics to be right internally. And sort of in the same way, I mean, sort of like, it was also, sort of, SREs within the application teams and not having dedicated teams was also quite a – sort of an anti-pattern that we saw a bit where it’s easier to steal the SRE’s time to do application work. And then again, we don’t actually move forward. So the – so that’s sort of probably the biggest failure.

I think also we need to make sure that we have a good set of base tools and base things that – that can be shared between the teams such that _____ everyone needs to – needs to build everything from the ground up. And we probably – we probably started sort of in silos where sort of parallel things were built but it improved. It improved – it improved the production quality but it didn’t necessarily make us go faster in terms of rolling out SRE and so it – we sort of had to step back and sort of standardize a bit more of tools and make sure we had central ownership of some of these tools rather than individual teams owning them.

Shimel: Excellent. Stig, we’re coming up on the end of our time here. I wanted to kind of just ask you, so, you know good progress, off to a heck of a start, a fine beginning. Where do you see the future of SRE at Bloomberg specifically and in the greater market, let’s say, if you had a crystal ball, over the next three to five years?

Sorensen: I think – I think internally here, right, like we’re – we’re trying to grow significantly so for us to just be able to – to both convert people internally from an application to an SRE and also hire the people.

And I would hope for us and for larger companies like us where there’s a transformation, that it becomes – becomes more standardized such that we can have a centralized org that is the SRE org, and have sort of more of a – where we can – where we can scale – scale and support more teams whereas now it’s really one-to-one and – not necessarily one-to-one in terms of people but one-to-one in terms of teams.

And I would hope the industry in general also starts to think about the people that do not run on the big cloud providers and sort of actually own everything from the ground up, like us, and I would hope that more companies that are like us get into this such that –

[Inaudible due to radio noise]

– that it would be more pools and more things to support us. Right?

Shimel: Sure. Sure. Well, Stig Sorensen of the SRE team at Bloomberg, I want to thank you for being our guest on today’s DevOps Chat, and, you know, this is really – this whole SRE thing is certainly an area where we are watching closely. Maybe we could have you back on in a couple months and get an update.

Sorensen: I would love to, that would be great.

Shimel: All right. Stig, thanks again. This is Alan Shimel for DevOps dot com and you’ve just listened to another DevOps Chat. Have a great day, everyone.

— Alan Shimel

June 18, 2018
DevOps Chat: Prem Chandraskearan, VP of Software Engineering at Barclaycard

In this DevOps Chat we spoke with Prem Chandraskearan, VP of Software Engineering at Barclaycard. Prem led the DevOps transformation there. He sums up his learning thusly:

The best way for an organization to approach DevOps is from a collaborative angle. When development and operations experts actively work together in a cohesive effort, solutions are well designed, efficient and smart from both a development and maintenance perspective. When operations is viewed as a software problem, Dev and Ops can work in tandem to implement a tool that is holistically a part of the process from start to finish.

DevOps is always a work in progress, but the initiative can only improve with quality resources that implement a variety of backgrounds and perspectives on both Dev and Ops working together. Barclaycard has had some interesting challenges with DevOps due to being in the credit card/banking industry, so for example, the “you build it, you run it” mantra doesn’t work as well for us as it would for other enterprises implementing DevOps. It is definitely a learning curve, and our goals and best practices are still coming to fruition, but we are continuing to find ways to automate.

The best way to get teams to work together is to simply ensure that they are not in silos, meaning that if there are distinct dev and ops teams, they must spend time in each other’s sectors to understand the pains, how the functions work, what makes it tick, etc. When the development and maintenance perspective are strategized in tandem, it automatically makes for a better, more streamlined workflow.

The best way to ensure a DevOps initiative’s long-term success is to ensure that the foundation of the program is collaborative and understanding of how each function works. With this, automation testing for failure is imperative to discover problems that are typically only otherwise found in production. If all the bases are covered and the process is streamlined and collaborative, the overall quality of your DevOps function will be much higher.

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

Audio

Transcript

Alan Shimel: Hi, everyone, it’s Alan Shimel, devopsy.kinsta.cloud, and you’re listening to another DevOps Chat. Got a great chat scheduled for today. We’ve got a real, live DevOps practitioner. I’d like you to welcome to the show Mr. Prem Chandrasekaran—and I mangled that terribly—Prem, why don’t you give us proper pronunciation?

Prem Chandrasekaran: The name goes “Prem Chandrasekaran.”

Shimel: Fair enough. I don’t think I did that bad then. So, Prem, you are a software group leader at Barclaycard US, correct?

Chandrasekaran: That’s correct.

Shimel: Okay. And, well, before we get into it, let’s make sure that, in case people aren’t familiar with Barclaycard, who they are and what they do, if you wouldn’t mind just giving us maybe a quick little background on that.

Chandrasekaran: Yeah. So Barclaycard in the US is a credit card provider. Our primary business is co-branded credit cards, so, for example, when you’ve got an Apple credit card, if you look carefully, it actually says “Barclaycard” on it, in the background somewhere, but we’ve got a whole bunch of partners like that and we provide credit card services for our partners and customers through the co-brand. We also have a consumer lending business, which is a lot recent, but the credit card business is what is our primary revenue _____ _____, if you wanna look at it that way.

Shimel: Very good. And, Prem, in your role as software leader, what exactly does that mean? ‘Cause it means different things in different orgs.

Chandrasekaran: Yeah, yeah. So my actual title is that of a vice president, but, you know, what I was hired to do was to incept this new line of business. We were coming up with a new line of business called “consumer lending.” And our infrastructure, both hardware, software practices, all of those were on a pretty old legacy system, and we had two choices. One was that we would build on top of the legacy system or create a new platform, as we wanna call it, have all of the modern techniques that we use, including CI/CD, a lot of XP factors, and so on.

And I was brought in as a consultant first when I took the role on full time, two years ago, to lead the launch of that new consumer lending business. And I’ve been doing that. And now we’re trying to apply the same processes, software, hardware, all of those solutions, onto the credit card business, as well as we try to migrate.

Shimel: Excellent. And how long has this project been ongoing?

Chandrasekaran: Consumer lending started somewhere in 2015 and we launched at the end of 2016. It’s been live for the last 18 months or so. And what I’ve been doing after that is, again, I’m still in charge of making sure that consumer lending runs in production, but we’re also building what we call a “global platform” – basically, a set of design patterns and application templates and CI/CD pipelines to allow us to create new services, migrate existing ones, and develop what we call the platform –

Shimel: Oh, sorry. Go ahead.

Chandrasekaran: Yeah, so what I’ve been doing is we’ve been defining the learnings from what we did for consumer lending and making it available to development teams here, so that they can focus more on the business-logic portion of things, solving real problems, as opposed to grappling with a whole bunch of the surrounding stuff, nonfunctional stuff like log-in monitoring, CI/CD pipelines, tracing, and authentication authorization, and so on and so forth.

Shimel: Correct. So, Prem, I didn’t hear you mention security or cyber security, though, and that’s obviously something that’s important anytime we talk about financial services. Where did that play in, in the program here?

Chandrasekaran: I mean, we like to think that it’s something that starts with the code that you write, you know, so we make sure that all of our developers and teams think about security right from the ground up. And we have tests, both static and dynamic and penetration test frameworks, which check the state of the code that you’re developing from a security perspective, right through the CI/CD pipelines. And you’ve got a whole bunch of automation and a bunch of manual penetration tests that the teams do, to make sure that we are producing things that are secure not only for ourselves but also for our customers.

Shimel: Got it. So, Prem, let me ask you a question then. What I think is interesting is this was a project that, as you said, started in 2015, and here we are, 2018, talking about some successes you’ve had. And now rolling some of the lessons and learnings and success from that throughout other parts of the organization. And that actually – no two DevOps transformations, no two experiences, are exactly the same, but that’s right in sort of the sweet spot of how we see DevOps expanding within an organization. You get a project and many people are surprised that, in spite of the speed and automation that we think about in DevOps, it actually takes time. It takes time to launch a project. It takes time to bring a project to market like this.

But, once that’s done and you have good results, part of that DevOps way, if you will, is to take the feedback loops, take the learning, take the lessons learned, and apply them in other places within the organization. Prem, what about executives sponsorship of this, if you will? I mean, you’re a group leader, but, above you, what kind of buy-in or sponsorship did you have from your exec team

Chandrasekaran: Oh, absolutely. I mean, without exec sponsorship, I don’t think we would have progressed to where we are. I mean, we’re by no means done, but, you know, we are still in this journey and we’ve got a very solid leadership team which basically said that we need to operate not as a traditional bank, but as an IT organization, rivaling the best in the world, right? And that’s where we want to be. And it starts from there. And it percolates pretty much every single facet of our organization, starting form hiring to the way that we think. Basically, you know, DevOps is really a means of shortening the cycle of getting a product out of the door reliably and repeatedly, right?

Shimel: Yep

Chandrasekaran: So it does take a huge amount of effort in terms of the automation and the processes that we need to put in place, but, yeah, I mean, we’ve got very strong support from our leaders to help us transform the organization that way.

Shimel: Okay. So, Prem, let me put you on the spot here a little bit. We have listeners out there saying, “Wow, this guy’s done a project where they did this,” right? If you could – and we didn’t discuss it, so I apologize for putting you on the spot – can you give our listeners sorta three things they should avoid? What were the three biggest lessons you learned in the course of this project?

Chandrasekaran: Yeah, so, okay, I’m gonna try to look for three things, right? Okay, so the first thing that comes to mind is that, at least at a place like where we are, in a bank, right, buy-in is very important. So you might have buy-in from the top, but you need to have buy-in from pretty much every facet of the organization, that automation isn’t a threat to their jobs and existence, right?

Shimel: Mm-hmm.

Chandrasekaran: Where, you know, it’s normal that now our time and operations person – “Oh, my job can be automated and now I’m out of a job.” Right? That’s one thing that it’s largely a psychology thing, where you have to address that and give people the confidence that that’s not the motive here. The motive here is to churn out software fast and enable both DevOps, business, QA, information security – I mean, you name a whole bunch of these groups – it’s about collaborating and working closely together to achieve the end, which is putting out software solutions for our customers and our stakeholders repeatedly and reliably, like I said before. That’s one. It’s more of a mental shift that needs to happen. And, unless you do that, you’re going to meet with a lot of resistance.

The second thing is in terms of who you hire, right? Like I said, it’s a mental thing. It’s a philosophy where you need to have likeminded people who want to do the automation, as opposed to doing something that’s manual and error-prone, right? So hiring the right kind of people definitely is second.

And, third, it also needs your business folks to be patient while these transformations happen, where you might not see the benefits of it on day two, right? It takes a while for the benefits to start appearing because it does take a lot of practice. And we’re not there yet in terms of saying that we’ve achieved perfection – I guess nobody can say that – but it does take a few patient stakeholders as well. I mean, those are my three things.

Shimel: Excellent. So, you know, Prem, when we started, I said the 15 minutes go quick – we’re wrapping up here – but, again, for our listeners who maybe are contemplating or in the throes of their own DevOps journeys, I mean, this is certainly a success story to date. What else – I mean, what’s next here, though? Beyond what you’ve already mentioned to us?

Chandrasekaran: Yeah, you know, so, right now – I mean, our next step is to scale this out, right? I mean, we’ve got one product line that is using all of these, and a bunch of the rest of the organization, at least here in the US, has drawn a lot of inspiration from the successes that we’ve gained here. You know, we still operate in a private-cloud environment. We’re targeting going to the public cloud, which basically means that we now allow ourselves to scale a lot more quicker and a lot more faster. So, yeah, I mean, that’s probably the next step, where we’re targeting the public cloud and provide value to our business and customers a lot more quicker that way.

Shimel: Excellent. Excellent. Well, Prem, thanks so much for giving us a little bit of insight into how Barclaycard US has leveraged DevOps here and has started out on their own DevOps journey. We’d love to hear more about it in the future; maybe we can check in.

Chandrasekaran: Yeah. Thank you very much, Alan, for having us.

Shimel: Okay. Prem—and I’m not even gonna mess it up or attempt ’cause I will mess it up—Prem, thanks so much for joining us here on DevOps Chat. This is Alan Shimel for DevOps Chat and we hope to see you soon on another DevOps Chat. Have a great day, everyone.

— Alan Shimel

April 24, 2018
DevOps Chat: Continuous Testing with Sandeep Johri, CEO, Tricentis

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

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

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

Audio

Transcript

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

Sandeep Johri: Thank you, Alan.

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

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

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

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

Shimel: Mm-hmm.

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

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

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

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

Shimel: Wow.

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

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

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

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

Johri: Right. Right. Right.

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

Johri: Uh-huh.

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

Johri: Right.

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

Johri: Right.

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

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

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

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

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

Shimel: Mm-hmm.

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

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

Johri: Yeah.

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

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

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

Johri: Mm-hmm.

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

Johri: Mm-hmm. That’s right.

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

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

Shimel: Mm-hmm.

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

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

Johri: Wonderful. Yes.

Shimel: Yep.

Johri: Mm-hmm. Mm-hmm.

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

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

Shimel: I don’t know.

Johri: Oh, God.

Shimel: You know what?

Johri: Yeah, I should –

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

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

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

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

Shimel: It’s okay.

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

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

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

Shimel: As both, right.

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

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

Johri: Thank you.

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

— Alan Shimel

March 9, 2018
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

December 6, 2017