devopsy.kinsta.cloud

Category: DevOps Chats

DevOps Chat: A New Take on Application Security with Portshift

Portshift brings a new identity-based application security model from code to runtime. Cloud or on-prem, Portshift works. In this DevOps Chat we speak with CEO Ran Ilany and VP Business Ops Eran Grabiner about what is unique to the Portshift solution and why you should consider it for your own application security, especially for your DevOps teams.

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, Security Boulevard, and you’re listening to another DevOps Chat. In today’s DevOps Chat, we actually have a new company to introduce to our audience anyway and that company is Portshift. And I’m joined by two of the key folks at Portshift. We have Eran Grabiner, who’s VP of Business Ops, and Ran Ilany or Ilani – I mispronounce your name, I apologize – Ran Ilany, CEO and –

Ran Ilany: Ilany.

Shimel: Ilany, great. CEO and cofounder. Gentlemen, welcome.

Ilany: Thank you.

Eran Grabiner: Thank you, Alan. Thank you for having us.

Shimel: Oh, my pleasure. So, Ran, you’re the CEO. I’m gonna let you kick off. A lot of people in our audience may not be familiar with Portshift. Fundamentally, what’s Portshift about?

Ilany: So, fundamentally, Portshift is trying to solve – solving a problem which is a hard problem that wasn’t solved in the last couple of decades and was very much introduced as a solution, during early ’90s, with the firewalls technology. And now we’re moving to the cloud infrastructure, we see that the same firewalls that were used 20 years ago are not longer, I would say, valid, in order to run a application. And, essentially, there are, I would say, two to three reason that to that and I will let Eran elaborate about the reason of why.

Grabiner: Yeah. Sure, so, you know, Alan, when speaking about the cloud, there are two things that fundamentally changed everything for IT folks and DevOps engineers. The first thing: you don’t own the infrastructure, so the level of network and infrastructure, you simply don’t control it.

And, secondly, a lot of change through time in the world of compute. If – I don’t know – ten years ago, we had the monolithic application sit down in our data centers in the office, right now, when we’re in the cloud, our application is broken into many different pieces, many different _____ services. Everything is much more automated. Software is being updated on an hourly basis. And developers and engineers, they have much more power to do things with their software. So, because those two reasons that the old tools that we had, in order to orchestrate security in our network, simply doesn’t work.

Ilany: Yeah, and –

Shimel: Agreed. Ran?

Ilany: And just to add to those points, there are two layers that essentially impose the challenge. The first one is the fact that, if you’d really like to, I mean, to use firewalls within the cloud environment, you really need to understand the network infrastructure. To understand the network infrastructure, you need to understand what is the application is doing out there in the cloud, and, in order to do this, you need to configure those IPs and those ports, which actually create a very, very close binding to the actual network infrastructure, for one hand.

And, for the other hand, you obviously need to have this type of discussion between the security folks to the actual operation folks, which actually creates a lot of bureaucracy that was possibly valid, you know, 15 years ago in the data center, but, now we’re moving to the cloud and everything is automated with CI/CD, you need something else. Okay? You need to break the paradigm, at least from being tied to the actual network, from one hand, and, from the other hand, you need to make things to be much more fast and much more intertwined with the development life cycle. Which is essentially the primary objective that Portshift’s have put in as a target and as a solution.

Shimel: Absolutely. So, guys – and, look, I’ve been in this a while myself. You know, when we first started with the next-gen firewall, right, and that was sort of the premise, is that we were gonna get the developers involved and application-aware firewalls and all that, but it didn’t translate to the cloud. You’re right. But, Ran, I’m interested, as the CEO/cofounder, so this is obviously a problem, right? How do we do this in a cloud environment, at cloud scale, at cloud speed and all of that?

Ilany: Yeah.

Shimel: How did this affect you personally or in your kind of journey to where you’ve got here today, where you recognized and said, “Hey, we gotta do something about this, that this is a problem looking for a solution here”?

Ilany: Yeah. So, essentially, we understand that there is a problem that requires a solution, you know, while talking with customers. I mean, those are usually the No. 1 –

Shimel: That’s the way –

Ilany: Yeah, and –

Shimel: – the best way to do it.

Ilany: And we saw that there are – and we call it “the impossible tradeoff,” okay? They either need to be very, very fast – they want to run very, very fast in the cloud, from one hand, but then they have a security constraint. They really want to control, I mean, the communication between the application and where the application should run. And there, there is the where to be in the curve of being Agile and being secure every organization has to find itself, in this type of curve, and to find what is the level of security that it wants to enforce or impose.

And this is, I would say, what led us to think of changing the paradigm or breaking the paradigm or making a solution that the customer will not have to make this type of tradeoff or make this type of decision and target to be both fast and Agile but also secure from the other way around _____ _____.

Grabiner: And we basically looked at what’s going on in the cloud from the DevOps perspective and we saw that many things changed to be better, with automation, with CI/CD tools, and we ask ourselves why, with security, this is not happening? Why the workstation or the tools that the DevOps engineer is now using to deploy software, why security tools can’t look the same? Why they can’t be part of the same idea and the same work cycles? And this is what got us to think that we need to, in a sense, push security to the left, shift left, and take it to be something that is part of the DevOps life cycle and part of the CI/CD infrastructure of the organization.

Shimel: Sure. So, guys, obviously – so we call this “DevSecOps,” right? Is part of it.

Grabiner: Yeah, right. Yeah.

Shimel: It’s something that I – you know, between DevSecOps Days and events we put on at RSA and so forth, it’s something we’re very involved in. My question for you then is, so it sounds like Portshift is really aimed at helping DevOps engineers, DevOps teams, developers, get more involved in the security or in the cloud firewall kind of paradigm for security. Is Portshift aimed then at the security team, the developer team, or both?

Ilany: So I think – well, obviously, the focus of Portshift is not to try to educate Dev and DevOps to be security folks – this is obviously not the target – but think the good news is the fact that Dev and DevOps have the knowledge, okay? And the knowledge is where, essentially, they know their intention. They know where, essentially, they want to deploy the application and, essentially, who should talk to who, in terms of application containers or processors, depending, obviously, on your infrastructure. And this is, I would say, the basic assumption that the whole concept of Portshift is based on, okay? We actually take this type of knowledge, okay? We create from this knowledge or this attributes, we create the actual identity of the application, which is essentially a signed infrastructure or crypto-signature of those attributes. And we use those intentions that are described by DevOps, in their own natural language – I mean, a recipe in Cookbooks with, you know, _____

Shimel: A Chef or a Puppet.

Ilany: Yeah, of course. Or Ansible or Kubernetes, obviously, infrastructure. We use this type of information while creating the crypto-identity, in order to deploy those application or signed application in the cloud and enforce the actual security that we describe formally. And the whole point is, essentially, that those folks don’t have to change the way that they work, okay? The security is more intertwined with their own system, the CI/CD system.

We leverage this type of information in order to create the security and the actual security folks will actually define guardrails. Okay? They will define operational environment in high level – the production environment, the testing environment, or the preproduction environment – where the actual application should run within. And the security will be sort of enforced and be visible automatically, without the pingpong, okay, or without the never-ending discussion between the security and the DevOps folks, which we all know it’s part of the problem, okay? It’s part of the challenge of securing the application in the cloud prams.

Shimel: Absolutely. So I guess this – well, let me back up a sec. I just wanna make sure. Portshift, I know you work with AWS, obviously.

Ilany: Mm-hmm.

Shimel: Microsoft Azure, Google Cloud as well?

Grabiner: Yeah.

Ilany: Mm-hmm.

Grabiner: We’re totally agnostic to the infrastructure.

Shimel: Okay. And what – I’m curious ’cause this is something that we going back and forth on, back and forth on. The attitude of the developers, the DevOps teams. I mean, you never meet a developer who says, “Oh, I’d wanna make an insecure application or I want my stuff to be hacked,” right?

Grabiner: No.

Ilany: Mm-hmm.

Shimel: And you’re right – they’re not security people, but they’re security-aware and they need to be security-responsible.

Ilany: Mm-hmm.

Shimel: Right? On the other hand, look, we all know security people who’ve said, “The developers will do what I tell them,” right? “And they’ll be secure when I tell them they’re secure.” But that doesn’t work either in this new world. Right? It’s gotta be together. So you talk about integrating with the CI/CD process. Give us an idea of how you work within the CI/CD process.

Grabiner: Got it. Yeah, so, basically, what we’re doing, we are asking the developers, the DevOps engineers, to use a very simple set of APIs, whenever they are using their infrastructure as a code or whatever the tools that they’re using, to send Portshift the relevant information that we need, in order to identify the piece of application that they’re deploying. This information can be technical information about the build, the version, the namespace of the application, and other attributes, that will allow us to rip up an identity that is unique, for each and every one of the pieces of the application. So this is the first part, where we learn your application logic, where we understand who should speak with who, and we know your business.

Now, when we take this identity and we move into runtime, we see all the different pieces and, first of all, we see them for sure. We know because we find them during CI/CD. If something didn’t go through CI/CD, if a developer deployed a container without asking, if, god forbid, an attacker is moving in the network, we would immediately see that because we signed the components during CI/CD. And we can see them. We can see them communicate. And now security folks and also DevOps engineers, they can easily define their agenda and their rules, based on their application logic.

A simple example: if they want their billing app to speak with their financial database, something that can take days just to config because your application is broken into different pieces and you need to config security groups and make sure you did it right and so on, with Portshift, you would simply write this sentence. You would just say, in English, “I want my billing application to speak with financial database,” and that’s it. Everything will work from then on.

Shimel: So it sounds magical, right?

Grabiner: Yeah.

Shimel: You know, I’m too old to believe in magic. What’s going on behind the scenes, though? When I write that, what’s actually happening behind the scenes?

Ilany: Yeah. So, essentially, what happens behind the scenes is we have two phases for this identity bit generation. As eloquently mentioned by Eran, the first phase is done by offline, okay? We take this type of attributes, which are sort of the intention, okay, in the CI/CD. We grab those as attributes of the identity and this is essentially the description of the application – wherever the application should run, who should it talk to within the actual environment that we’re targeting to.

And then we have the correlation with the runtime properties. Every process, every containers have runtime characteristics – for instance, the process ID, the UID, memory footprint, and stuff like that – so we combine all together the offline attribute that was created with the ICD, with runtime attribute. We sign them all together.

And this essentially creates one unique entity that is running out there and this is what we’re using in order to enforce. We are transferring this type of identity in the traffic stream so that a conversation between two different application is, first and foremost, authenticated, okay, and only then authorized. Okay? This is what we call the classical “zero-trust” approach, okay? We’re not trusting the IP; we’re trusting the identity on the counterpart.

And this brings another where we talked, I believe, a little bit about the operational benefits and the fact that it’s very Agile and useful for the Dev and DevOps and the security collaboration. But there is another very important advantage and it’s the fact that, now that we are not talking about an attack surface which are segments, network segments, we are talking about type of access. Okay? So, if an attacker, for instance, get into one of my workloads or one of my application, we are not losing the whole segment, okay? We are losing a single part.

And now we have, I would say, less – we’re much less concerned from the extent that we are exposed, okay, because we are talking about only point-to-point access permitted. They’re not network segments, which are open and, from the attacker perspective, it’s like a dream come true. If I find a flat network and I get into your flat network in some miraculous way, then I can get into every resource or application that is out there.

Shimel: A good target.

Ilany: Yeah. And this is, essentially, the basic concept of the security perspective of identity-based access control between different applications.

Shimel: Sure. Guys, it sounds fascinating. As I mentioned to you when we started, the time goes very quickly. We’re kind of at the end of our time.

Grabiner: Yeah.

Shimel: I apologize, but maybe we can continue the conversation. For people who are interested, Portshift, you can get more information at portshift.io. Correct?

Ilany: Right.

Grabiner: That is correct.

Shimel: And you guys will be at AWS Reinvent, though –

Grabiner: Correct.

Shimel: – _____ _____ after. Will you be at RSA conference?

Grabiner: Yes. We will also be presenting there, at a startup venue.

Shimel: Oh, the Launchpad or the Sandbox?

Grabiner: The – I think it’s called – I think it’s the Launchpad. Yeah, it’s where all the early-stage companies are. Yeah.

Shimel: Yep. Sandbox – that might be the Innovation Sandbox. Launchpad is more for ideas.

Grabiner: Oh, yeah.

Shimel: I think you fit more in – yeah, we’re a big part of RSA, so, yeah, I just did a podcast with them about both of those, so little bit I know. Anyway – I’m sorry. Thank you very much for joining us and we will – if we don’t see you at AWS, we’ll see you then at RSA. Well, we’d like to probably hear more because this kinda fits right into our sweet spot. Ran, Eran, thank you for joining us on DevOps Chat today. Good luck with Portshift. This is Alan Shimel for devopsy.kinsta.cloud. Have a great day, everyone.

— Alan Shimel

December 17, 2018
DevOps Chat: Container Security and Aqua 3.5 with Rani Osnat and Andy Feit

In just a little more than three years Aqua Security has set its mark in the container security space. With its major new release of Aqua 3.5, the company has again raised the bar with serverless and container encryption upgrades and feature sets.

I sat down with the Aqua Enforcer himself, Rani Osnat, and “Boston” Andy Feit to discuss the details of this major release. Rani and Andy give us an inside peek.

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. Today’s chat is a little bit about cybersecurity, container security, Kubernetes and a major new release coming out of our friends at Aqua, Aqua Security. I’m happy to be joined with the dynamic duo of marketing at Aqua, Andy Feit and Rani Osnat. Andy, Rani, welcome.

Rani Osnat: Hi Alan, thank you.

Andy Feit: Hi Alan, good to talk to you.

Shimel: And just so people know, Andy, you’re joining us from Boston today. And Rani, you’re out in Israel. Is that correct?

Feit: Yes. Yes. Today I am in _____ _____ [Crosstalk].

Osnat: Right.

Shimel: Modern technology. We have a worldwide panel. But guys, the big news is, Aqua just announced version 3.5 of their platform suite of tools. And you know, Aqua’s not a company that every single new time there’s a new release, and the DevOps mantra, you can’t get too excited about any one release. Right? Because there’s always a next one and a next one and a next one. But this is one to get excited about, huh?

Feit: Absolutely.

Osnat: We certainly think so.

Shimel: So why should we be excited?

Feit: Rani, you want to take that one?

Osnat: Yeah, I’ll take this one. So, with every release we make, especially, and in the beginning of course everything’s new. But we’ve been in this space now for three years. Which is not a long time, but in this space it’s a very long time. And so now we’re at the point where we have a lot of large enterprise customers using our product. And we have a market that’s looking for innovation.

And with every new release we try to balance these factors of, you know, offering something new that the market wants. But at the same time ensuring that our enterprise customers can make use of our platform, as they themselves grow their cloud native container implementations. So there is a maturity factor here as well as an innovation factor.

And so on the innovation side, we’re introducing a few significant innovations. First and foremost, risk assessments for serverless functions. Which is a, you know, a kind of a sideways expansion for us into the serverless technology space, in addition to containers. Thinking that you know, what we see as, it’s basically the same teams and the same benefits that are gotten from containers people expect to get from serverless, it’s just another means to get the same end.

And so we want to provide our customers with all the controls they need to address any challenges they have around securing those technologies. And it doesn’t matter if they use containers or serverless or both, or any sort of mixed environment. We also added something that’s innovative in the space, which is container encryption, and we can talk about that.

And then on the side of enterprise scalability and ease of use, we’ve added quite a significant I would say rearchitecting of how we manage both administrative controls on our platforms and what users can do in terms of access. As well as the policy engine to make it a lot more scalable for multicloud, multiteam, multiapplication use.

Shimel: Got it. Got it. Andy, did Rani leave anything out you want to add?

Feit: No, I mean, those are the big pieces that are in the release. As he said. I mean, it’s very much being driven by our customer base and where they’re headed. And you know, in some aspects, it’s the technology elements. Like adding serverless. And in other aspects, it’s really about living with the solution. You know, as our customers, we now have customers that are we think the largest container deployments in the enterprise.

We have some very large users and span of different industries. As they look to roll out, they’re finding they have multiple teams working on these projects. And they need to implement different levels of security. And in many cases, they’re implementing that on different technology stacks. And some are using containers, some are using serverless environments.

And they may be using even different underlying providers of some of the infrastructure. Whether that’s tools for development or the cloud provider itself. And so we’re really, we’re becoming very heterogeneous in terms of what we need to support. And for our customers who, on the security side, are trying to look at that whole context and manage that whole context and have consistent policies, all our consistent reporting across all of them, and not be monitoring 17 different dashboards. It’s important that it be easy to do, to be able to see that whole network of activity. And that’s really what a lot of this release is about.

Shimel: So guys, one of the things that you mentioned, both of you actually mentioned, was the serverless piece. And this is something that we are, we’re hearing a lot about from our readers and from people we speak to. You know, how quickly, and we live in crazy times, right? So the whole container revolution, if you backed up on hypervisors. And now, how quickly serverless is you know, gaining a foothold and people are building around that type of infrastructure.

Osnat: Right.

Shimel: Let’s, just baseline, what are some of the security challenges that you guys are seeing around this?

Osnat: Right. So I’ll preamble that, you know, just add one more thing. There’s, you know serverless has been around almost as long as containers have, in terms of the, you know, its current incarnation of the use in the cloud. But, the use cases is quite different. And while it is gaining traction, the use cases are much more limited than containers. There’s a whole kind of religious war, you know, between the proponents of containers and the proponents of serverless. Personally I don’t believe it’s a zero sum game. I think that both are going to end up being used, and both are going to end up being used in hybrid architectures.

Shimel: Yeah, I don’t think it’s either or.

Osnat: Yeah, I know, but some people would like you to think it is. I don’t think it is. I think it’s both. And so we, but there are some fundamental differences between containers and serverless when it comes to security. First of all, most of the serverless workloads that happen today are cloud based and specific to a cloud provider, right? Mostly Amazon, because Amazon is the larger cloud provider in general, as well as in serverless specifically with Lambda.

But basically you run those functions and it’s quite cloud specific. That’s one area of difference. The other is of course that you know, these are very small single-function entities that can run for a fraction of a second. So when we talk about run time security for serverless, for example, there is a lot less to do there than you have with containers.

Containers are, there are applications that can run, they could run for a minute but they often run for a lot longer than that. With something that runs for a split of a second, there is really only so much you can do when it’s already running. So a lot of the stuff you need to do is before it ever runs. You want to make sure that what you’re running is actually something that is secure, that passed your policy, and that you know about, right?

So when you look at the challenges, one of those is actually discovery. What functions do you have in your inventory, and what are you using them for? The second is ensuring that what’s in them is secure and not vulnerable, configured properly. And that also includes permissions. So, when you define for example a Lambda function to run on AWS, there is a set of permissions you can give it.

And depending on how you configure it, this can be very liberal or not. And of course you want it to be less, the least liberal you can. So as not to allow it to do anything outside the scope of what it’s supposed to be doing. So right now we’re primarily concerned, and that’s also where our customers are, with preventive controls. Basically ensuring that you are, that when you run something you actually know what it is. You know that you’ve approved it. And you can run it safely. That’s the first step in what we think is the right approach to securing serverless functions.

Shimel: Fair enough, fair enough. And back to what you said kind of right at the get go with the either or thing. It was the same arguments about, would container replace hypervisor type of thing. And I think what we see is the majority of people want containers on hypervisor.

Osnat: That’s true. It’s –

Feit: Yeah, and I would also add that the data centers with lots of VMware and hyper-v haven’t gone away yet either. And they won’t. They probably will never entirely go away. New development today is cloud native development. Most of your mobile customer facing development.

It makes sense to do that in the cloud and as long as you’re doing new development, why not do it on the latest and greatest. But, and the flexibility that you get from doing something on containers or serverless or a hybrid approach of those, makes it a lot smoother, easier, scalable. You get all these wonderful benefits. But we don’t see people going in wholesale and saying, I must clean out this data center now. So I think that –

Shimel: _____ [Crosstalk] throw out the baby with the bathwater. And people –

Feit: Yeah.

Osnat: Yeah. So I think that’s one thing that we did. The other, I think very interesting and innovative feature that we’re announcing is container encryption. And I want to explain the use case. So we work with, you know, we work with many organizations. For example, we work, some of our customers are ISVs, who create software for customers to use.

And that software is proprietary IP that they’ve developed and invested in. And they often want to make sure for those reasons as well as for reasons of governance, to make sure only the latest stuff is being used, et cetera, that they have some control over where it’s running and who’s using it. And so one of the things we provide here is an ability to encrypt, you basically encrypt the container image when it’s built.

And then in order to run it, you need to decrypt all its contents, so there’s basically a key that the customer will have, the end user will have. And that will decrypt the image as it’s running. And if you don’t have that key, the image will not run. So the container itself once it’s running is not encrypted. But up till that point, it’s encrypted and you have to decrypt it in order to run it. And then of course this prevents the sort of, someone reusing or forwarding your software and you can imagine various use cases except the ISV one where companies would want this sort of deep security control over their containers.

Shimel: Sure. Sure. And I think it’s just the, you know it’s funny, Rani. I think you said right in the beginning that over the last three years, you know, the progress that Aqua has made, and the progress the whole industry has made in securing their containers. Like everything that’s come before it, right, with each new release, with each light bulb, _____ security we see like more polish being applied.

So, to me this idea of container encryption is you know, maybe first we have to concentrate on just getting the containers to work in a somewhat secure manner. But now we can start thinking about next level, next, you know, how do we turn it up a notch? Things like container _____. What’s the word I’m thinking. Like the standard, the, you know, the container encryption becomes ubiquitous over time?

Osnat: I don’t know if it will become ubiquitous. I mean, certainly today you have a lot of encryption happening with TLS and all the stuff, all the pipes that handle containers. But as for the code itself, you know, even in highly regulated environments, I don’t necessarily see everyone encrypting everything. But certainly there are some crown jewels that you will want to encrypt.

And it’s especially those areas where you’re not talking about reusable components, right? A lot of the containers that our customers use are reusable based on open source components, that’s fine. You don’t need to encrypt your NGINX webserver container, right? That’s, it’s identical to the same, other NGINX containers people use. But if you have proprietary stuff, that’s where you want to, or something that’s especially sensitive, whether it’s for any kind of security, confidentiality reasons, or for IP reasons. That’s when you would want to use something like that.

But what you said actually, you know, brought me to the other topic I wanted to talk about, which is how the use of these technologies has matured with some of the more leading or pioneering companies that we work with, which is why we’ve invested in these scalability, manageability features. So I want to kind of explain what it looks like in a customer environment.

So when we started out, and we started out kind of together with the market, the companies we were talking to, even larger companies, would typically have one or two teams that actually use containers, right? And so, you were talking about isolated projects. And that’s one level of doing things. But as we move forward, you know, now we have customers that have hundreds of development teams working with containers. They make thousands of images on a daily basis, because it’s all in a CI pipeline.

And it all gets, it all goes into this large blender where it’s being spit out at the end, through Kubernetes or mesosphere, basically through an orchestrator to a variety of delivery platforms, whether it’s OnPrem or cloud or a mix of both. And if you look at it from an enterprise perspective, what they want is a way for them to apply security policies but maintain segregation of duties. Maintain compartmentalization and multitendency models that they have. So what we’ve done is really change both our administrative access model as well as the policy engine to enable that.

So basically, you’re talking about people who use the Aqua platform. They have one installation of the Aqua platform. But they can basically distinguish between what different teams can see and do, what different roles can see and do, and how those policies apply.

I’ll give an example. Let’s say that you have an application that is PCI DSS related. Handling credit card transactions. And so it has to comply with certain criteria that are requirements of the PCI DSS standard. You want, and you’re, but at the basis you’re using some basic elements like, I don’t know, MongoDB or MySQL. That same MySQL image that you apply a policy to within the PCI contexts will have a different policy than in non-PCI contexts. So having contextual policy is important.

So that’s one area. The other area is who’s got access to what. So of course the people who handle the PCI application, the developers, the DevOps team, will need to handle certain aspects of this. But they don’t necessarily need to control the policy. That’s expected to be done by the security and compliance team. And the same token, they don’t need to access, or other teams don’t need to access that PCI application.

So we’re talking about a matrix that really separates who’s got access to what and what they can do with that access, according to the specific application or geographic location, or what cloud it’s on or what registry it uses. All of these parameters. So you know, we’ve done this and we have, now both of these models combine to basically give you this matrix that is, that has you know, dozens of parameters on each facet to basically determine who’s got access to what, and who can do, whether it’s view access or edit access or only access to the logs, for example, for auditors and so forth. And so, it’s really a step up in terms of enabling these large deployments to work in an enterprise environments.

Shimel: Absolutely. Good stuff. Guys, I want to _____ two other topics or areas I want you to hit on. One specific to 3.5, one specific to the market. And we’re coming up on the end of our time. So you know, we hear about immutable infrastructure, and you know one of the advantages of a container environment.

So how do you deploy, you know, now you’ve got a bunch of customers. They want to upgrade to Aqua 3.5. Talk a little bit about how do you actually upgrade or run out this upgrade deployment. Is it a question of throw out what you have and just stand up new? Because Aqua itself is containerized. Or is, what, give us a little insight, nuts and bolts if people want to upgrade. Do you know what I’m saying.

Osnat: Yeah. So our upgrade process is you know, it is simpler because we use containers, right? So there’s nothing to install. You simply run the new container. We do have backward compatibility with our previous versions, so when there’s an upgrade path for anyone using older versions of Aqua to this version.

We actually, we’re the last, we don’t, I mean, we release software more often than what some of our customers would like to follow, in terms of their upgrade schedule, right? And we don’t force them to do that. But in the last version, the last major release, 3.2, we actually had a lot of customers move to that. So we’re in good shape from that respect.

And they can of course upgrade to 3.5 when it becomes available at the end of the month. So there’s really no, there’s nothing in particular they need to do except of course, we always, always recommend doing it in a test environment first. And then once you see everything works, you move that to production.

Shimel: Excellent. Excellent. So let me add –

Feit: There’s one more thing now I was going to jump in with, which is, we’re sort of talking about as our organizations of scale and especially if they have multiple teams that are working on different platforms and policies that need to be implemented. In some of these larger enterprises, it’s become very hard to really even see everything and know about it and track, you know, who’s running what and where, and who are these owners. And so one of the things that’s new in the product is a pretty slick interface.

Probably that’s the prettiest part of our product right now. The dashboard’s always looked great. But you can now go in and do what we call workload explorer. And visually view all of your running workloads, whether they’re on Kubernetes or Docker or OpenShift, and you can see everything that’s running across a large distributed runtime environment. And drill down into them, and you can start doing things like highlighting those that are vulnerable or high-risk, and those that are PCI compliant can be coded to jump out, and you’ll see that much more easily.

You can then do tabular mechanisms. Begin to filter. Show them only those running on this platform. Let’s say that there’s a vulnerability that’s exposed in a certain component. You can show me just those, and start drilling down and looking at them, seeing where are they running? Is this one on-prem? Is this one on the cloud? Which cloud provider is it running on?

So you know, as companies have become multiteam, multicloud, multistack, it’s the matrix of what you’re looking at has become pretty complex. And as workload explorers, it’s a great way to just sort of move around in a large enterprise. See what you have and understand what you need to work on right now.

Shimel: You know, and let’s not trivialize it. Let’s not belittle. I’m having a tough time with the word. Let’s not belittle it. You’re a hundred percent right, Andy. Today’s organizations are multi everything.

Osnat: I agree.

Shimel: _____ _____ distributed on so many different levels, that really, having a 360 degree view of, just of the lay of the land, where all this, how it all plays together. That in and of itself, someone could make a product out of. I mean, it’s crazy.

Feit: It’s eye opening for customers. Just in the last, we’ve been working with this product for about a month or six weeks, with some of our early adopter customers. And some of our sales engineers have been implementing it in proof of concept environments. And when the customers see this map, and they, you start drilling down, they say wait a sec – where’s that running? Show me that one.

They’re finding things that they didn’t realize they had because you can now visualize it and see it. You know, when it was coming in as yet another alert or a text field or you know, something coming in to your SIM system, that was one thing. You had to look at the logs and know the query to type. But when you see it visually and you jump in and start looking around, and says wait, what’s that?

And people were, it was eye opening. Okay, I need to go talk to that person. Literally, people were discovering things they didn’t know they had in their environments. And that’s exactly how, in a big environment, this tool can be very helpful in organizing things and showing you what’s out there.

Shimel: Absolutely, absolutely. Guys, that last question for you is not really 3.5 related but more mark related. You know, we seem to be undergoing a, well, it’s constant. But recently we’ve seen just more and more consolidation in the tech vector general within containers, around Kubernetes, you know, IBM’s Red Hat –

Feit: Cloud, right?

Shimel: IBM’s Red Hat acquisition, $34 billion. I mean, is the king of it. But we saw for instance, CA or Broadcom CA, whatever they call it now, spin on _____ for near a billion dollars. To Tom or Bravo. We saw, who, someone just bought, was it _____ just bought a –

Osnat: Later insight, yep.

Shimel: Container something.

Osnat: Right.

Shimel: I mean, at some point, consolidation to what Aqua’s been out here preaching for three plus years. How do you think that affects, I mean certainly now, 3.5, you’ve raised the bar again. Let everyone else try to catch up. But in this atmosphere, talk to us a little bit. What does that mean around Aqua? Or do you just keep doing your thing?

Osnat: Yeah, that’s a good question, Alan. I mean really, I think you keep doing your thing. Because your thing is understanding where customers are headed and building solutions that address what they really need. We’ve tried to keep our eye on that ball. And we’ve been big pushers of the concept of supporting multiple platforms, from the early days.

We were Docker first, but today we support all kinds of things including things, less broadly used technologies. But pivotal, and Microsoft containers. Supporting all the cloud. So you keep your eye on that ball with the goal of building a customer base that is satisfied and loves your product, is excited about working with you.

And one of the things that’s important to us is our customers are going to continue to renew with us and retain. You know, we’ve only been around three years. But we look at, our largest customers are very happy and using us, and expanding their use of us. They’ve put us in a pilot two years ago, and now they’re in production and they’ve put us in production with five applications. And now they’re on 50 applications. So this is all good. We’re not very focused on hey, we must be acquired by some time or we must be public by some time.

It’s, let’s build the right products, continue to see adoption. We’re growing very rapidly, both within our base and customers deploying more, and new names, new logos, that are using our solution. And that’s what’s important to us. And the market, you know, the market will be the market. If somebody says wait, I can’t let these guys get that much bigger. I’m going to try to snap them up. That may happen. But it’s not something that we’re really focused on. We’re focusing on building the business organically in the right way.

I have to say, we’re all old enough to have been through the dot com boom. And you know, the craze that went on back then. And I think it’s important to keep level headed. We’ve been around for three years now. We’ve just crossed the 100-employee mark. Celebrated that. You know, we work with our customers, we’re happy about that. We keep our heads, you know, leveled and we keep doing the work. You know, someone comes along and offers $35 billion to buy us, like Red Hat, I’m sure the board will approve.

Shimel: They might think about it as –

Feit: They’ll think about it a couple of days, you know. But in the meantime, we’re trying to keep things sane.

Shimel: I hear you. Guys, just one last reminder while I have you both on. I’ll see you both out at the TubeCon Native, cloud native, Linux foundation event, along with Red Hat, right? Sponsoring a Monday conference on container security. I think we spoke about it last time. And I just, I don’t want to mess up the date, but I thought it was December 9^th, or 10^th.

Feit: Nope, December 10^th. So it’s the Monday right before KubeCon starts, and it’s collocated with the event in Seattle. And you can register on the CNCF site when you register for KubeCon, or if you already did you can go back there and add on one of these collocated events. Ours is very focused on enterprise security, so it’s called KubeSec Enterprise Summit.

So for larger organizations, facing you know compliance requirements and deploying containers in production, it’s a great way to learn what others are doing. We have a great lineup of speakers. We have, JPNC is speaking. We have Tinder speaking. We have Starbucks talking about their journey towards secure containers. We have Liz Rice and Michael Hassenboss, who wrote the recent book on Kubernetes security. Which is not even published in paper yet, it’s still an eBook, but it will be first delivered in paper form at KubeCon. We’ll have them in our booth, and they’ll be signing books there.

So it’s kind of a great event that people can get exposed to all of these technologies, and hear from a lot of different people. We ran an open call for presentations, so we have everything from technology to compliance to best practices. It’s going to be a great event. We’ve got a couple hundred people already signed up. We only have room for 300. So, if any of your readers do want to attend, they should do that soon.

Shimel: Absolutely. Well, I’ll be there as well. We’ll be reporting for it. Andy, Rani, we’re way over time as usual. I ____ _____, we’ll need to call a wrap here. Congratulations on Aqua 3.5. I’m sure it’s going to be a great benefit, and the customer base will really appreciate it, and we’ll look forward to seeing you in Seattle.

Feit: Look forward to seeing you, Alan. It’s always great to talk to you. And share what’s going on with your listeners.

Shimel: Thank you. Andy Feit, Rani Osnat, Aqua Security. This is Alan Shimel for devopsy.kinsta.cloud, and you’ve just listened to another DevOps Chat.

— Alan Shimel

December 14, 2018
DevOps Chat: Digital Transformation with Paul Chapman of Box

It seems every organization is chasing digital transformation. Some companies are succeeding, while some are wallowing a bit, trying to figure out how to do it. Box is a company that is both successfully navigating digital transformation and being a catalyst for digital transformation at other organizations.

In this DevOps Chat we speak with Paul Chapman, CIO of Box, about digital transformation for both Box and other companies, and he gives us his own take on what the environment is like for companies and what they should do to thrive today. Great conversation, enjoy!

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

Transcript

Alan Shimel: Hey, everyone. It’s Alan Shimel and you’re listening to another DevOps Chat. I’m really happy to have as a guest on today’s DevOps Chat, Mr. Paul Chapman, CIO at Box. Paul, welcome to DevOps Chat.

Paul Chapman: Thanks. Great to be here, Alan.

Shimel: Great to have you here. So Paul, before we jump into a couple of the items we wanted to talk about. I guess in case anyone in our audience maybe is not familiar with Box or yourself, why don’t you just quickly level set your background, Box, and we’ll jump in from there.

Chapman: Sure. Well, maybe I’ll start with just a little background, accelerated bio of sorts. Been in the technology space for quite some time now. I like to joke that although this is the truth, I was a COBALT programmer and an RPG programmer back in the late ’80s. So I’ll fast forward to today and say a lot has gone on in between. I’ve had to reinvent myself many times over to stay relevant. I often tell my team that the pain of change is mandatory. It’s the suffering that’s optional.

So get comfortable with being uncomfortable if you’re in the technology space. It’s never boring. That’s for sure. I’ve done a lot of things in between but thoroughly enjoying my time over here at Box. We’re born in the cloud, grown up digital company. Very forward thinking, innovative. And we’re helping tens of thousands of organizations around the world to help to transform and digitize the workplace.

Shimel: Fantastic. So Paul, you mentioned Box and we talk about unicorns and cloud natives and these kinds of things. Box is certainly a member of the club. And while they themselves, generally, these kinds of companies like box eat their own dog food in terms of what they preach and everything, we almost take for granted the transformative wave that they’ve ushered in. Again, I’m your age or maybe more. I remember the 1984 commercial with the hammer –

[Crosstalk]

Chapman: Mm-hmm. The Apple one, the famous Apple one.

Shimel: The Apple commercial. Sure. The Mac commercial. So in a lot of ways, companies like Box and as their poster child for it have broken through the silos that in the IT world, you and I grew up and kinda held us bound. If you can, give our audience a little bit of – I don’t know if that was intentional that it breaks down silos or it was an unintended consequence but talk to us about how is it helping to break down. How does it usher in what – digital transformation is something everyone talks about. How does it help with that?

Chapman: Yeah. Well, I think when you look at – and I’m gonna sort of just geek out a little bit and share that one of the things that I have – now, we’re starting to see some maturity in what I would call sort of the modern reference architecture for how you run your IT service today or business services today, is that when you look back at sort of the technology that we invested in in the ’90s and in the ’80s, which at the time, was the most modern advanced technology I should say, at the time. Unfortunately, it was architected in such a way that it was very siloed and you ended up sort of building up these sort of monolithic sort of application stacks where you went to sort of the oracles for everything or the SAPs for everything and it was very hard to integrate.

And unfortunately, what happened is is you sacrificed a lot of what I would call best of breed capability and innovation in that model and because that architecture doesn’t, in a sort of step wise, linear way evolve to support today’s way of working – today, we have a new style of employee. One that has grown up digital that’s been educated by consumer experiences that expects a certain set of things when they enter the workplace. You have a new style of workplace. It’s very open and social and collaborative.

You have this new style of IT that’s evolved to support that. And when you look at what’s actually happening, the modern architecture is built around this best of breed ecosystem and there’s innovation going on everywhere. But the innovation is generally organizations are picking the area that they’re gonna be the most innovative in and they maniacally focus on the innovation in that space. So they’re the best at what they do and Box is absolutely the best at managing unstructured content for the enterprise with the best compliance and regulatory and so on. And security and risk and all those things.

And then there are other companies that are the best at messaging and then there are others that are the best at certain types of collaboration. And what we get to do now is to start to bring all these services together because they’re built to interoperate which the architectures of yesteryear weren’t and we get to bring and curate that into the experiences we bring to our employers, partners, suppliers, and customers and therefore, we’re starting to create more automation, more digitization across this best of breed ecosystem. Long winded answer but there’s a lot going on in there today.

Shimel: Oh, absolutely. So let’s pick into a couple of those areas. Number one is lock-in or the – we used to suffer with these large stacks. You were locked in though. Right? I was talking to someone earlier today, a start up who managed Macs for enterprises. Right? And why haven’t we seen that before? Well, maybe there were enough Macs. But we’ve all suffered from lock in in our technologies.

Chapman: Yeah. And we don’t like it. We don’t like the way it makes us feel. We don’t like to feel captive or without choice and really today, freedom of choice is extremely important. And so what I do know, though, and this is something that I’ve certainly come to appreciate is especially if you are, as you think about a much more heavily cloud based footprint, you have the freedom from infrastructure. You have the freedom from direct sort of operational responsibilities that in our past lives, we have significant operational responsibilities managing a lot of technology debt and infrastructure and so on and we had to manage service levels, capacity, performance, backups, failover, all the things that are just really keeping the lights on.

We’re not adding any material value necessarily directly to the businesses. It’s the things, the services that run on top. And so what I’ve seen is is that now as you start to move to a cloud based model which is much more subscription based. The on ramps are a little smaller. The off ramps are a little smaller. The ability to change out services for services that may not be as innovating as fast as others as is a little easier but I think the key thing is this. Every one of those services that you subscribe to, it’s a mutually beneficial outcome. They have to earn your business on an ongoing basis.

Shimel: Yep. On a minute by minute. Not even daily.

Chapman: Because if not, the subscription stops and you move it somewhere else and if they are not maniacally focused on innovating in their space, having highly reliable, scalable services, having services that meet your compliance and regulatory requirements and having services that meet your trust and risk criteria for that particular service, they don’t have a business. And so the beauty of this model or this new emerging model, I should say, is that in the old ways, they’d sell you software and then you sort of … you get locked in and it’s hard to move. Now, we think about it as all the time. It’s about the customer all the time. How are we making our customers get more value from their investment in us and how can we make sure we’re providing reliable services and innovative capabilities that they’re subscribing to to maintain them as a customer. And that’s good for us.

Shimel: Absolutely. So I would even go further, Paul. I’d say the hardware vendors locked you in more than the software guys even did. Right? When you made decisions, whether you were on Solaris or this flavor of Unix or Microsoft or what have you or HP, I mean, HP, and I know you used to be at HP, no disrespect to them, but they were really good at talking about freedom and best of breed while locking you in tighter than a drum. But today, so to me, this all refers to something that I call portability. We have, as consumers, as customers, we have such portability today where we can take our stuff up and go. It’ll run anywhere we want, just about.

Chapman: That’s a great point. Actually, a really good point. And the infrastructure, I was focusing on the services piece but you’re absolutely right. As I mentioned, the freedom from infrastructure in the cloud world is like no offense to the infrastructure providers. It’s just I add more value to my organization when I’m not focused on those things. It’s a give back of time and one of the most precious things we can give anybody is time. And I’m able to use that time to do what I would consider much higher value, contribute at a much higher value to the organization because of that.

Shimel: Absolutely. Paul, I wanna transition to another topic that we spoke of but I think you gave me a great segue here and that is that when we talk about things like transformation and thriving and leveraging what we have, what the technology world has to offer us today, so much of it, frankly, isn’t hardware or even software. The success or failure of organizations is often based on their culture and their people. Right? And some, we live in a gee whiz world where we take things, we were talking off hand about answering the doorbell from China, but organizations can’t really thrive, compete, and transform without that cultural sort of happening. Curious on your thoughts on that.

Chapman: Yeah. Probably … at Box, we talk a lot about the future of work and also, we talk a lot about it’s not about rewriting your software. It’s about rewriting your company. And when we look at companies that … if you look at just some of the statistics, 52 percent of the Fortune 500 have disappeared since the year 2000. And if you do the math, that’s more than one per month. And a lot of people get into this techno-panic thinking it’s technology that’s disrupting these companies but the reality of it is is technology is enabling that disruption but the technology that’s doing this is available to everybody including the incumbents that have built their business models and their operating models on sort of a sort of legacy way of working. And you have – if you look at the companies that are disrupting, it’s because they have a different operating model. They have different business models.

They operate culturally very different and the cultural shifts are really, really hard, especially in organizations that have become very established in their markets because that’s what got them there. And the reality of it is we used to coin this term sort of this frozen middle part of an organization that didn’t necessarily have – doesn’t necessarily have aligned incentives to change. Because it’s like what’s in it for me on the other side of this change? And they say at any given point, a third of an organization, and this changes, varies from company to company but a third or an organization knows where you’re going and how you’re gonna get there. A third doesn’t but they’re willing to learn and invest and figure it out and a third doesn’t, never will, isn’t interesting, da, da, da, da. And that’s resistance.

And the resistance to change has to be resolved. A lot of companies will figure out maybe what they need to do and even why they need to do it but it’s the execution of the how and sometimes, that how is where it really holds people back because they realize that they may not be able to get there with the culture and the people they have. And they switch out leaders and so on and I can share some more in what I’m seeing companies that are able to do this successfully. Most of them, it does take sort of what I would call sort of breaking the company somewhat in order to ______ them.

Shimel: No, no, no. You gotta burn it down. Right? And I don’t wanna burn it down. But there has to be fundamental change. Last question because I know we’re running low on time but how important is leadership? Right? As a CIO, this is kinda your … this is a big part of your role, right? But how important is leadership in making that transformation?

Chapman: It’s absolutely key. You can’t do it without the right leadership mindsets and call it coalesced support. So I’ll give you a recent example that I was talking to a CIO of a very, very large company that had been struggling with, call it, reinventing itself and reestablishing itself in a new modern digital world and was starting to make some, is starting to make some success there. And one of the questions that we often get asked as CIOs is, “What’s your partnership model look like or your engagement model look like with the business and how do you think about change management?” And like I said, I went to school to learn how to do programming and COBALT and RPG. I never went and got a PhD in change management.

[Crosstalk]

Yeah. I’m not an expert at trying to change the mindsets of thousands of people across an organization when at least a third of them, based on our numbers, don’t even want to. Right? I’m jesting a little bit. The CIO is one of the best partners to enable change but isn’t necessarily always in the best position to drive that change across the organization. You have to have leadership alignment and so on and the company I was talking to, I was talking to the CIO and he was asked that question. “What’s your – people are interested because they’re starting to see meaningful change.”

And they asked him about his relationship model with the business and he said, “Here’s what happened. When we got our new CEO, he went to all of the heads of all the different business functions that we have and said, ‘If we are going to transform, if we are going to think like a digital company, if we’re gonna think like a technology company and we’re gonna disrupt, it’s incumbent upon every single one of you business leaders not for IT to come to you and say, ‘Here’s what our model for working with you is.’ It’s what is your model for working with IT? What is your model for working with the CIO?’”

And he said that once that accountability came into the business owners, he said it just greased the runway for the CIO and organization to enable accelerated change across the organization because it wasn’t incumbent upon the CIO then to drive that change. It was to enable the change. And I actually think that that’s something that is key here is we have to rethink the model of how we engage and operate, not just it’s a technology solve.

Shimel: Right. I agree with you. First of all, I wanna apologize for taking up much more time than I think we booked but it was a great conversation. It was kind of fascinating. Maybe we can have you on on another chat at some point or through the other vehicles we use. But look, continued success with Box. We’re customers.

[Crosstalk]

devopsy.kinsta.cloud only for our most important data. But anyway, thanks for being our guest on DevOps Chat today and we’ll speak to you soon.

Chapman: Appreciate it. It’s fun hanging out.

Shimel: All righty. This is Alan Shimel for devopsy.kinsta.cloud. Thanks for listening. This is another DevOps Chat. See you soon everyone. Take care.

— Alan Shimel

December 7, 2018
DevOps Chat: Promoting Innovation at the RSA Conference

RSA Conference is where the world comes to meet Security. For the last 14 years, the Innovation Sandbox Contest was where you could find out what the up and coming companies in security were up to.

This year RSAC is doing something else in addition. The Launch Pad is where to come to if you have a great idea. You can pitch to VCs, the community and your peers – get great feedback.

In this chat we speak with Cecilia Marinier of RSAC about Sandbox, Launch Pad and so much more that is RSAC. Listen to the chat, go to RSAC and enjoy.

Transcript

Alan Shimel: Hey everyone. It’s Alan Shimel, devopsy.kinsta.cloud, Security Boulevard and you’re listening to another DevOps Chat. Today’s DevOps Chat is gonna focus on well, what for me is my favorite conference of the year, the RSA Conference in San Francisco, which this year is the week of March 4. And one of the great things about RSA conference is there’s so many things going on. I’m happy to be joined actually by someone from the RSA conference team. Cecilia Marinier, Marinier. Cecilia, I hope I didn’t mess that up terribly. My French is … that New York accent just doesn’t work with French. I’m sorry [laughs]. But Cecilia, you there?

Cecilia Marinier: I am here. Thank you. And you did a great job with my last name. Thank you.

Shimel: Why don’t you say it right, though, for everyone?

Marinier: Okay. So my name is Cecilia Marinier.

Shimel: Marinier. Oh, you can almost taste the French food in the way you even say it. Anyway, I just got back from France, Cecilia and so I appreciate it. But you’re with RSA Conference. Why don’t you give our audience a little bit of background on what your position is and your own journey on how you got here?

Marinier: Absolutely. Thank you. So I work with the RSA Conference. I joined them about five years ago and I started actually working with just the RSA Conference Innovation Sandbox content having a strong interest in innovation in cyber security. Prior to that, I was working with a small boutique consulting firm that consulted US government clients on security intelligence issues and one of the main focal areas was cyber security, which is what drove my interest into actually joining RSA conference. And tying that together with innovation is just how I got started on this journey and from there, it’s just been a super wonderful ride with RSA conference. Just keep on building out these incredible programs focused on innovation.

Shimel: Correct. So I’ve had the pleasure of being involved with the innovation sandbox contest now for a number of years. I would say it’s gotta be going on what seven or eight years they’re doing it? Maybe more at RSA already?

Marinier: Yeah. Actually it’s 14 years.

Shimel: 14.

Marinier: This is our 14^th year.

Shimel: Oh my God.

[Crosstalk]

Marinier: I know. But it started off under – [laughs] I know. Well, it started off under a different name back in 2005 and then in 2009, it actually changed into the current form, which is the innovation sandbox contest. But there were really incredible company that came through that you might recognize like source buyer and Imperva in those first couple of years so it’s –

Shimel: I remember those years. And maybe that’s why I said seven or eight years because since they’re using their name, the Sandbox. But in any event, we’re very careful to use the name Innovation Sandbox Contest because we don’t wanna confuse people. Again, there’s so much going on at RSA conference. There’s also the RSA Sandbox where people kinda have hands on experiences with different tools and so forth and security, and cyber security. Correct?

Marinier: Exactly. The RSA Conference Sandbox actually hosts three sandboxes, plus sands _____ _____ and each sandbox has these hands on activities and it’s in the internet of things. IoT village. It has also ICS village looking at _____ systems and finally, we are – this year, we’re bringing in wireless hacking village too. So it’s a really exciting time for the sandbox in addition to the innovation sandbox contest.

Shimel: Absolutely. That is exciting. I remember seeing it last year. That’s some great stuff. But when we talk about the Innovation Sandbox Contest _____ _____ for those of you maybe from my DevOps audience or who have not had the pleasure of attending RSA Conference, it really is a showcase for new technology, for new sec companies to get in front of some of the top, top people who are judges for this contest and really show them what you got. Right? And like you said, companies like Imperva and Marty’s _____ source fire and many others have been recognized over the years at the Sandbox Innovation or Innovation Sandbox contest. So it really is great.

Why don’t, if you can, Cecilia, let’s talk a little bit. What is the process? How do the companies get selected? How is a winner picked? Give our audience a little insight?

Marinier: Absolutely. So right now is the submission period and right now, any company that is less than five years old and less than $5 million in revenue can apply online for the contest and there’s an application process. You send in a 3 minute video that can be taped in your offices. It doesn’t have to be professionally made. And all those submissions are then sent to the judges and our judges are extraordinarily awesome this year. I’m really proud of the diversity.

So one of the things that we do when we’re looking at Innovation Sandbox Context to ensure that the company will be successful, is we have all the people who are interested and understand what it takes to make a successful company. So we have our venture capitalist. We have our siso who’s the buyer. We have an entrepreneur, a veteran entrepreneur who this year is actually Shlomo Cramer who has been a –

Shimel: Who?

Marinier: Veteran on the stage. Shlomo Cramer from Cato Network and Imperva and Checkpoint. So Shlomo will be our entrepreneur and then we also have a chief strategy officer who’s representing what it’s like to be a buyer inside a large company. So we cover the gamut of what will it take to actually take this to market and I think that’s one of the – why this is always choosing very successful companies. Even most recently, if you look at Phantom which was acquired by Splunk or if you look at Unify ID who won in 2017 and they received good funding right afterwards, it’s a great Launchpad for a lot of different – I shouldn’t say Launchpad. It’s a great place for companies to actually showcase their latest products. The only other caveat is the product has to have come out between December 1^st 2017 and December 1^st 2018. So we’re looking at those start ups that have launched their product and if they’re ready to go to market, they can apply online for Innovation Sandbox Contest.

Shimel: Excellent. Excellent, excellent, excellent. I will include the URLs for all that, guys, with the show notes here in the podcast. And Cecilia, I really should chime in in that yeah, there’s been a lot of quote on quote famous companies that won but what I always loved about the sandbox contest was the pure democracy of it. Right? It’s really as open to any company that’s under five years and under $5 million and the three minute limit on the video, they mean three minutes. I, myself, have worked on these videos in the past and I know we’ve word smithed them and talked faster to get as much as we can in on those three minutes as possible but it really is.

You don’t have to be a blue chip VC-backed company here to invest or to enter and even to win. There’s been companies that weren’t DC backed at the time over the years that have won, if I’m not mistaken.

Marinier: Yes.

Shimel: Yep. And I remember – and wound up leading where – it’s hard to draw. It’s a dotted line but it wound up leading to those companies getting funding as a result of winning as well. So it really is. It’s a prestigious thing to win. Now, if someone’s out here listening and say, “Oh, I may go to RSA Conference this year,” and by the way, if you are, there’s some discount codes available on Security Boulevard and devopsy.kinsta.cloud through our RSA Conference partnership, if you are looking to attend. But if you are looking to attend, Cecilia, how can the attendees interact and see what’s going on and participate in Sandbox Innovation Contest?

Marinier: Well, actually, the conference itself has really made big strides in trying to build an ecosystem around innovation. So in addition to the Innovation Sandbox Contest, which does have a break while the judges is evaluating the companies to chose a winner and the attendees for that particular event can go meet the top 10. There’s kiosks there. But in addition, we’ve created a couple other opportunities for the attendees to see what’s happening in innovation and cyber security and one of those areas is called the early stage expo. And this area has 50 startups this year. We’re up to 50 startups and it also has a small briefing center and yeah, it’s an amazing opportunity. It’s located right next to the sandbox that was talked about earlier and it runs from Tuesday through Thursday so you can check the hours online for that.

Additionally, if you are an entrepreneur but you’re not quite there yet and you wanna learn a little bit more about how to become an entrepreneur, we have a half day how-to seminar on Monday which covers how to get funding, how to get in front of the busy CISO, how to go to market and the journey of an entrepreneur. So all of these are elements that are tied into what’s going on in innovation itself. And then also, additionally, we have this new event that we’re launching which I’m pretty psyched about which is called RSA Conference Launch Pad. And I’m happy to share more about that with you right now or we can wait and put it on hold and I’ll tell you a little bit later [laughs].

Shimel: No, no. Go ahead. That cat’s out of the bag. Let’s go.

Marinier: All righty. So the thing about RSA Conference Innovation Sandbox Contest that we noticed was that we’d had a lot of strong, solid companies that I would almost say later stage startups. What we thought would be really cool and what we saw in some of the submissions that were just in the cusp of getting ready to launch their product but had not quite done so yet and so they didn’t qualify during that year. And what we wanted to do was offer them a different opportunity, which, again, is to get in front of this audience but this time, they’re going just in front of three venture capitalists and there’s three very strong venture capitalists based here in Silicon Valley that their names are gonna be really well-known when you see them.

And this is kinda more like a “Shark Tank” kind of event where you’ll go and they’ll be pitching in front of the audience and maybe one of these venture capitalists might just put some money towards one of the companies. There will only be three of them. It’s not a winner take all. It’s literally just an opportunity for people to see what are the venture capitalists interested in, what kinda questions are they asking, and then also to kinda get a glimpse into an earlier stage start up. So it’s really fun and exciting and that’s on Tuesday afternoon and that will be a really fun event as well.

Shimel: Excellent. Excellent. You know what amazes me, Cecilia? So I’ve been in the – we’ve spoke off mic and I’ve been going to RSA Conference since like 2002, 2003 maybe. And what amazes me is I remember back in maybe around 2005 or 2006, I had started something called the Security Bloggers Network. We had our security bloggers meet up every year. This is when blogging about security was first becoming really popular, ’04, ’05. And RSA Conference, actually, was a catalyst and a sponsor of this back then. We’ll be doing it again this year. I think it’s the … I don’t know, 15^th or 12^th. I forget how many years. We’ve been doing it a long time.

Anyway, we were talking back then and I remember hearing people say something like, “Do you know there are 600 or 700 security companies in the world? There’s no way the market can support that many …” We didn’t call it cybersecurity. It was InfoSec. “There’s no way the market can support that many InfoSec companies.” And now, we look at RSA Conference today and there’s something like 500 companies or so exhibiting at RSA in that range. And we –

Marinier: Yeah. There is.

Shimel: Do you know the number? I don’t.

Marinier: I believe there are 600 going to be on the floor this year, plus the 50 at early stage expo. So over 600 is what I was –

Shimel: Well, there you go.

Marinier: Comfortable saying over 600 for sure [laughs].

Shimel: Yeah. So there you go. There are more than that just exhibiting at RSA Conference this year so the growth in the market. But to give them something like this early stage expo is really such a leg up because you know what? I’ve been on both sides of this from this divide and it’s not cheap. It’s not cheap going to any conference in San Francisco. It’s not cheap exhibiting at a conference in San Francisco. And I don’t mean to single out San Francisco. It’s not cheap, period, doing conferences. And but in the case of RSA, it very much is a question of, “Well, if you’re not there, people ask why. Are you really a player? Are you serious? How could you not be at the biggest event of the industry?”

And so giving them a sort of fast track, and quite frankly, a bit of a discount to get your foot in the door, it’s a great thing. So kudos to RSA, to RSA Conference for doing this and I think it’ll be really cool. I encourage people to go check out some of the folks in the Launchpad because that’s where you’ll find _____ _____.

Marinier: And also, yeah, in that early stage expo area, it is exactly like you said. It’s what we’ve heard from the people who are exhibiting in that area is they love it because the people who come into early stage expo are really interested in learning more about each of the companies and they’ll stop. And the kiosks are not that large but they all have just an interesting background and story and there’s a lot of people that walk through and just really enjoy getting to have that personal attention from the CEO of the company because they’re so – these companies are so small that you’re meeting the CTO. You’re meeting the CEO. So it’s really a cool little area. I really hope that your listeners all get to stop by and check it out.

Shimel: Absolutely. And just to be clear, usually the expo floor for RSA opens up the Monday night, which I think is March 4^th this year.

Marinier: It is.

Shimel: Will the innovation area, the Launch Pad area and Sandbox be open Monday?

Marinier: No. So Innovation Sandbox Contest runs from 1:30 PM to 4:30 PM on Monday, March 4^th.

Shimel: On Monday.

Marinier: Yes. And it closes and then that’s when we go over to the welcome reception. We encourage people to go over to the welcome reception at the Moscone. We’re actually going to be at the Marriott this year so please come to the Marriott.

Shimel: Oh, okay.

Marinier: That’s where we’re gonna be for all the innovation –

[Crosstalk]

Shimel: Okay. I didn’t know that. So they are still using Marriott this year. I thought the construction on Moscone was gonna be finished and everything was moving in.

Marinier: I thought so too and the construction has –

[Laughter]

The construction actually has been promised to be done but the area that they were anticipating, the thing that Innovation Sandbox Contest has grown so big that we need to have this size room that can hold 2,000 people and so that’s why we’re there, we’re over at the Marriott this year. And hopefully, in the future, they’ll be able to – it will change and we’ll all be in the same area but the Marriott is really close to Moscone West so I hope –

Shimel: Oh, no, no, no. It’s right around the corner between Jillian’s. You go Moscone, Jillian’s, and the Marriott. And I should also mention that also Monday starting at 9:00 AM in the morning, I’ll be running for the fifth year, our DevOps Connect DevSecOps days event in Moscone. RSA Conference obviously puts us on and I was lucky. I got moved to Moscone last year, Cecilia. We were like the first people in this beautiful room up in … I guess it’s Moscone North. It’s a brand new section. It’ll be up there and I think it was us and the Cloud Security Alliance. We were right next to each other and …

Marinier: You’re making me jealous. You’re making me jealous, Alan.

Shimel: I’m sorry. I don’t wanna rub it in but I was told we’ll have the same room this year. So we start at 9:00 AM. We’ll run through 4:00 PM but there’s plenty of time to run back and forth here from the Marriott to the Moscone. It’s literally a couple of steps.

Marinier: Yep. It’s very close.

Shimel: So I encourage everyone to do do both. And then the launch pad is … will run through the whole expo?

Marinier: The Launchpad is the event on Tuesday with the sharks, with the venture capitalists and then the early stage expo areas opens right after that as Launch Pad closes. As soon as Launch Pad finishes that event, we open the whole space, the Sandbox and the Early Stage Expo. Actually, it’s opened with the Cyber Ops, which is kind of a fun little networking event in addition to opening the space. And then it will be open from 8:00 AM to 4:00 PM on Wednesday and from 8:00 AM to 3:00 PM on Thursday.

Shimel: Fantastic. Well, Cecilia, when we started, I told you that once we start talking shop, the time just flies. So I’m sorry to say that we’re about out of time. But just man, I’m already really pumped for RSA Conference this year but I always am but I’m really excited for what’s going on with the Sandbox, Innovation Sandbox Contest, the Launchpad, the Startup Showcase. If you’re not moving forward in this business, you’re dying, as they say, right? And RSA Conference continues to move forward in being innovative and getting these new companies a shot at getting their bite at the ring or grabbing the ring or whatever you wanna call it, bite at the apple. So congratulations to you and the team for doing this and thanks for doing it.

Marinier: Thank you.

Shimel: And we’re looking forward to it. We’ll be there. We’ll check it out. Maybe we’ll report. There’s a good chance we might be on Broadcast Row over in Moscone West during the week doing some video broadcasting. And if so, maybe we can get you and some of the folks from the Sandbox contest and the showcase in and we can make them movie stars or at least YouTube stars [laughs].

Marinier: Sounds great. Sounds great.

Shimel: All righty. Fantastic. Cecilia Marinier. Close?

Marinier: Excellent. Very good.

Shimel: I’m getting there, man.

[Crosstalk]

A French model on the internet like the commercial says. Anyway, Cecilia, thank you so much for being our guest here on DevOps Chat. Good luck with RSA Conference. It’s coming up in a few months. Hey, Sandbox Contest applications are available if you’re listening. Go do it. And you’re eligible and you think you’ve got a shot here, I would encourage you. But for now, this is Alan Shimel for devopsy.kinsta.cloud and Security Boulevard and you’ve just listened to another DevOps Chat. Have a great day everyone.

— Alan Shimel

December 4, 2018
DevOps Chat: DevSecOps with Signal Sciences’ James Wickett

James Wickett is the man to go to for DevSecOps. The founder of the Rugged DevOps movement, which has merged into the DevSecOps group, James is one of the most knowledgeable people on the subject of DevSecOps.

In this DevOps Chat, James shares his views on what’s on the horizon for DevSecOps and the most important things we can do to make our teams more secure. Have a listen as James gives us his take.

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, Security Boulevard and you’re listening to another DevOps Chat. I’m really happy to be joined on this DevOps chat by one of my friends from the Austin boys, James Wickett. James, welcome.

James Wickett: Hey, thanks Alan. Really glad to be here.

Shimel: It’s my pleasure to have you here. So for those of you who may not be familiar with James, you know, James is really one of the lynchpins in the, for my money, the best DevOps community in the world and it’s the folks over in Austin with Ernest Mueller and James and Karthik and Boyd and just a whole bunch of great people coming out of Austin. But when James isn’t busy building the best DevOps community around, he also works at Signal Sciences and of course James was also kind of the founder, prime mover behind Rugged DevOps and now DevSecOps, as well as with Shannon and those folks. So, I hope I didn’t make you blush, but –

Wickett: That’s all right. We loved having you come down to Austin and we’re pretty proud of the – you know, it feels like the InfoTech community here in Austin is really close knit and there’s a real family dynamic to it, to a certain sense, the good kind of family. I know that can be different for different folks, but you know, it’s very nice that we’ve been able to do that for so many years and we’re excited for bringing DevOps days Austin, continuing to come back year after year, and your partnership with that has always been great, Alan, so we –

Shimel: Yeah, no, it’s my pleasure. I don’t say it lightly, especially this past year and a half, two years, I have probably been to more DevOps days and DevOps events around the world, not just here in the US. And Austin’s a special, special place for it. James, as we were talking off camera a little bit, you know, over here at devopsy.kinsta.cloud and the rest of the media op sites, we’re doing an event called Predict 2019 and it’s a virtual conference. It’s more than just kind of like a video like this where it’s actually a virtual conference where the sponsors have booths and there’s a whole session auditorium and everything, but the idea behind it is really to put on our crystal ball hats and take a look at, hey, what does the near term future look like? You know, if we’ve been in tech long enough, we know better than to make a long-term future guess.

Wickett: That’s right, that’s right.

Shimel: Right? Who knows? But, near term we’ll try. So, I wanted to spend a couple minutes with you and talk about what do you see 2019, the next 12 to 18 months. What’s factored in on the DevSecOps scene, on the DevOps scene, on AI Ops, on you know, just what we live in day to day, James?

Wickett: Yeah, yeah, that’s right. Yeah. Well, that’s a good question because when you think about DevSecOps and where it is today, I think, I always hope that we’re further along than we are, and the data still shows that like we have some ways to go. There is a SANS survey on secure DevOps and kind of the joining of just security and DevOps and where it is in the current state of the world and Signal Sciences, along with several other sponsors, are happy to kind of be a part of that survey and that research, but one of the things that is pretty astounding out of that whole piece is that 95 percent of securities responsibilities or 95 percent of security people reported that their main kind of thing they were doing was supporting legacy applications.

So, and it’s real telling that we see this – we’re seeing really in security and DevOps kind of the same problem we had with Dev and Ops, you know, ten years ago, right, this whole throw it over the wool mentality, you know, different groups value different things. Developers valued feature speed and deployment ability, I guess. Operations valued stability, reliability, things like that, and they always felt like they were at odds. Well, security comes in as sort of this third wheel here and what does that do to the mix?

And I always – I’m really happy like to be spending time with some of our customers at some events and I get to hear stories of people doing things that are radically different than securities done over the last decade, but to say that that’s not – to say that that’s ubiquitous would be false. Like that is just not where we’re at right now and I think it goes back to that quote, right, and I think this helps us with this 12 to 18 month prediction piece. Like the future is here, it’s just not widely distributed. Right?

So, I can see what leading high performing companies are doing and I can just say, next 12 to 18 months is like more people doing some of that stuff, and I’m excited about that.

Shimel: I agree with you. You know, James, this is something that I, you know, I’ve always kind of felt is that, you know, we certainly suffer from shiny trinket syndrome and we always want to know what the next great thing is or what’s the next big thing. But what we often forget about is the whole world isn’t a green field. It would be so great if we only had green fields and new apps to work on.

Wickett: That’s right.

Shimel: But we live in a world of legacy apps, right? We’re going – no one’s throwing out their mainframes. No one’s going to just throw away all of these applications that have been built. Excuse me.

Wickett: Yeah, we live in the brown field, Alan.

Shimel: Right, we live in a very, very brown field and so to me, should we be focusing near term at modernization, right, and how are we – because at the same time we have these legacy apps, James, we have such new infrastructure possibilities with, you know, so how do you containerize and Cubernettisize and make servo lists, all of this brown field application and at the same time, I really think that’s an opportunity for security.

Wickett: That’s right, yeah.

Shimel: To come in and let’s do it right. Right?

Wickett: Right.

Shimel: Let’s fix something that really wasn’t set up right the first time.

Wickett: Well, and the inverse or the – there’s another layer to that problem is that we’re seeing people in the security space that are almost cutting edge for like what we would call like DevSecOps and people that are doing great, but they’re all coming from like large enterprises, which is a really weird thing because innovation from the DevOps space came from like small, medium sized companies that were able to be nimble and be fast, but when you’re at a certain size, you don’t have security talent on hand. You don’t have anybody on staff and you’re also – you have a different set of concerns. Right? Your concerns are staying in business for the next several quarters.

Shimel: Right, keeping the lights on.

Wickett: Right, when we’re seeing people like Shannon Lietz over at Intuit or we’re seeing Topo over at Capital One, right, or Chitra Elango over at Fannie Mae, right, we’re seeing these stories and the way that people are piecing together pipelines and they’re tying all these security things into these DevOps movements. They’re all coming from big companies and I don’t think there’s – I think there’s definitely a connection there. We’re going to see some of that security wisdom and kind of learning of how to do DevSecOps come from the other end of the spectrum, which I think is a really cool thing.

If you’d have asked me three years ago, I would not have predicted that at all.

Shimel: No. So I’m going to tell you, along those same lines, James, to me, this may wind up being the hidden gem or the hidden legacy of DevOps. When I first launched devopsy.kinsta.cloud and you were around, you remember, you know, besides everyone yelling about making a commercial, there was this huge argument raging between people about startup DevOps versus enterprise DevOps, you know, could enterprises do DevOps, was it a unicorn thing? And you know, some of the – I always felt that the right answer was, there’s only one DevOps. Right? There’s not a startup DevOps and an enterprise DevOps.

But, different organizations have different things. I think what we’ve seen over the course of evolution is that yes, DevOps really kind of took hold in the small midsized businesses out of necessity, but enterprises shaped and molded it and made it work at these large enterprises, and in doing so, created opportunity for the security folks, the QA folks. Right? All of these other silos, right, that maybe you didn’t have in a small company, right, because everyone wears like seven hats.

Wickett: That’s right, that’s right.

Shimel: Right? But, at the enterprise level, it’s giving it a chance to flourish and to – it’s like a giant petri dish, right, and so it’s great and it’s giving security people a chance to get in here. So –

Wickett: Well, and you look at, you know, you have a vision of like, hey, let’s put this for, this is not just for startups and west coast companies. This is something that can hit across – and I love that. I love going to middle of America, DevOps Days events like the Kansas City one was quite _____.

Shimel: Kansas City was pretty cool, yeah. Right.

Wickett: And I liked it because it’s people at larger companies wrestling with these problems, trying to make this happen and I’ve been lucky enough over the last several years of my career to do a lot of green field type stuff, but that’s not the yeoman’s work. The real tough work that we’ve got to do is DevOps transformations in these large enterprises. And you and Jean Kim through the DevOps Enterprise Summit we see stories of these types of transformations happening and seeing security being brought into that. I mean, it’s just–it’s really pretty cool.

Shimel: Absolutely. So, now not to prod you along here, James, but –

Wickett: Yeah, prod me. Prod away.

Shimel: I see it, so we’ve had a chance to build a little bit of a foundation. Right? We see these things happening at the enterprise level. Kansas City, Chicago’s another great example. Big companies, right, talking about their DevOps and their DevSecOps. How do we build on this momentum, James? What shape does that take? As security people, what do we need to do to move that needle?

Wickett: Yeah, that’s a good question. Let me – can I take two answer on that and –

Shimel: Sure, take three if you want.

Wickett: Sure, all right, good. Well, I think there’s – let’s start with the first answer. I think we’re still developing a mental model or some sort of platform of like how the delivery pipelines work. I mean, of course you can go to any number of talks, you can see how our people have assembled them, the tooling that they’ve put in place, but security has a lot of success whenever they can look across the – whatever the software delivery value chain and say, “All right, how are we delivering the software and where is our build system or our development process and then how do we deploy and deliver all the way to the customer?” And look across the broadly and find discreet tools that they can add in those places, and not just tools for like software, but like practices or ways to transform. Take the ISC squared, CISSP manual and rip out a good – a lot of the waterfall bits, but figure out like were does this change, like in the modern world? And I think that’s – I’d say that’s like the first approach that I would like to say.

I think philosophically, I would – I’ll kind of answer you with a situation that I was posed with recently. A friend of mine, he works at a large enterprise company. They are not cloud, just now thinking, “Hey, maybe we should do this cloud thing.” And which I – some people that are listening to this are like, “What?” But that’s just the way it is. People are –

They have so much investment in the data center that like now it’s like they finally kind of said, “All right, we have some new stuff that we’re building. We think the cloud is where we should do it and we’re hearing these things like Cubernettis and servals and containers and whatever.” Right? “So we’re trying to figure out what direction we take with all this.”

So now some of these companies, legacy type companies, are putting resources towards it. Well, this guy is a security guy and he had them kind of come in and say, “You’re going to DevOps the thing and DevOps is going to be the way.” Right? Not really – this is a company where maybe they’re not even really sure what DevOps really means. Right? Which is okay. They’ve heard it. They’ve got some of the vision and they’re interested.

He’s very concerned. He says, “James, what do I do about this? I know you like the DevOps and stuff like that, but you know, what do I do from a security perspective.” I give him an answer. I didn’t feel great about it. I gave him a, you know, I don’t know, find ways to inject stuff, I don’t know. I went home, thought about it, woke up the next morning and I was like, “I got to call him back.”

So I gave him a call and I was like, “Hey, the real answer to your question is never say no ever again. Never say no ever again. Security has lived the world of no for so long and you have to throw that away. Like your new answer has to be yes, you can have yes with qualifiers, yes with whatever, but you’ve got to find ways, creative ways to say yes and kind of the cloak and dagger, blame it on compliance, slowing down things for whatever, you can’t do any of that stuff anymore and you’ve just got to throw out all the security gets to be a blocker.”

And I said, “Because every organization that I see high performing, what we would now call like DevSecOps teams, but security and DevOps working together, they sort of rip tear up the security playbook and they say, if you are a blocker, everyone in the organization is going to route around you. But if you play ball, like you get to be a part of the solution. And security has to find a way to add value inside of that.”

And so, and I said, “Every single one, you talk to any person who’s undergone the transformation and working in any of these companies to Hulu to Netflix to Inuit or whatever, you know, or all the ones that we see at DevOps Enterprise Summit, they’re always finding ways to say yes and be part of the solution and not to see themselves as a blocker. So I think that’s a fundamental like philosophical shift that security has to undergo.

Shimel: Absolutely, and you know, just to turn it around on you a little bit, I’m going to be the Jewish guy spreading the good news too, right, the gospel. We started off this conversation early on and you said, “Well, we still have so much more to do and I wish we would be further along.”

Wickett: Yeah.

Shimel: You’re right, but someone much smarter than me once told me, James, change, especially in technology, is 99 percent of the time evolutionary, not revolutionary.

Wickett: That’s right.

Shimel: But, when we look back over a period of time, we’re often astonished what that evolution – how that evolutionary change adds up. So the fact, that little piece that you espouse right there about not saying no anymore, and yes, we can and you know, whether you qualify it, caveat it whatever, but yes, we can.

Wickett: Yeah.

Shimel: It’s so powerful. It really is. It’s so powerful. Look, I spent 2001, I’ve spent 18, 19 years hearing now from people, and – or being part of the no too, to be in all honesty.

Wickett: Right, yeah. I mean, that’s –

Shimel: You don’t want to wind up in jail, do you?

Wickett: I got my ISC squared books up there. They look at me with an evil eye.

Shimel: Yeah, so you know, it’s refreshing. It’s like liberating to take that attitude. How do we spread this gospel though? What more – what better way can we do it? I know you’re involved in DevSecOps.org and DevSecOps Days and I’m obviously too and at RSA this year, we’ll be doing our thing again. But what more could we do in 2019, James?

Wickett: Oh man, that, I don’t know the answer. I don’t know the answer to that question yet. I mean, I think there’s some pragmatic things. I think we continue to say the story side. I relate to what’s going on with security right now to what happened with DevOps in the beginning and if you rewind to like 2009, 2010, or like let’s say the first three years, right, DevOps equaled chef or puppet, like straight up, like that’s what it was. And so what was that? That was operations was finally able to be developers, to act like developers, to shift left. Right?

They participated in agile type practices with infrastructure, revolutionary, really cool, really great. But then there was also another movement that happened at the same time and that was the idea that like we needed the instrument a lot better. We need to do monitoring. Now, people talk about observability. There is a big push of understanding like what your systems are actually doing. So, and that was, then there’s kind of the whole like monitoring conference, there’s monitorama, there’s monitor movement and the monitorama in response to it.

There’s some great products have come out of that space. We see things like Data Dog and before them Cloud Kick and other folks. Well, I relate all that to security because if you look in the first several years of this security and DevOps kind of joining forces, I know people have been talking about it for many years, but over the last couple years, what are the things that everybody has kind of gone around? It’s the whole idea of shift left. So you see great companies, _____ types, Nick, other folks like that, that are focusing on, you know, putting all of your development testing, you know, figuring out what binaries, talking about software supply chain, bill of materials, all that sort of stuff. We’re still missing the push right.

Now, I mean, I work at a – or a shift right type thing and so like, Signal Sciences, we sit at that end of the spectrum, so this is a bit of a self-serving type statement, but I mean, you need to have sort of insight into sort of what your application is doing and when we started the company, we were singularly focused on one question and that question is, do you know right now if you’re under an attack with any degree of certainty, we’ll say. You don’t have to know 100 percent, but with any degree.

I ask people that question like in conferences and whatever and almost zero, like I’d say just one or two people per, y, every six months or whatever, says yeah, they know. Most people have no idea, like what’s actually going on in their site. And we see this like when was the last time you read the headline that said, like, you know, we lost a million account credentials, but we stopped them. We’ve been following them through our system, we saw that they were starting to leak data and so we turned it off, but we didn’t get it off soon enough, but they didn’t get 100 million, but they got a million. Right? You never see that news story. Right? You see the news story of like _____ we lost it all and we lost it all three months ago. We had no idea until it started being traded on the market. Right?

So, like we lack a critical insight and you know, operations had the same problem, right, didn’t understand what was going on with the systems, performance-wise, everything. Security is quite similar to that. So, being able to instrument and see and do monitoring and have that sort of security observability is like an important aspect to where I think we need to go. So, we’ve done a lot of the shifting left similar to ops in the early days, and I think we’re going to see some more movement on the shift right part.

Shimel: It also sounds though like opportunity there for some better tooling.

Wickett: Yeah.

Shimel: Right? I mean, a lot of our security tools, you know, from vendors really aren’t made for that, right? I mean, you know, we have so much – so you know, the fighting point in the security vendor space is, should we put more focus on security response versus prevention? Right? Threat intelligence, all of these things, and you’re right. We don’t have that analog of a Data Dog, a Signal FX or that, for the most part, in securities.

Wickett: Yeah, ’cause like I see that across like – so for Signal Sciences, like we provide that for web applications, but that’s also stretching across other boundaries that you need to look at, and a more fuller picture, and I remember whenever we were launching – when Ernest and I were doing cloud stuff at our first just kind of thing over at National Instruments, we were trying to find vendors and just straight up like operational monitoring vendors and I talked to like – that was my job. That was one of my first parts of the things.

It’s like, okay we built the thing that – we have this whole thing we called Pie that spun up our system, much like Chef and Puppet, but then we said, all right, what are we going to monitor this stuff with? And I started calling and monitoring vendors and getting demos and stuff and it’s like, at the end of it, I was like, I just need one that has an API. Like just a good working API that can like admit _____ _____ and connect, you know, ’cause this is early days. Right? And we ended up finding a Cloud Kick and they ended up getting bought and sold and we moved later on to Data Dog, but it was so hard at the time to find that. And I feel like security vendors are similar in that space, that they struggle from where like when – and we’re not alone in this. There’s other people in our space that are doing thing that are helpful for people, but emitting data back to all the systems that you work with, like the Slack and JIRA and whatever, but also just being part of like the whole tool chain approach. And I think that’s a story we’re going to see continue to be developed and companies that are adopting that and embracing the idea that they’re a piece in the overall tool chain, like I think those companies are going to continue to do well.

Shimel: I know that you can have like just standalone security monitoring and so I think security monitoring has to be part of your larger monitoring.

Wickett: That’s right.

Shimel: Two or three other points I wanted to hit on, get your opinion on. So, just like DevOps, same analogy, tools are important. Culture trumps tools in a lot of places and we can have the best tools in the world, but until the security people’s mindset is changed and we’ve touched on it in this talk, you know, not saying no anymore and all of that, so how do we go about changing that mindset? Well, one piece of it, James, is at the organizational level, right, we embrace security.

We make them part of the team. Another part of it though is at the community and industry level and we mentioned it now a few times and a lot of my friends mention it, and this is the whole what are security people taught. And I’m not knocking ISC Squared or SANS or any – we’ve got some –

Wickett: Let’s knock them. No, yeah.

Shimel: I’ve got friends on the board there. You know, I got to be careful. But, I mean in all honesty, and again, I’m not singling any one of them out, but when security people are being taught to say no, it’s very hard for us to come in and say, “Don’t say no.”

Wickett: Yeah.

Shimel: Right? So, do we, you know, you know I’m part – I’m one of the cofounders of DevOps Institute and we have a DevSecOps class there that you know, some of my more enlightened friends have helped us with. You and Ernest have done the DevSecOps thing. You guys do _____ and stuff like that. But those messages, I don’t know if they’re finding their way into, let’s call is mainstream security training, ISC Squared, CISSB exam, the SANS certifications and not just those two. There’s a half a dozen other very well-known ones. How do we, you know, is 2019 the year we make a beachhead there?

Wickett: I don’t know. I don’t know. I’m an optimist, Alan, so I would love to say yes to that question. I would love to say yes, but when you think about it, like it’s – security has a very tough job. They’ve worked themselves into a scenario that they’re beholden to compliance and standards and outside bodies of influence and then they also are inside of an organization trying to affect change, but they find themselves at a very like inequitable distribution of labor. So like you have a hundred developers. You have ten operations folks. You may have one security person. Right? That’s a recipe for a problem. They’re all going to have different values.

So, I don’t know if we’re just going to automatically fix the culture in 2019. I will say tools influence – tools have an influence on culture and that you know, in the CANS model or CLAIMS model for DevOps—or CALMS, I guess people like to call it as well, but for the M, for measurement and sharing, I think those are the two pieces that can really help influence the culture in a more positive light.

And so, you know, security has, you know, we have stocks and we have like we – we remit all the data and have people taking concern of this, but we’re not – if you’re not creating – this is something else that I try to influence among my security friends. It’s like, if you have any tooling that you’re buying and implementing whatever, but it’s not creating a feedback loop to developers, then it’s like worthless. You should _____. Right? If it’s just going to a sock and someone’s doing it like, that’s not good. Right? There’s no DevOp telemetry out of what’s actually happening.

And so I think finding products that can help or whether it’s like open source testing tools or you know, instrumentation on the right or detection on the left or whatever, but like creating those like, I don’t know, able – we’re able to have a sort of virtuous cycle of feedback loops to development. I think that’s going to be key. But yeah, I’m going to say like no, 2019 is not going to be the year just because of – just because of the way humans are. I would like – but I think that it’s going to get better.

Shimel: I think it will get better. Here’s what I think we need to do, James, and you have got to do in this.

Wickett: All right.

Shimel: You and I are both wired into this community. We know people on the ISC Squared board. We know SANS instructors. We know the folks at SANS. We know all of these places. If one of the missions of the DevSecOps.org group, team, community, DevSecOps Days, what I do with my stuff, is to make sure we reach those people and say, “Hey, we represent a very large piece of this community and you’ve got to listen to us. It’s like a voter registration drive then. And – but you’ve got to lead it, right? And so, I’m going to put the onus back on you, James, and say you can make this a reality. You –

Wickett: All right. Well, Alan, let me tell you how I am working on that. So I do have somewhat of a plan here or an idea here. So, I’m working with several others, Shannon Lietz, Ernest Mueller, John Willis and we’re working on the DevSecOps handbook, which is going with IT Revolution, and we’re trying to tell those stories of like how DevSecOps is transforming at large companies, small companies, helping people see the new path forward. So hopefully yeah, that’s –

Shimel: In 2019?

Wickett: That’s – the – what is it called, the like the draft galley copy, like we’re hoping to have some of those available in 2019 at the DevOps Enterprise Summit _____ either in London or in Vegas, so yeah, it depends on – you know, it’s a – they run a real great shop over there, so it depends on the schedule for editing and all that stuff.

Shimel: Well, that’s a revelation. Good stuff, man.

Wickett: So hopefully 2020, 2021, like we’ll start to see the industry really shift. You know, I do hope that – I always hope that things happen sooner than they do, but –

Shimel: It _____ before it’s time either, my friend, right?

Wickett: That’s true.

Shimel: So James, I told you this was only going to be 15 or 20 minutes. I’ve got a feeling we’re at like twice that already.

Wickett: Yeah.

Shimel: But, it’s okay. I think it was a great conversation. People will enjoy it. Predict 2019 folks, you can go to predict2019.com. James is, of course, with Signal Sciences and you should definitely check out their site and what they’ve got going on. And also just a quick reminder, RSA conference is here March 4 this year. And we are doing our DevOps Connect DevSecOps Days at RSA Monday March 4, so if you’re going to RSA, come a day early, come in at the Moscone Center, Shannon the whole crew _____.

Wickett: Yeah, if people are listening to this and they haven’t been to that, like, you’ve got to go. Like, I think that’s a very valuable single day track that’s really helpful. And also, some of the sponsors and vendors back there, like some of the really forward-thinking folks, I mean, it’s the – it’s really like the part of RSA that I feel like has really kind of anchored that for me in my experience at RSA. It’s like “Oh, okay. Here’s the crew. Here’s what we’re trying to do.” I can see the message going out, and I love the fact that kind of the vision, did you decide to start that or is that –

Shimel: That was me.

Wickett: That’s – I think that was good because –

Shimel: DevSecOps Days, I just – you know, I – so I have a relationship with RSA for 15, 20 years and I originally went to them with it. This is the fifth year we’re doing it. I’m really pumped. I mean –

Wickett: Yeah, well, and thank you for that because basically like we – I’d say one of the ways we make the transition is by going to security events and kind of helping make this happen.

Shimel: Yeah, raising the flag.

Wickett: Yeah, and you – that is an outpost for DevOps over at RSA, RSA of all conferences. So –

Shimel: Yeah, if we can do it there, we can do it anywhere.

Wickett: I agree. I agree.

Shimel: All right. Hey, James Wickett, Signal Sciences, thanks for being our guest on this DevOps Chat. James, thanks for all you do too for the community and everything else. Keep up the great work and we’ll speak to you soon.

Wickett: All right, thanks Alan.

Shimel: All right. This is Alan Shimel for devopsy.kinsta.cloud Security Boulevard. You’ve just listened to another chat. Have a great day everyone.

— Alan Shimel

December 4, 2018
DevOps Chat: App Modernization and Service Virtualization with IBM’s Matt Tarnawsky

While everyone wants to focus on building a new app, the fact is there are many, many apps already out there. They need to be maintained, updated and modernized. How do you upgrade these legacy apps to new infrastructure, frameworks, languages and more? App modernization is a thing.

In this DevOps Chat we speak with Matt Tarnawsky of IBM about app modernization and service virtualization, testing and more.

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

Transcript

Alan Shimel: Hey everyone. Alan Shimel, devopsy.kinsta.cloud, and you’re listening to another DevOps Chat. In this episode of DevOps Chat we’re going to spend time talking about app modernization, testing, service virtualization. We will see what else kind of gets dragged in within our time frame.

Our guest, you know, who’s going to serve as the expert today, Matt Tarnawsky. Matt, hopefully I didn’t mess that up too bad. Matt is with IBM. And Matt, welcome to DevOps Chat.

Matt Tarnawsky: Thank you, Alan. Good to be here.

Shimel: Absolutely. Pleasure to have you here. So Matt, first of all, I did not mangle your name too badly, I hope.

Tarnawsky: No, you got it pretty good.

Shimel: Fantastic. So Matt, following our tradition here on DevOps Chat, we like our guests to introduce themselves. So why don’t you tell us a little bit about your current role at IBM and also a little bit about your own personal journey that led you to be here today.

Tarnawsky: Sure thing. So I am the product manager for IBM’s Rational Test Workbench and Rational Test Virtualization Server, specializing in API testing and service specialization. In terms of how I got here, I have had an interesting journey, starting off with working with a lot of the circuit boards and SPGAs, working with those and then testing those as well.

I ended up migrating across to working with a small company called Green Hat Software building, AGI testing and service specialization tools. We were acquired by IBM several years ago and I’ve been enjoying the journey ever since.

Shimel: Good for you. That’s a great story met. And you know, it’s fairly – it’s more usual than unusual in the IT space when you see someone – when we look at the arc of our careers, five years from now who knows what we will be working on. It may not even exist or we even know about it today. So it’s kind of right par for the course.

So Matt, as I mentioned earlier, I wanted to talk a little bit about app modernization. In my mind, anyway, it’s a loaded – that phrase is a loaded phrase. We hear it bandied out about a lot but when you talk to people – to some people they are talking about, “Well, I am modernizing my existing app. So I’m taking my legacy applications and modernizing them for new infrastructures, new delivery methods, new imports, what have you.” So really about modernizing your existing legacy applications.

To other people, though, it’s more about modernizing the way you develop, deploy, and manage applications. So modern – application modernization. Of course, no matter how we are talking about it, testing plays a vital role in this. So why don’t we first do a little level set. You know, Matt, what you – when you hear app modernization, what does it mean to you?

Tarnawsky: So to me, it encompasses a lot of things you mentioned _____ _____ _____ _____ people talk about is, how to do I _____ _____ my app to new markets, new interfaces. That can be things like mobile. It can be things like presenting apps _____ _____ _____. And that often does require _____ _____ _____ _____ their interfaces to actually bring them into the _____ away from our systems that they may have had in the past.

But often, it also means they want to look at the faster methods of delivery, new development styles. These things often go hand in hand. You often can’t get those faster methods of development with rapid feedback and everything else without looking at, how do we change our entire development life cycle; trying to be stuck in a waterfall method doesn’t really get you that same acceleration that you can get when you start looking at, how do we automate everything and moved to DevOps.

Shimel: Got it. Got it. Now you broke up there a little bit back on – and I’m hoping people listening will be able to catch all of that. But let’s – so we may fill in. But let’s talk a little bit about the role of testing and that framework of app modernization. Obviously, testing is important, but how so and in what context?

Tarnawsky: So I actually see – you know, if we are taking older, monolithic applications and looking to migrate them towards micro-services, it’s a great opportunity for testing. You are putting things into small units that can be tested on their own. You get things like – let’s say you’re migrating to a _____ based _____ based service, you get the opportunity to describe it with _____ Swiger or _____ or open API. And you’ve got a contract there that you can then test against.This means that things now have the parameters, the what needs to be tested, how to test it, and it can be imported into many different test tools to help them start testing, but it’s smaller bits of functionality. So it’s a great opportunity to break things up and really look at how those can be worked with at a smaller level.

At the same time though, it also introduces new opportunities for more complex interactions that we didn’t previously anticipate. So let’s just say you’ve taken that big monolith. You want to expose micro-services to the rest of the world or indeed to other teams in your organization well, suddenly the integration that you had relied on in the past might not be the same ones that you are looking at using in the future. You need to start looking at how we test not just those smaller levels of the micro-services, but also looking at how we test each of those integrations over time.

One of my customers has a great analogy that they like to use in terms of the testing. They said when you’re testing a car, you don’t just test the car. You test little pieces of it. So you might start off by testing the spark plug. Then you might say we will integrate some pieces and see how those work together. We test the engine out. Then at some point in the future, we will put the engine in the car and we will test that as – you know taking it for a test drive, taking it for a spin, and make sure the entire end-to-end system works as well.

Shimel: Excellent. Excellent. Actually, that’s a great analogy. Great analogy. So Matt, another phrase we hear, and we’ve all been hearing it, a lot of us, in IT for a long time now, is service virtualization. I think people have a better handle on what we mean when we talk about service virtualization. But again, let’s lay a foundation. When you talk about service virtualization, especially in terms of app modernization and testing, what does that mean to you?

Tarnawsky: So service virtualization is where we take some sort of interface that we might have had that could be something silent rest. It could be something like Mqueue. It could be a legacy mainframe interface like Kicks. We provide some sort of mock that is going to handle the interactions with the interface. That can be coupled on the rest of the application. It starts to be providing us – I’m sorry.

It starts providing us with the ability to look around and – I’m sorry about that. Got myself a little bit jumbled there.

Shimel: No problem.

Tarnawsky: Basically, it gives us the ability to remove restrictions from ourselves. So if we had legacy items in our environment that we might not have in the cloud yet, well actually, we can do is we can say, well, look, that mainframe connection, that SAP connection, whatever it might be that’s in our current on-prem environment, we can virtualize that, we can house something that sits in the cloud. And in fact, our developers can have an entire environment in the cloud that is no longer linked to those legacy systems.

Shimel: Fair enough. So how does this all play out then, Matt? Right? So now we’ve got our little parts here and we’ve defined what we mean by this. In your world, where are you seeing sort of rubber meets the road, if you will, in terms of organizations deploying, employing, doing this kind of stuff? Make sense?

Tarnawsky: So we see all sorts of things. We do see people looking at that – we want to do a migration. So we are going to record various pieces of environment and have them available to replay. Just very, very basic style of creating virtual services, but it can be effective. And indeed, they can do the same sort of thing for their API testing as well and just say, “Have we migrated this correctly? Does it still have the same functionality we had last week when we had it on-prem as we got on the cloud now?”

That’s a very effective way to look at things. But equally, we see all sorts of interesting stories come up from customers, whether that’s looking to virtualize the way a third party – so we’ve seen customers look at things like Apple Pay or Experian or whatever, where they have to pay every time, they had that third-party service. Or indeed, that might just don’t have control over it and they want to simulate what happens if that third-party service responds or throws an error code or whatever.

We see customers who do some really – one of my favorite stories comes from a customer who was looking at testing out their credit card issuing systems. Now, you can imagine that as you’re looking at issuing a credit card, at some point you’re going to print a credit card. Now, just imagine test automation for that sort of thing. Do you really want credit cards popping out of the machine? No you want to be able to test things effectively, but not have these physical dependencies.

So what they did what they looked at the traffic that was going through that credit card machine, the issuing machine. They said, here we got a point where we can virtualize some things in our environment and remove this dependency that we currently have. We don’t want to print real credit cards. It’s a waste of time, waste of resources, and in fact, it slows that test automation down. So if we can virtualize that out, we can get faster feedback back to the development team. So that’s exactly what they did.

Shimel: So Matt, we recently did a webinar over on devopsy.kinsta.cloud you are probably aware of it, modernizing testing as apps re-architect. Is this the kind of stuff we are talking about?

Tarnawsky: Very much so. You want to make sure that your testing stays in pace with that re-architecting of the apps. A lot of that does come down to developers delivering fast from the cloud. And tests more and more need to be automated. That doesn’t remove the value of exploratory manual testing or anything like that. But we do see that need for testing to become more and more automated in the future as well, as this change happens.

Shimel: Absolutely. You know, another thing, and I get this a lot, Matt, when I’m traveling around the world. Is this a sort of – not to use the – abuse the term, but first world problems, right? Is this where… In terms of the market, is it sophisticated, large enterprises who already have legacy infrastructures, a history of service virtualization and so forth? Or is this something that’s really kind of more grassroots that’s happening across the board, across the globe, as organizations are starting to move to app modernization and dealing with the realities of having to test around this stuff?

Tarnawsky: So we see all sorts. Actually, the example I gave you earlier, the bank that was looking at the credit cards, was a fairly new bank here in the UK.

Shimel: It was? Okay.

Tarnawsky: They were – that they are very much based on looking at how they can do things in the cloud, trying to keep things as modern as they can. They are looking for all the latest techniques, all the newest tools that can help speed up their development and their time-to-market. So yes, we do have a number of customers using this stuff for legacy enterprise systems. They are looking to virtualize the way a mainframe, for example.

But equally, we see other customers come to us and say, “I want to accelerate my development and my testing as fast as we can. What can you do to help us?”

Shimel: Good. Interesting. You know, Matt, I mentioned when we started that the time goes pretty quick. We are coming up on the end of our time frame here. But for people who maybe want to get more information on this, where can they – where can we dig? I mean, I should mention that the webinar I referenced earlier is available on devopsy.kinsta.cloud and YouTube, a recording of it along with the slides. So people who are interested there should absolutely head on over and get that. We will try to include the URL in our show notes for today’s podcast.

But where else should they go, Matt? How do people get smart on this?

Tarnawsky: So I would invite them to come on to IBM.com, searching for Rational Test Workbench or Rational Test Virtualization Server, depending on whether they are interested in test automation or service virtualization, as a starting point. And we’ve got loads of white papers. We’ve got customer stories. We’ve got all sorts of things you can look at for more information just to see how other people have been doing things.

Shimel: Fantastic. Matt Tarnawsky, thanks for being our guest on DevOps Chat today. Pleasure to have you on. Hopefully we will have you on again soon.

Tarnawsky: And thank you very much for having me.

Shimel: All right Matt. Hey, this is Alan Shimel for devopsy.kinsta.cloud. You just listen to another DevOps Chat. Have a great day, everyone.

— Alan Shimel

November 30, 2018
DevOps Chat: Managing Apple Devices with Fleetsmith

Managing Macs, iPhones, iPads and other Apple devices at scale is not something really native to iOS or OSX. Enter Fleetsmith. In sort of a Puppet-meets-Apple environment, the Fleetsmith team automates configuration, management and security of your Apple devices.

In this DevOps Chat we sit down with Fleetsmith co-founder and CEO Zack Blum and company adviser, Puppet co-founder Luke Kanies, to discuss the mission and challenge in managing Apple devices.

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

Transcript

Alan Shimel: Hey everyone. Alan Shimel devopsy.kinsta.cloud and we are here for another DevOps Chat. Excuse me. This episode of DevOps Chat features an old friend and a new friend. We have, first of all, cofounder and CEO of Fleetsmith, Zack Blum, who is the new friend. Zack, welcome.

Zack Blum: Thanks, so much. Great to be here.

Shimel: Okay. And then joining Zack is our old friend, Luke Kanies. And Luke really needs no introduction to our audience. Luke is the founder of Puppet.

Luke Kanies: Famous on the internet.

Shimel: Famous on the internet, but still puts a token in when he jumps on the subway. But anyway, Luke, welcome.

Kanies: Thank you very much for having me.

Shimel: So let’s get this out of the way right away. Luke, what’s your connection to Fleetsmith?

Kanies: I have been trying to help Zack and his cofounders, trying to tell all the stories of all the ridiculous mistakes that I made in hopes that they make only new mistakes.

Shimel: Wouldn’t that be a great thing? Man.

Kanies: We can dream, right? We can dream.

Shimel: Yeah. I was just going to say, if you can bottle that, man, you really would be famous. So Zack, before we even jump into Fleetsmith, then let – you know, Luke has told us what the connection is. Always interested to hear. How did you hook up with Luke and come about to – I’m going to assume you asked him to an advisor here.

Blum: Yeah. Well, it’s funny actually. Even before that, the interesting thing is Puppet itself was the inspiration for us starting Fleetsmith. So the connection goes really far back. I was the IT director at a company called wikia and we had this problem where we needed to manage our device fleet. So I asked around my peers at IT and security and talked to a guy at Dropbox and asked how they did it internally. And it turns out that they use a bunch of open source tools traditionally used by DevOps pros actually to manage their laptops.

So I went out and learned all about Puppet and realized, “Oh, my goodness. There is an amazing application opportunity here on the endpoint side.” So long story short, that guy at Dropbox, Jesse Endahl, became our cofounder and CSO; had a product. And Luke and Puppet were a major inspiration. So pretty cool.

Shimel: Very cool. Very cool. So let’s address Fleetsmith, right? What is it you guys do?

Blum: Yeah. Thanks so much for asking. We do a few things. We are a modern Apple device management product. So we help companies manage their corporate Macs, iPhones, iPads, and Apple TVs. And we really try to accomplish four things for our customers. Number one is making on boarding new hires as seamless as possible. So employees ramp right away. We do that by automating new device set up. So straight out of the box, to have a computer set themselves up.

The second one is we provide fleetwide device intelligence so that IT can see problems before employees get interrupted. We do that with really core reporting on exactly what’s going on out there. The third one is we provide employees with uniform, up-to-date computing environment. We do that through automating OS and third-party app packaging, patching, and the delivery of those as well as config for Wi-Fi printers and other tools.

And the fourth one, the last one, is we decrease business risk for customers by allowing them to enforce, in an automated way, security best practice so features like disk encryption with automatic key escrow, remote lock and wipe. And so those are the four things we do; really try to help companies of any size, especially small and medium businesses, take those best practices and apply them in an automated way without huge teams and huge _____.

Shimel: Excellent, man. You know, as crazy as it sounds, I almost feel like you serve an underserved business segment for first trillion dollar company ever, right?

Blum: Well, we think you’re right. Yeah unfortunately, too many of the companies that we come across have nothing in place at all; no visibility, no automation around this. Then there are a lot of companies who have something in place and it’s just incredibly tedious to administer. There are so many higher value things that IT and security can focus on than manual packaging of software updates.

You know, providing great customer service to their employees, helping them do better work. So we are really excited.

Shimel: You know, but this has always been a – I go back in my years in security. We – the company I helped found, kind of one of the pioneers in what we call the NAC market, the network access control. So it was a little different. As you would log onto a network, we would check your endpoint, whatever that might be, and make sure it conforms to whatever the policy that was set. And part of those policies were; were you up-to-date on your patches and your AVs and all that good stuff.

Blum: Right.

Shimel: And even then – and by the way, this was for three letter agencies and U.S. Department of Defense networks. Even then, checking Macs was like a black hole. Right?

Kanies: It’s always been that way.

Shimel: I’m sorry, what?

Kanies: It’s always been that way, for various reasons. And one of them is that they just haven’t been used as much. The second is that Macs have always been kind of cut out of IT policy. Either the Windows – the IT has always been run by Windows and they either say, no, you can’t have them, or, yes, you can have them, but don’t ever talk to us about them. So they’ve kind of always been out.

In the last 10, 15 years, Apple has really done a great job of building a device that is better for actual usage. So it started out very much in the consumerization of IT, which is how PCs got started in the ’80s, course, as people bring their own computers in. What then they started bringing their own Macs in. Now you look at, especially small companies, and they’ve gone from, “I’ve got a couple of Macs for my designers.” To, “Everyone have a Mac and I’ve got a couple of PCs because my accounting people have to use the Windows version of Excel for whatever reason.

Shimel: You know what? That’s exactly it. And it’s interesting that we get this kind of folks coming in. And one of my colleagues just joined here. I apologize. So when Macs were 2 percent of the market, maybe no one cared. But as we were talking off mic earlier, when you started getting to 20 percent or more of the market or thereabouts, that’s a number, right? That’s a sizable amount to worry about.

But how much are the – and I will throw it both at Luke and Zack. How much are the guys – and due to Apple’s professed policy of not wanting to be in the enterprise or not wanting to be in that business market of being a consumer brand? Right? And as a result, you know, if it walks like a duck, it quacks like a duck, but it’s really not a duck. Right how much of that is to blame here for our, up to this point, neglect of managing Macs in the workplace?

Blum: You want to start on that Luke?

Kanies: Sure. Honestly, I don’t think much is, for at least two reasons. No. 1 is that it wouldn’t have mattered if Apple had decided they really wanted to be enterprise. They would have failed. We know that because of taking multiple cracks at trying to do enterprise stuff and all of them fail. If they are lucky, they deflate quietly and just get brushed into a corner. If they’re unlucky, they fail relatively spectacularly.

So Apple has, in the past, fought against its own DNA and lost because that’s how it works, right? And when you look at Microsoft today and they are resurgent. And one of the ways they are resurgent is that they are doing a better job of being who they are rather than trying to be who they are not.

I think the second reason is that Windows was incredibly dominant for so long. The way in which Windows succeeded was very business oriented, very – and yes it was kind of user oriented at first, but that was long time ago. You know, when I came up and went to college in the 90s, my – first cut my teeth, I was a Solaris user. I was – back before there was Linux. So even then you wouldn’t choose between Windows and Mac and a corporate environment. You would choose between Windows and Solaris in a corporate environment.

Shimel: Right.

Kanies: And again, you had a couple of designers in the corner and they had Macs what they did was really specialized. But I don’t really think it had anything to do with Apple. If anything, Apple was struggling to hold on at all. It was less that they weren’t an enterprise company and more that, “Wow. We found like two people who can’t live without our product that we going to make sure we do everything you can to make them as happy as possible and we’re not going to worry about anybody else. ”

And it was only when, kind of the world changed a lot, partially because Jobs came back. But partially because the world changed a lot, right? The internet came out. And the reason why you wanted a computer shifted from, “Because I need one for work,” to, “Because I need one at home.” Right? And if the iMac had been 10 years earlier, they wouldn’t have sold any because, why would you have a computer at your house in 1990. There was no – there is not nearly so much reason. But when you can dial-in, when you’ve got Internet, that really changed the world.

Then the trends, the drivers of computing shifted from entirely business use cases to at least 50/50 personal, business use cases. And one can argue today that the majority of drivers of how people think about their relation to computing is mostly driven by consumer use cases and that pushes to the enterprise. And we’ve seen this consumerization of IT trend going back decades. It’s more of a treadmill or an escalator than it is a one-time blip. But to me, this really explains why it matters now and it didn’t matter before, because that consumer use case driving so much of the story.

Shimel: Yeah. I mean, so Luke, I’m a little older than you, right? Solaris is … My first company, we ran you know, SPARC servers, UltraSPARC, actually. But –

Kanies: They may be slow, but they sure are expensive.

Shimel: Don’t even go there, man. But on top of that, I was an OS2 dude. I loved OS. I was running OS2 really early on. I still don’t understand why Windows is here and not OS2. But that’s another story.

Kanies: But you know, one of the things that I think has really enabled this is they used to be such a gulf, such a, frankly, a pain in the butt to move. If your colleague was on Mac and you are on Windows, you just had to give him a word file to use or spreadsheet or anything, for that matter. You know, reformatting discs and doing all that nonsense. Beyond the internet, interoperability between has really, I think forced it. But that’s – you know, that, it speaks for itself, right? A lot of us are using Macs today. I’m on a Mac right now.

Zack, one of the – and we shouldn’t just focus on Macs. We should focus on what the iPhones and the iPads and Apple TV and it’s is ubiquitous, man. Nothing drives security people battier then having sort of unknown devices or unmanaged devices or black holes in their network.

Blum: Absolutely.

Shimel: And so I would imagine that’s the allure, if you will, of giving Fleetsmith a whirl.

Blum: Yeah, absolutely. And especially with the move to the internet of things. Even with computing devices like iOS and iPad, you had iPads, for example, in nontraditional computer roles like a front desk check in machine or the conference room calendar. Then you have, often, three devices comprising a conference room videoconference set up, right?

So these aren’t as much for individual employees anymore. These are sort of use case driven, almost appliance type applications. So not only do you have these unassigned, if you will, devices floating out there, they’re just on the internet. The corporate network as far as computer management and security of devices is dead, we need to secure the endpoints wherever they are and provide visibility.

So that’s one of the great things about a product like Fleetsmith is that we provide that things to security folks whatever network the devices on and whatever its application is. And I wanted to add one thing to what – continue Luke’s first point from before.

Apple absolutely has been a consumer company and now that there is such a high enterprise market share, they’ve actually stepped up and are building a lot of really great management APIs, kind of recognizing that third-party providers of MDM like us are then able to run with that where that is in our DNA. We are experienced IT and security folks. So they are doing some really exciting stuff that’s enabling further penetration into the enterprise stream.

Shimel: Absolutely. One other just question. This is something that’s kind of – it’s close to where I’ve come from in some ways. If I’m the IT guy or the security guy, I absolutely abhor having multiple management interface systems that I’ve got to work with. So I’ve got this to manage my Mac stuff and iOS. I got this to manage my Windows stuff. I got this to manage my Linux. I got my cloud management stuff.

How – does Fleetsmith integrate with any of, sort of the larger Windows or other kinds of device management products out there?

Blum: Alan, you’re talking about the fabled, single pane of glass. I think that’s what I’m hearing.

Shimel: Yeah. Well, the mythical single plane of glass, but okay.

Blum: That’s right. Well, you said it. To answer your question directly, we do integrate with G-Suite and Office365 so that when people adopt Fleetsmith they don’t have a ton of manual data entry for their inventory. But aside from that, as far as devices go, there’s kind of the suite – device management, there is the suite approach and the best-of-breed approach.

Unless you have incredibly, incredibly simple needs, usually the suite approach, you know, these companies that build management for every single OS, really fall short in all but one. They really started as a signal platform and just tacked on a couple of checkboxes. So unfortunately, in today’s world the reality is that if you need zero touch deployment, you need to automate the setup of the devices and you need FileVault disk encryption with automated _____ _____ _____. You need to make sure everything is encrypted. You really need the best-of-breed solution.

So we do all of Apple and there is some products that do all of Windows, a lot out of Microsoft. And past a certain point, those are pretty much just a requirement today.

Kanies: I would go a little further and say I would add a different dimension that’s less platform because Puppet, for example, is promiscuously cross-platform, but almost entirely server-side. So you can use, as Zack found in the early days, you can use Puppet to manage your desktops. But what you will find is just a constant low-level of friction in doing so because so much of our workflow, so much of the experience is built around servers.

You might say, “Why is it hard to – if you are servicing more complicated than desktops why is it hard to manage them?” The answer is, desktops are off all the time, laptops are off all the time, they check in from different networks all the time. You don’t get to decide when is a good time for the user to reboot their computer. The user really has to decide.

You’ve got to build a completely different experience around the product. It’s something that could be done, but there was a lot of friction. So I would say that I agree with that point, that you got to pick best-of-breed. And part of that dimension is what platform you’re talking about managing. Certainly a Windows solution… A solution for Windows being used to manage your Macs is not a great idea. But also, I think a solution for servers, a solution for back in, is not a great solution to manage desktops and laptops.

That’s really where you do need a different solution. And not that it’s impossible that you could have a company doing both, but it’s unlikely and it certainly hasn’t happened yet.

Shimel: Got it. Got it. Got it. Guys, we are right on the top of the hour. Unfortunately, I need to end it right here. But before we do, Zack, really quickly, people can get more information about Fleetsmith at…?

Blum: Yeah, just go to Fleetsmith.com.

Shimel: Okay. And you know what? Maybe we could follow up in a couple of weeks before the end of the year because I do think the whole issue of Mac management as well as non-computer – or nontraditional PC devices, whether they be iPads or some sort of IoT and whether they’re running, frankly iOS or some other non-windows, non-Linux – well, maybe Linux. The idea of keeping them compliant, with whether it be a security policy, access policies, what have you, is a really big problem a lot of companies try to tackle, but they tend to stay in the low hanging fruit way rather than maybe some of the corner cases, as bad as a corner case as it may be, you know, it’s still not the mainstream like that.

Blum: Yeah. Absolutely. I could talk about that all day. I would love to.

Shimel: All right. We will schedule something. Hey Luke, I’m sorry we didn’t have enough time to really dig into what else you got going on. But maybe we can do a follow up at some point on that as well.

Kanies: That would be great. I will warn you that most of what I’m doing next is pointedly not very DevOps. I took 20 years in one industry. It has been enough.

Shimel: Thank you.

Kanies: So there is a lot that I’m working on but it’s taking the lessons of the last 20 years and trying to use some of the same tools in different places with different people.

Shimel: That’s not a bad thing either, my friend. As you said earlier, it’s life.

Kanies: Yeah.

Shimel: Good luck with it though, and we will be in touch. Guys, thanks for being our guests on this episode of DevOps Chat. Fleetsmith.com, that’s; F-L-E-E-T-S-M-I-T-H.com. If you’re looking to manage and secure your Macs or iOS devices, worth checking out.

This is Alan Shimel for devopsy.kinsta.cloud. Until next time, everyone, have a great day. Bye-bye.

Kanies: Thanks so much, Alan.

Blum: Thanks.

— Alan Shimel

November 26, 2018
DevOps Chat: Mainframe Attitudes with LzLabs’ Dale Vecchio

Dale Vecchio has spent many years in the mainframe business, including 18 or so years with Gartner covering the mainframe beat. Today, he works as chief marketing officer at LzLabs, which recently conducted a survey with Microsoft on mainframe use: info.lzlabs.com/lzlabs-microsoft-…ation-survey-2018

The results may or may not surprise you depending on your views on mainframes. It seems that a very high majority of mainframe users would like to ditch their mainframes if they could. There are some other interesting results here as well.

Transcript

Alan Shimel: Hey, everyone, it’s Alan Shimel, devopsy.kinsta.cloud, and you’re listening to another DevOps Chat. Happy to be joined by our guest who’s actually in London today, and he’s Dale Vecchio. Dale is with LzLabs. Dale, welcome to DevOps Chat.

Dale Vecchio: Thanks, Alan. Great to talk to ya.

Shimel: Great to have you here. So, Dale, let’s first do a little sort of level-set. Give us a little bit of your personal background, maybe your journey, and then tie that into how you come to LzLabs and what they’re about.

Vecchio: Sure, Alan. I’m currently the chief marketing officer at LzLabs, which was a startup company out of Switzerland designed to help customers move mainframe workload to modern x86 open-cloud environments. But, before that, I was 18 years a Gartner analyst, covering the mainframe. I probably took 10,000 inquiries over those years, to mainframe customers all over the world. And I used to joke I was the only Gartner analyst with a theme song, and it was called “Should I Say or Should I Go” by The Clash.

Shimel: [Laughs]

Vecchio: ‘Cause mainframe customers weren’t quite sure if they wanted to stay or they wanted to go, and I said, “Well, here’s the challenges and opportunities if you stay; here’s the challenges and opportunities if you go. You make the decision. I don’t have a dog in this fight.” But I was 18 years a mainframe software vendor. I grew up as a mainframe application developer and assembler, Citrix programmer, the whole nine yards, so I’ve been dealing with this platform, on one way or the other, for four decades.

Shimel: Yeah. You know, Dale, it’s funny; you get to a certain age, not that I’m saying you’re old, but I am, and you get to a certain age and you’re surprised how many people that you’ve dealt with, that you run into, who, actually, their root’s in IT, where “I was a mainframe developer. I was writing code on mainframes back in ’70s, ’80s, even ’90s,” and that’s very different, of course, than generations past, people who’ve come into the workplace since 2000, let’s say, or whatever.

So, Dale, you have that historical perspective. Look, there’re people who – and, like you said, you have a dog in the race. I’m in the same boat. Right? We get cutting-edge DevOps, Agile people who say, “If it’s not on the cloud and SaaS, it just can’t keep up to today’s pace,” and then I run into a lot of people whose businesses still run on mainframe. You guys actually did a survey – I think it was in conjunction or in partnership with Microsoft?

Vecchio: Correct.

Shimel: On kinda people’s attitudes towards their mainframe, if you will.

Vecchio: That’s right. Because I’ve always found the challenge for the mainframe, moving forward, is not a technical one. It’s a great box; I’ve always been a fan of the box and the hardware. The problem is that people have lost faith in it being the only platform in town. I mean, you can’t say, “I can’t run mission-critical workload on the cloud or in x86.” I mean, I don’t know how – how does Amazon do it? Or eBay? Or Google? Or Facebook? Or any global startup in the last 20 years hasn’t been built on a mainframe, so there are technical options. But the disciples of the mainframe – as you said, baby-boomers, born between 1946 and 1964 – even if an organization says, “I wanna have young developers,” your decision-makers, you database administrators, your system programmers, those guys are not young.

Shimel: Right. They cut their teeth on ’em.

Vecchio: And I always used to say that the biggest decider of whether customer wanted to stay on a mainframe or not was the age of the CIO ’cause, if you want an older CIO, as you said, you grew up in the world; you understand the value proposition of the box. If you’re a younger person, not so much. So that skill survey that we did, we wanted to get some objective measures from 500 senior IT leaders around the globe – “What is it you think about this platform?”

There’s two things that came out of that that was pretty shocking. First off, almost everybody has open-source, cloud, and Agile development as key components of their IT strategy, moving forward. Now does that say the mainframe can’t participate in those? No. Is it where you’re mostly likely to find those things? Probably not. So that’s the first part. The second part was 94 percent of the respondents said they would consider getting off the mainframe, number one, which is a shocking number to me.

Shimel: Yeah.

Vecchio: I didn’t say they will. Said they were –

Shimel: No, no.

Vecchio: Which, 10 years ago, you wouldn’t have got that kind of number. But I think the one that was more surprising to us was that half of the mainframe companies that we surveyed have lost faith because IBM is more focused on the cloud and Watson. And they not even sure that the keeper of the flame is as focused on that platform as, say, Compuware, who is 100-percent focused on that. I mean, they have a great DevOps story.

Shimel: Yep. Well, look, all of the mainframe people have developed a DevOps story, right, Dale? Whether it’s IBM – as you said, the keeper of the flame – or the Compuwares, the CAs, and there’s a few others we’ve dealt with that are mainframe vendors and stuff. Here’s how I kinda – couple of things. First of all, that 50-percent number on people’s perception about IBM’s focus on the mainframe? I get it. You know, I go to IBM Think every year. It’s this huge – it’s in Moscone this year and it’s a huge floor. And you look at how much is dedicated to mainframe versus the shiny, new objects.

Last year – well, it’s been Watson for a few years, but, this past year, it was the – not “cognitive.” What’s the new computers? It was like a copper machine – eh, whatever. I forgot the name of – it’ll come to me, I’m sure, while we’re talking. But, anyway. But, yet, when you look at the bottom line, when you look at the revenue – and I’m not a stock pundit and I’m not here giving anyone investment advice, right?

Vecchio: Nor I. Nor I.

Shimel: Their revenue still comes, way, way, way more than they would like to really tell, comes from mainframe.

Vecchio: Well, their profit does. Their profit does.

Shimel: Their profit. Yeah.

Vecchio: Yeah. That’s for sure. I mean, this is a challenge for anyone with a mainframe. It’s not a bad box. You’re faced with the challenges of skills decline. Most of the, if not all of the, vendors in the space are very focused on maintenance revenue. And why would anybody buy Rocket or CA, why would an investor look at that, unless they were managing the maintenance revenue streams? So that doesn’t bode well. This is not about whether that box is any good; it’s the dynamics of the market are working against it.

Shimel: I get it. Yeah, by the way, it was “quantum computing.”

Vecchio: Ah.

Shimel: That was brought up _____ _____ _____.

Vecchio: Oh, yeah, quantum computing. Yeah.

Shimel: Yeah. That was definitely the shiny bullet at last year’s Think. And you’re right. Look, you got Chris O’Malley at Compuware and he’s all mainframe and he’s not shy about it either. CA – a lot of people are saying the whole reason Broadcom bought CA was for mainframe – I don’t know if I buy that either.

Vecchio: Well, for mainframe revenue.

Shimel: Yeah.

Vecchio: For mainframe –

Shimel: Well, more for using the mainframe customer base to go sell routers and switches, which I’m not – we’ll talk about that offline. But let’s stick to the survey. So, yeah, I can understand the 50 percent. It doesn’t jive, of course, with IBM’s profits, but here’s my kind of basic nitty-gritty on this issue, Dale, is, yeah, we’d all – look, I’d like to get a different car. I’d like to do something different. The problem is that trillions – and it is literally trillions of dollars that have been sunk into mainframe. I don’t know how many organizations can just afford to walk away from that.

Vecchio: Well, this is sorta the challenge, when you talk about this, is it becomes a very black-or-white conversation. People talk, “Oh, you’re saying the mainframe is dead?” No, we’re not saying the mainframe is dead. All we’re talking about is mainframe’s getting marginalized to the high end of workload. If you went back 20, 30 years ago, there were 30,000 or 40,000 mainframes. Now there’s maybe 3,000 or 4,000 mainframes. Well, sure, they’re much bigger than they were, so there’s been some consolidation, but, even in the number of customers, there are fewer.

One of the things that I always found, the time I was at Gartner and even out of what these survey numbers tell me, is they want to get off. They want to. They don’t because they’re not sure they want the risk, number one, and, number two, they don’t have to ’cause they still have the people. But, as those – every single one of them in that survey, 85 percent of ’em, said, “Yeah, we have got a problem.”

So you’re either gonna fix the problem or you’re not, and that gets us to the whole conversation about DevOps – just “Can I bring my hammer to the mountain or the mountain to my hammer?” Can I bring all of that DevOps, Agile mindset to a platform where the culture is a 180 degrees from that? You know, all of the things on a mainframe were designed for security, reliability, availability; they weren’t there for speed. There’s not all the automated testing. People don’t understand these applications and what they do. You know, we used to joke, “These aren’t legacy systems; they’re leprosy systems,” ’cause nobody wanted to touch ’em ’cause they might lose a body part.

So how are you gonna do Agile and DevOps in that environment? So is it technically possible? Absolutely. Does Compuware have a compelling story? Absolutely. Have they convinced enough that you believe that the future of the mainframe is bright or it’s gonna continue to decline? I –

Shimel: I don’t know. I mean, I guess time will tell us that. I’ve often thought, “Why can’t you duplicate the resiliency, the power, if you will, of the mainframe?”

Vecchio: Ah, that’s a great question, Alan. Because part of – the mainframe was very much a scale-up world. You know, if you wanted more processing power, you added more MIPS. One single operating system, unified database, transaction monitors, et cetera. It is absolutely 100-percent unique _____ _____. Everything else is scale-out.

Shimel: Mm-hmm.

Vecchio: Like, “How could I take a scale-up environment and move it to scale-out?” And that’s what we’ve tried to do with our software-defined mainframe, is to give someone the ability to move an application without recompiling it, without changing the data, down to an environment that now will do scale-out. So just take full advantage of Linux, of OpenStack, of cloud-deployment models, take that exact same application and now I can run it in a scale-out world. That’s only the first step because you’re gonna wanna maintain it and then you’re gonna wanna transition to modern languages. But it’s a lot easier to take advantage of the innovation and community of open-source off the mainframe than it is on, you know?

Shimel: Yeah.

Vecchio: Sure, IBM has Linux on the mainframe. Sure. But you tell me where the community and innovation is going. Right? It’s going to cloud; it’s going to x86; it’s going everywhere else.

Shimel: You know what? It’s going – well, look, you could run containers and stuff on mainframe, but, look, when I’m talking to startups and even enterprises now, Dale, who are “high-performing IT organizations,” let’s call them, right? They’re not Google and they’re not Facebook, but they’re not necessarily iron miners or something, right?

Vecchio: Yeah, okay.

Shimel: They’re talking about things like Kubernetes and serverless and microservices, and I’m not saying that you couldn’t run these on a mainframe. I’m just saying I don’t think – I don’t know if it’s the right tool for the job. You know, one thing I learned as I grew up: I was never a handy guy, Dale, right, but tools make the man. Right? And –

Vecchio: Yeah.

Shimel: You know what I’m saying? And so I –

Vecchio: Tools are your – Alan, you’re 100-percent right. And this idea of bringing DevOps to the mainframe, which is Compuware’s story, depends on two things. First, you have to have the tooling, as you said, to make that happen, but much, much harder. And I even read some of the posts up on devopsy.kinsta.cloud about this – the culture is the challenge.

Shimel: Yeah.

Vecchio: So you can’t just try and take the culture and bring the tools into that world and expect it to take. It’s not gonna do it. Now – so we’re sorta the other way around. We’re saying, “Bring that workload to the world where DevOps readily – ”

Shimel: That culture exists. Right.

Vecchio: Right? Now are you gonna keep running those applications? No, but, to your point, they’re not so easy to change, in a big way. But, if I can get out of the complexities of the operational environment – ’cause DevOps is a combination of operations and Agile development, as you all understand – sure, I can do the Agile development; how do I deal with the operational side of that? How do I do all of the automation that’s required? How can I take a fix – can you imagine trying to roll out one-tenth of the fixes that Amazon does in a day, on a mainframe.

Shimel: Nah.

Vecchio: Very, very difficult to do.

Shimel: Yeah.

Vecchio: And I would ask you, any large customer that you speak to, if you said to them, “If you had to do it all over again right now, would you build it on the mainframe?” And I’ll bet ya seven out of ten would say, “No.” So the challenge for mainframers is it’s hard to get off, but the challenges of staying are not free either. So, to me, bringing DevOps and Agile to the mainframe is 100-percent reasonable, intelligent story. I haven’t seen it be successful. And I think the dynamics of the workforce are in play.

Shimel: Yep. So, Dale, we don’t have a lot of time, but I wanna ask you, so I’m not as familiar with your company; this is our first conversation. I’d love to see some case studies of companies who have sorta migrated to software-as-a-mainframe kind of thing and see what their experience has been, and so forth. How _____ _____ _____ –

Vecchio: Yeah. Well, that’s –

Shimel: How long are you guys offering this?

Vecchio: That’s just a perfectly reasonable thing to do and I’ll see, when we’re offline, if we can’t make that happen. There’s two parts to this whole conversation of moving mainframe workload. One is the infrastructure side, the operational side, and the second one is the applications, running the application technology itself. And our solution is designed to allow you to move the applications and get rid of the infrastructure side and take full advantage of a Linux, VM, OpenStack, OpenShift container world in order to do that. That’s the first part of the conversation. There is not many people that we speak to who aren’t intrigued by the notion of cloud.

Shimel: Sure.

Vecchio: Whether it’s public or private.

Shimel: Mm-hmm.

Vecchio: Once you say that, what you’re saying is “I want to be in an Agile, scale-out world.”

Shimel: Yeah.

Vecchio: Now the problem is so few of the vendors left in the mainframe world are actually innovating. And I assert Compuware’s one of ’em, but, for the most part, they seem to be more interested in managing a maintenance revenue stream. That’s not really conducive for what we’re trying to accomplish.

Shimel: Understood. You know what, Dale? We’re gonna need to continue this conversation ’cause we’re about out of time, but let’s do that. Fascinating stuff. And you know what? People make fun of mainframes and say, “Boring,” but this really is fascinating stuff, right? And it’s real-world ’cause there’s still a lot of stuff running on those mainframes.

Vecchio: Nobody wants to get off because it’s a bad box. ‘Cause it’s not. I mean, it’s an incredible piece of engineering. No question –

Shimel: Yeah, it really is. It’s still a _____ _____.

Vecchio: Also, it’s hard to get out.

Shimel: All right. Dale Vecchio – was it CMO or VP marketing?

Vecchio: CMO.

Shimel: CMO at LzLabs. Thanks for being our guest on DevOps Chat today. Good luck and we’ll be speaking to you soon.

Vecchio: My pleasure, Alan.

Shimel: All righty.

— Alan Shimel

November 19, 2018
DevOps Chat: Instrumentation with Influx Data’s Evan Kaplan

Evan Kaplan, CEO of Influx Data, is someone who knows his way around the technology world. In a lifetime of experience that has seen him found and manage several successful companies from startups to public entities, Evan has had a great track record of success.

Influx Data is yet another success for Kaplan. Building on the open source InfluxDB, the company boasts more than 200,000 users of Influx today.

In this DevOps Chat, Evan and I discuss systems instrumentation today and what big data and velocity means for developers and everyone up the stack. It is a very different world from just 15 or 20 years ago.

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. Happy to be joined in this episode of DevOps Chat by, actually, someone who grew up in my neighborhood. We knew each other – well, we didn’t know each other way back when, but we’ve come from a very small area of concentrated – lot of people, you know, we know from that area, but, anyway, Evan Kaplan, CEO of InfluxData and of North Woodmere. Evan, welcome.

Evan Kaplan: [Laughs] Thanks, Alan. Thanks for having me. Look forward to _____ –

Shimel: My pleasure. So, Evan, it’s been a long, strange trip from North Woodmere. Why don’t you give our audience a little bit of your background and your journey? And then we’ll jump into –

Kaplan: Yeah. Sure. Sure. Very long for me. If those of you don’t know, that’s a suburb of New York City, right near Kennedy Airport, that we both grew up. My strange trip took me to Seattle, where I finished up college and worked as a climbing guide for years. And then worked in aerospace and started a company, the first company to develop SSL-based VPNs, called “Aventail,” back in the mid-90s. _____ through the bubble. Ran a public company called “iPass,” and, about two-and-a-half years ago, met Paul Dix, the founder of Influx. And Paul and I really connected about his vision and what he was doing, and we partnered together to start building Influx from 25 employees back then to north of 100 now. So growing fast.

Shimel: Good stuff. Good stuff. And, Evan, I’m gonna assume most of our audience has at least heard of InfluxData, but, for those who have or even those who haven’t, just to set the level-set, tell us about what InfluxData does.

Kaplan: Yeah, so InfluxData is an open-source time-series-based data platform. It’s the leading time-series platform out there. Time-series is the fastest growing market in the database, data category. And so Paul, our founder, spun up Influx back in 20 – I think it was late 2013. It received a lot of accolades on GitHub. It was a very popular project and it has grown dramatically since then, from roughly – I don’t know – 1,000 sites running it to, today, we’re approaching 200,000 sites running it.

Shimel: Wow.

Kaplan: And, you know, most of the large Global 2000 is running it somewhere, so.

Shimel: That’s really impressive, man. That’s something to be proud of. So, Evan, we could probably spend our whole 20 minutes talking generally about Influx DB and what’s happening, but I’m wanted to kinda dive in a little bit and talk specifically today around instrumentation in modern software installs, in the modern software factory. This whole term “modern” has become sort of a catchall buzzword, dog whistle, if you will, for when we talk about things like Agile and DevOps and serverless and microservices and all of these ways that we’re seeing software being written, managed, and deployed today. So talk to us a little bit about it, if you will, Evan. Where’s your take on this?

Kaplan: Yeah, so I think we’re – we grew up in the industry, going back a couple of decades ago, the common myth for monitoring or instrumentation of systems was you would buy a package from HP OpenView or CA or a mainframe management package, and you’d buy a monitoring-for-a-service package. They were expensive and they were largely horizontal across the stack, and you’d implement those. And what’s happened over – certainly over the last ten years, during the DevOps revolution, is that stuff has fractured and you’ve seen companies, like Splunk and Elastic and a variety of other folks, arise to handle the modern workloads in an open-source sort of fashion. And now, if you take a look a look at DevOps world, most of solutions are dominated by open-source kinds of models.

If you look at state of the art now, that people are really paying attention to, the revolution that brought you to logs and log views of stuff and the consolidation of logs has moved much closer to metrics and events. And what I mean by “metrics and events,” the instrumentation of real time of these complex systems. And they’re not just software systems that are DevOps things, so – those are obvious, but they’re also hardware systems; they’re IoT things. And so what’s happening is people wanna see these complex systems and they wanna interact with them in real time because the only way to characterize these systems is to watch them behave in real time. And “observability,” as you know, Alan, has become sort of a keyword here. And observability generally means real time and it means metrics and events; it doesn’t mean verbose logs.

And so what we’re trying to do is help developers, specifically and, up the chain, architects and CTOs, build instrumentation or telemetry natively into these complex systems, so they can view these things in real time. As you can guess, the data loads with this are absurdly high. You’re talking about hundreds of millions of points a second in some of these systems and you’re talking about to visualize those in near real time, you know, control loops in near real time. And you’re talking about this sort of next generation of, lack of a better way to say it, system instrumentation and management.

Shimel: Sure. Evan, if I could stop you there for a sec, you know what I find interesting? We’re talking about building this instrumentation and to give people insight and who are we giving insight? Well, you mentioned developers and managers and architects and CTOs, et cetera, but you didn’t mention ops. And is that –

Kaplan: Yeah. Yeah.

Shimel: Isn’t that a little bit of, you know – I don’t know if it’s Freudian or if it’s just insight into what today’s world looks like for these things.

Kaplan: You know, that discrete ops, right? That discrete ops role is changing, right, into what you obviously cover, which is this DevOps. And so our view of how our – uptake of our platform into large corporations, companies like IBM and Cisco and SAP and Tesla and PayPal, has been from developer or DevOps people up. So we tend to think of “Make it super easy for developers, right? Get their time to value down to really, really minimal and then it will rise up and be taken as a complete operational system.” So we tend to think of it from developers up. Not to say the operations guys aren’t relevant – they’re super relevant – it’s just, when we enter into a large opportunity or business or that sort of stuff, it’s usually coming from a developer who figures out he can instrument his code, his service, his offering relatively quickly in Influx.

Shimel: Got it. And I’ll tell you something I – and it goes back to what you mentioned earlier – the sheer volume and the acceleration of data, right, the – so, no, it’s how much data and the speed that it comes at us. With automation and everything that that brings, it easily outstrips the ability of a human, a lot of times, to stay on top of it, so you almost need to build automation, machine learning, AI into these types of instrumentations, that you bring what the human really needs to see and touch or make a decision on to his attention ’cause so much of it is just whizzing by right now.

In the last week or two, Evan, I’ve probably had a couple of discussions – trying to think of a friend of mine who – CEO at ScienceLogic and another company called “Ravel Systems”; some friends of mine in security just launched something called “DisruptOps.” And they’re all talking about this term, “AIOps.”

Kaplan: Yeah. Yeah.

Shimel: And I’m wondering is this something relevant to what you’re talking about, with instrumentation? Where does that fit in? How do we account for just the big data nature of this?

Kaplan: Yeah, I think, first of all, absolutely. So, if you think about – so the journey. And let’s call it the end state of all of this is true autonomy, which is very rare and, in fact, almost never the case, right? But, if end goal state is true autonomy, what’s that journey look like? It looks like, first and always and most importantly – and, by the way, the stuff that we skipped a lot, when we were in the early stages of our career – it is, in fact, instrumentation, is telemetry. Telemetry always was an afterthought before whether shipping a product or a service or that sort of stuff. Now the ability to drive that cost of instrumentation down so low that the ability to see what’s going on and create the data – not just see as in “human” see but create the data – has changed dramatically.

So, if you follow that journey, you go from instrumentation; you go to observability; you go to automation in the form of “I’ve observed these sorts of things, whether it’s through AI capability or not. I built control loops because I’ve observed them, so I’ve built control loops to keep it in a relative stasis. Right? To autonomy.” All of that – the last two steps, right, even the last three steps – involves some form of machine processing of learning, whether it’s machine learning or AI or call it, but all of that gets increasingly sophisticated. But it means taking in, as you sort of articulated, you know, millions, hundreds of millions – in some case, billions – of points per second, right?

Shimel: Yep.

Kaplan: Think about it. Now that’s just completely – you know, what a different world, than doing server management with your CA Unicenter product 20 years ago.

Shimel: [Laughs] To say the least.

Kaplan: Right?

Shimel: Yeah, I hear ya. I mean, it really is. If we transported – you know, if we could do that – if we could transport someone from not that long ago, Evan, an hour or _____ _____ –

Kaplan: No. No.

Shimel: From 1997, ’98, right? I was helping an early ASP, Interliant. We were building – opening data centers, managing Lotus Notes and PeopleSoft and stuff like that.

Kaplan: Right.

Shimel: If I could take a NOC guy from there and show him today’s velocity and the fact that we actually do have telemetry and we actually are building tools that allow us to manage at that level, it would be like taking someone from colonial times and showing them highways with cars. I mean, the supports –

Kaplan: But, Alan, these solutions are still sitting out there. They’re a huge _____ _____ _____ –

Shimel: No – well, that’s the scary thing. Yeah, I mentioned my friend, ScienceLogic, my friend Dave Link. He was saying that’s his – you know, and they’ve done very, very well, and his thing was just replacing the Tivolis and the Unicenters and that generation, if you will, of network management, of systems management.

Kaplan: If I could tell you what, back in the late ’90s, is I was building an ASP also, based on the Aventail, the SSL VPNs, what we were standing on Netcool, back in the day, and things like that, _____ _____ –

Shimel: And Netcool was a new program, right?

Kaplan: Yeah.

Shimel: Before IBM bought it, right? It was one of the cool, new kids at the time.

Kaplan: Exactly. If I could tell you what somebody could take with Influx today and do, relative to what Netcool did back in the day, and the difference, right – first of all, they could do it for nothing. Forget paid licenses. And the amount of scale, the amount of data collection, and the ease of sort of visualization has dramatically – and all those _____ _____ –

Shimel: It’s phenomenal. Phenomenal, man. It’s just crazy. So, Evan, let’s bring this back to Influx. How does all of this now manifest itself with your business today?

Kaplan: Yeah. So that’s right. So we look at our businesses in two segments, right? We look at it as the instrumentation of and the collection of data around software, being the platform of record for this next generation of cloud software. And I don’t have to describe to you is is that, if, in the old days, it was an X Windows terminal talking to a Unix server app, today, there is no “there” there. There’s a virtual network; there’s VMs, containers, and microservices that are growing at exponential rate. The whole infrastructure is ephemeral, so the monitoring and the instrumentation workload has dramatically changed. So one side of our business is really focused on that, that opportunity, and we’d call that the “DevOps chain” of the business, right? Because it comes up into organizations through DevOps folks who bring in Influx and instrument.

The other side is IoT, which is completely different. So, while DevOps is largely metrics-driven, IoT is largely event _____ driven. And that’s the instrumentation of the physical world, right? So our watches, our clothing, our health care, our cars, our homes, are all being instrumented with sensors. The amount of data pouring in through that is driving whole other systems into business. And, while most of our time was spent on the management of software systems back, now it’s this deep, deep integration of software and hardware. Deep. And so our business breaks out into those two categories, largely.

Shimel: Got it. Got it. Evan, anything – any new news coming out of Influx you wanna share with our audience or –

Kaplan: You know, where – we have – you know, we’re almost constantly releasing stuff into the community on a regular basis, so no news that I’d share at this moment. We can touch base in three or four weeks. We have our big InfluxDays event. We’ll make some announcements there, but you can look for us to build increasingly sophisticated solutions that allow people to do their machine-learning workloads, their application tracing, their log and metrics, their asset management, on top of Influx. What we want is people to use us as the platform of record for all of these metrics and events pouring in.

Shimel: You know, we live in interesting times and I can’t wait to see where this all goes as well, so we’re about out of time, though, here. As I mentioned to you, the 15, 20 minutes goes so quickly.

Kaplan: Yeah, it really does.

Shimel: And you barely ever – you know, it is what it is. But, Evan, thanks for joining with us. Evan Kaplan, CEO, InfluxData. You know, so, in three, four weeks, you have your event coming up; maybe we’ll have you back. We can talk a little more about that. We’re doing a big – I didn’t even announce it yet, but I’m gonna announce it right here on the show with you – we’re gonna be doing a big virtual event, December 18th, called “Predict 2019,” and we’re gonna –

Kaplan: [Laughs]

Shimel: Yeah. We’re gonna be opening up the crystal ball and asking a lot of pundits and experts and so-called experts what their predictions are for what 2019 has in store. Maybe we can have you back then and we can do some crystal-ball gazing.

Kaplan: That’d be great, Alan. Always a pleasure. Always a pleasure.

Shimel: All right, my friend.

Kaplan: Have a great day. All right.

Shimel: Well, Evan Kaplan of North Woodmere and InfluxData, thanks for being our guest on this episode of DevOps Chat. This is Alan Shimel for devopsy.kinsta.cloud, and you’ve just listened to another DevOps Chat. Have a great day.

Kaplan: Take care.

— Alan Shimel

November 9, 2018
DevOps Chat: CI/CD with the Semaphore Platform

As the old saying goes, “speed kills.” When it comes to development, a lack of speed can kill, too. Marko Anastasov and the Semaphore team have strived to make Semaphore the fastest continuous integration tool in the market. With version 2.0 of Semaphore, they believe it truly is.

With his background in development, Marko brings a unique perspective in leading the Semaphore team. He knows what he and his colleagues like, and that is the road map for Semaphore. Have a listen to Marko tell us in his own words.

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. In today’s DevOps Chat, we’re gonna talk about a company called Semaphore. Their website is semaphoreci.com. And I’m happy to be joined today by one of their cofounders, Marko – and I’m not gonna pronounce his last name well, so I’m gonna let him pronounce it himself. Marko, your last name?

Marko Anastasov: Anastasov.

Shimel: Anastasov. Correct?

Anastasov: Yes, that’s correct. Hi, Alan, and thanks for having me. It’s a pleasure.

Shimel: Thank you for joining us. So, Marko, before we jump into Semaphore, let’s give our listeners a little bit of background on your – who is Marko Anastasov? How did you get here today?

Anastasov: Yeah. Yeah. Sure. So my core is, you know, I’m a programmer. Big fan of making – I’m a product-guy-slash-programmer. Maybe that’s kind of the intersection where I’m at, so I like making software products. Been doing that kind of almost since I was a kid.

Shimel: Mm-hmm.

Anastasov: And the kind of when I started being, let’s say, a professional is when things were going fast on rails, like Ruby on Rails, you know, Web development. And so I got into that, despite being kind of C++ nerd myself, originally.

Shimel: All right.

Anastasov: And I just kinda fell in love with ease at which you can kind of make something, put it online, create something useful for other people. I did a couple of kinda noncommercial projects and started a small consultancy, with my cofounder Darko, who is also a cofounder of Semaphore now. And, you know, we’re both also big fans of clean code, doing things – you know, software craftsmanship, all that kind of stuff. And, as we kind of grew ourselves professionally in that whole area, it wasn’t long till we, of course, realized the benefits of processes like, you know – it wasn’t called, really, “DevOps” at that time, ten years ago or something, but we identified, “Okay, continuous integration is obviously a process that any kind of – if you wanna keep moving fast, as you kinda work on a project, this is what you gotta do.”

And so, through kind of adoption of these practices in our own company and kinda having an eye on an ambition to create a tool that other kind of developers will also find useful, we started prototyping and eventually launched Semaphore in 2012. And, from that point, it’s kind of all we do and it’s been a great ride so far, you know, leading all the way to today’s interview with you.

Shimel: Sure. Hey, man, thank you. You know what? It’s funny; it’s not easy, but, when you ask people to tell them about themselves, you don’t wanna blow your own horn too much, but you wanna tell people what’s going. And I think you did a good job with it. So let me – before we jump into Semaphore, you mentioned something that I’ve heard from a lot of other developers, people in the DevOps space, whether they be vendors, practitioners, what have you, and that is they were doing what’s called a “DevOps-like things” before we called it “DevOps.” You know what I mean? And so were you into Agile? Was that something that kinda went with that?

Anastasov: Yeah, I would say yes. Although I never – it was always – Agile itself has always been a bit of a vague concept for me. The first maybe introduction to that kind of thought space, for me, was the “Extreme Programming Explained,” the book by Kent Beck, which –

Shimel: Sure.

Anastasov: So it was more like a practitioner’s path for me, so, as you’re in development, working in small iterations, you know, you’re breaking things down, being ready to adapt to change, kind of not being married to some kind of roadmap, and so on. So it was definitely something that we identified as a good way to operate, but even before maybe the Agile backslash – I don’t know. I didn’t use the word “Agile” myself that much, but –

Shimel: Well, you weren’t doing Scrum or taking Scrum classes and stuff.

Anastasov: Not really.

Shimel: But, certainly, sort of the Agile way of doing software development, right, before we called it “DevOps” or anything else, was kinda ingrained in you, if you will. So then I always – and this is something, Marko, I’ve asked other people about – so one of the unique things about DevOps is we sort of build on that Agile, we build on Lean, but, certainly, ops gets involved.

Anastasov: Yeah.

Shimel: When did you kinda make that jump, as sort of a programmer/developer, to say, “Hey, it’s really important we get the ops folks, the ops functionality, kinda built in there”?

Anastasov: So –

Shimel: And I don’t wanna put words in your mouth.

Anastasov: Yeah, sure. So, for me, it was about – so I come from a kinda small company environment and that was kinda my beginning. And so, in that kind of setup, if you’re kind of being responsible for a product, means that you’re also responsible for the operational stuff or that there is maybe a shared responsibility among developers to some degree, but there’s always somebody who kinda specializes, at least for a specific project, for doing the operations. And there is – I think it’s very healthy, kind of, for a programmer to kinda be exposed to these things because you – as you kind of experience this firsthand, you kind of – let’s say you’re ready to – you’re not maybe – you don’t have patience that much for things that kinda get in your way of getting the job done.

So, if you kind of practice not repeating yourself in writing code, you wanna kind of practice the – try to practice the same thing, when you kinda deal with infrastructure. So I think that’s kind of the line of thought that brought us the kind of infrastructure-as-code, you know, kind of EDU and the movement and the tools force.

And, once you maybe grow out of that kinda maybe very small team kinda environment, I think what you see then is you see maybe the bigger picture of, if you think of continuous delivery as a broader objective of being able to deploy anything that you’re working on at any point in time, as the ideal state that you wanna be in, then being really good at ops means that, for example, if you’re doing microservices, you’re not really that even Agile in the ’90s, maybe, way, if it takes two weeks for somebody to provision you the resources so you can just get started and write the first lines of code in your microservice. So if that can be reduced to five minutes or an hour or something, that’s really great, so.

Shimel: Yeah.

Anastasov: Yeah.

Shimel: So this is something, Marko, again, back when I first started devopsy.kinsta.cloud, four, five years ago, there was this big debate over “Is DevOps different at a small company versus at an enterprise?” And, of course, there’s differences between working at a small company versus an enterprise, right? In small companies, you do wear multiple hats. You don’t have the luxury of having a full ops team and a full separate dev team and QA and business architects and all that kind of – you know, you don’t have that. Everyone pitches in and does what they gotta do, where, in large enterprises, you sometimes do have that stuff.

And so, obviously, there’s a difference between them, but, at the end of the day, DevOps is DevOps, right? It’s about doing continuous integration, continuous delivery, and so forth. So I think that’s a – you know, what you’ve described is very not out of the ordinary. I think that’s sort of the path, the track that these things follow.

Anastasov: eah. Yeah. I think it’s about – whether you’re coming from a small or you’re working at a big organization, ultimately, it’s all about “How do we move fast so that we just kinda of – ” the ideal state is when we’re all kind of in creation mode, all the time or as much as possible.

Shimel: Sure.

Anastasov: And it can happen in a small team as much as, I think, in a large team, that things can get stuck, if you maybe – I don’t know – pick the toolset that’s maybe not fit for your needs, where you kind of want to reinvent the wheel or – so I think that, regardless of maybe the team size or the technology stack, the decisions should always be kind of “Okay, what will enable us to kinda stay focused on creating value, versus kinda being maybe, in some ways, slaves to the toolchain?”

Shimel: Got it. All right. So let’s jump in a little bit – you know, we got off on a bit of a tangent, but let’s talk about Semaphore.

Anastasov: Sure.

Shimel: What is it? How did that – I mean, I think you’ve given us a little background on how it came about. Talk to us what’s Semaphore about.

Anastasov: So Semaphore is – generally, our mission is to enable teams to build great products at high velocity. And we do that by making it as easy as possible to enable continuous integration and continuous delivery processes in their organization. We’ve started way back in – about six years ago, when we launched Semaphore initially, it was like we were looking at the tools available and, from our perspective, services like GitHub or, you know – on GitHub, you do a few clicks and you get your repository; you’re ready to collaborate with other people. We looked at, for example, there were already platforms-as-a-service, like Heroku, for example, where, again, in a couple of commands, you kinda have your entire application up and running and you’re ready to kind of iterate and get something to customers very quickly.

Shimel: Mm-hmm.

Anastasov: But, in the area of, for example, just having a scalable continuous integration process, basically, at that point, Jenkins was the only tool that’s available. And kind of this was initially like “scratch your own itch” kind of thing, but, for a lot of people, maintaining and scaling and learning how to do all that, the infrastructure for building and testing their code isn’t really their core business purpose or where they kind of create value. So our initial goal was like, “Okay, can we create something which is as easy to use as, for example, GitHub, but for continuous integration?” so that you just kinda click to connect your GitHub account, select your repository, and we, in many cases, automatically infer what the CI build should be and kind of you’re just off the ground. You have the full continuous integration process automated and running in the cloud.

And so, pretty soon after that, of course, listening to our customers, we implemented some features that enable continuous deployment so that customers or open-source users can keep track of releases and manage different environments. And so what’ve – throughout the years, we’ve kind of evolved from – so, traditionally, it was mostly about when people think about this space as “hosted CI,” so it’s kinda like there’s some – but, at this point, there’re a couple of options, of course, other companies doing the same function. And I think the perspective’s like, “Okay, it’s very – ” but, at this point, 2018, it’s pretty straightforward to kind of automate the testing, using some kind of a cloud service.

But that’s not – if we go back to kind of what we also discussed in the beginning, if the goal is to accelerate kinda the entire engineering organization, there’s more to just running tests, you know? So every tech leader wants to – I mean, their objective is to deliver bug-free products to customers as quickly as possible. So we’re talking not just about testing but also configuration and delivery processes that often involve multiple technology stacks, which, of course, evolve over time. Now we have container technology, for example, which we didn’t have –

Shimel: Changed the game.

Anastasov: Completely changed the game. So the way to do this is to basically implement continuous delivery so that, step one, you automate all the processes and step two is to kind of optimize them, but using Semaphore for automating all continuous delivery processes has so far been – it wasn’t able to support, let’s say, every process that’s needed, so this is why, this November, we’re excited to present the brand new version of Semaphore, which is —

Shimel: That’s Semaphore 2.0, right?

Anastasov: Exactly. Yeah.

Shimel: Mm-hmm. So, Marko, let me ask you this. I think you guys are pretty proud; on your website, you mention your bootstrap. You know, it’s interesting and, when you look at the CI/CD space, there’s a lot of great open-source, free tools, right? Jenkins, obviously, is the obvious one, but CloudBees, of course, has the commercial version, if you wanna call it. CircleCI, Travis – what’s the other one? – City – I forget the name of it. You and I both know there’s several pretty popular CI/CD tools, ARAs and all of this stuff. What do you think the special sauce is for Semaphore, if we’re talking – and our audience is developer-heavy, DevOps-heavy – why Semaphore versus maybe some of these others?

Anastasov: Sure. We’ve always been focused a lot on speed, so “How can we not just provide a tool that automates something for people, but can we give them something preferably out-of-the-box, so that they just save time, comparing to whatever else they were using previously?” So one of the kind of foundational things, when you use Semaphore, is that basically we kind of periodically keep measuring this and it always stays true, is that Semaphore is twice as fast, comparing to all other competitors in the cloud space, in terms of just pure performance.

So this alone can kinda save hours of engineering time to any team. Of course, it depends on the size of the projects and the team, but, if you kinda think back, kind of the fully-service hourly rate of developer in US is about $150.00. So, if you can do something to optimize that, we think it’s a huge win. Over time, we’ve kind of made steps forward, in terms of –

[Phone ringing]

Is this somebody from Jenkins calling to – [chuckles]

Shimel: Yeah, it could be. [Laughs] That was pretty timely, but, no, I think it was something else. Go ahead.

Anastasov: Yeah. So we provide tools that, for example, automatically paralyze the CI builds for projects, so people – which is, you know, large projects, for medium or bigger-sized teams with 100 or more developers, they typically have CI builds that run for hours. And the feedback loop – the kind of feedback loop in which you find yourself working, as a developer in such a project, it’s a pretty miserable experience. So you kind of become defensive. You work in wandering branches; you don’t merge off and – you know, you have flaky tests and so on. So, essentially, what we’ve seen, when people adopt Semaphore is, if they start using our automatic paralyzation feature, they go from, in some cases, from over 2 hours to something like 15-minute CI build. And it’s literally like they just needed to drag a slider and it worked. So we try to do things that really kind of improve the productivity of the teams.

And so far, on the market also, it hasn’t been – in Semaphore 2.0, we’ve kinda took a lot of kinda learning that we picked up along the way and from our customers, especially the bigger customers, and, first of all, we made it really easy to create complex pipelines for companies that need to model the continuous delivery processes. On the other hand, what we think is pretty important is that, so far, this kind of cloud-based CI and CD tools – and Semaphore was part of this. In fact, we kind of initiated this idea of kind of charging per worker or per concurrent some kind of a machine that’s executing your stuff, your jobs.

So, with Semaphore 2.0, we made the decision to kind of provide a service which is, let’s say, truly cloud, so it scales automatically to your needs, so you only pay what you use and you never really have any waiting time, which is a huge bottleneck we see in many organizations. They would maybe purchase some resources on a monthly or annual basis from Semaphore or Circle or some other product, and it’s like, if they are, let’s say, really busy in a certain period of a day or week, their CI just doesn’t process what they need. So we think that, with auto-scaling, developers will always be able to kind of get their work done quickly and stay in the zone as much as possible.

Shimel: Got it. Hey, Marko, man, I would love to talk to you for another hour about maybe state of developers. And I do think you’re right – while speed is really important, as a benefit or an advantage to Semaphore, I think we’re in a world where developers are the top alpha predator, right? The most difficult kind of shoes to fill, the hardest jobs to get. Giving them an environment that keeps them happy, that keeps them working, if you will, in a good way, is a huge bonus than, frankly, making them work with crappy tools. I’m not calling anybody’s tool “crappy,” but I’m just saying, given the choice, I think developers would – they’d wanna work with tools that make their life easier and make it a better experience for them. But we’re at a half-hour and this was way more than 15 minutes, man, so we’re gonna need to end this. Maybe we can pick it up a second – in another chat in a couple weeks or whatever.

Anastasov: I’d love to.

Shimel: But, for now, we’ll call a wrap on this episode of DevOps Chat. Interesting conversation with Marko Anastasov. Close?

Anastasov: That’s correct. Yeah.

Shimel: All right. Cofounder of Semaphore. The new Semaphore 2.0’s coming out; check it out – great tool for CI. Until next time, this is Alan Shimel for devopsy.kinsta.cloud and you’ve just listened to another DevOps Chat.

— Alan Shimel

November 7, 2018