Author: Alan Shimel

  • DevOps Chat: Chef Habitat Project Continues to Mature

    DevOps Chat: Chef Habitat Project Continues to Mature

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

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

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

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

    Audio: Chef Habitat

    Transcript: Chef Habitat

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

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

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

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

    Shimel: Thank you.

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

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

    Blake Irvin: Yep.

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

    Irvin: It’s called smartB.

    Shimel: smartB.

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

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

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

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

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

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

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

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

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

    Drew: Yeah, yeah.

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

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

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

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

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

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

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

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

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

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

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

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

    Irvin: Yeah, you could say that.

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

    Irvin: Yeah, that’s true.

    Shimel: Let’s talk about why.

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

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

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

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

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

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

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

    Shimel: Wow.

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

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

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

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

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

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

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

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

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

    Shimel: So, it’s Habitat.sh?

    Drew: Yeah, yeah.

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

    Drew: Thanks so much.

    Winsor: Thank you.

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

    — Alan Shimel

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

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

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

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

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

    Audio

    Transcript

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

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

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

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

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

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

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

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

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

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

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

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

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

    Chashper: Correct.

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

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

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

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

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

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

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

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

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

    Shimel: Mm-hmm.

    Chashper: Yeah, so that’s for that.

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

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

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

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

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

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

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

    Shimel: Really?

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

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

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

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

    Shimel: Got it.

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

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

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

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

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

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

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

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

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

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

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

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

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

    Parlette: Yeah.

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

    Parlette: Sure.

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

    Parlette: Sure.

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

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

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

    Parlette: No problem.

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

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

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

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

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

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

    Chashper: Yeah.

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

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

    Chashper: Yes, absolutely—thank you.

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

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

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

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

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

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

    — Alan Shimel

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

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

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

    Microservices & Containers

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

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

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

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

    Audio

    Transcript

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

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

    Jim Scott: Thanks, Alan.

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

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

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

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

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

    Shimel: Excellent.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Shimel: Really?

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

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

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

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

    Shimel: No.

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

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

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

    Scott: Exactly.

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

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

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

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

    Shimel: Really? Wow.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Scott: Yeah.

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

    Jim Scott: Yeah, sounds great.

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

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

    Shimel: Okay.

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

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

    Scott: Yeah, that’d be great.

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

    Scott: Thanks, Alan. Appreciate it.

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

    — Alan Shimel

  • NGINX Delivers New Products to Manage Microservices

    NGINX Delivers New Products to Manage Microservices

    At its annual user conference in Portland, Oregon, in September, NGINX delivered releases focusing on the application platform market and support of delivering microservices architectures:

    • NGINX Plus, an application delivery controller that combines a load balancer, content cache and web server.
    • NGINX Controller, a centralized management and monitoring platform for NGINX Plus, which orchestrates the delivery of applications across multiple environments, enabling companies to continuously deploy and update applications using tested and proven policies.
    • NGINX Unit, a multi-language server for applications, designed to work in highly dynamic environments. It features a full REST API that can be fully automated and used to deploy new application versions with no service disruption. It currently supports PHP, Python and Go with more language support coming soon.
    • The NGINX Web Application Firewall (WAF), powered by ModSecurity, which protects web applications against various Layer 7 attacks and provides DDoS mitigation, real-time blacklisting and audit logging.

    In addition to launching the NGINX Application Platform, the company has added the ability to use NGINX Plus as a Kubernetes Ingress Controller. Based on the open-source NGINX Ingress Controller for Kubernetes, this new feature enables the deployment of applications within Kubernetes and Red Hat OpenShift anywhere across a cluster so they can be reached by outside traffic.

    While these products combine to deliver a complete and manageable microservices solution, the most interesting of these is NGINX Unit. According to Owen Garrett, head of products, the complement of tools facilitates management of both north/south and east/west traffic for cloud-native applications. It’s small, lightweight, fast, polygot-enabled and programmable through an API and works with other Unit instances to deliver a service mesh.

    Key features of Unit that should be of particular interest to businesses deploying microservices relate to the ability to foster continuous delivery. For example, when the router accepts new configurations from the Controller process, the worker threads start to handle new incoming connections with the new configuration, while old connections can continue to be processed by the threads according to the previous configuration. That is: Router worker threads can work simultaneously with several generations of configurations.

    Additionally, Unit uses interprocess memory to communicate with the applications, thus allowing the Unit to provide greater agility in routing of HTTP requests. So, rather than forcing the application to directly listen, they can delegate network handling to the service mesh providing for increased scalability. They accept the clients’ requests, pass the requests to the application processes, get responses back from the applications and send the responses back to the clients. Each worker thread polls epoll or kqueue and can asynchronously work with thousands of simultaneous connections.

    — Alan Shimel

  • CA World 2017: DevOps As Far As the Eye Can See

    CA World 2017: DevOps As Far As the Eye Can See

    The show floor for CA World 2017 had one inescapable, very obvious feature: There was DevOps as far as the eye can see. No kidding. It was a stunning reminder that this multibillion-dollar-revenue company has gone all-in on DevOps and related technologies. While we know CA has spent almost a billion and a half dollars acquiring DevOps-related companies in the last year, the effect on this year’s CA world was dramatic.

    CA World 2017

    What Was All That DevOps?

    CA World is organized so that most of the sessions except the keynotes are all conducted right on the expo floor. The floor is broken into distinct areas. Each area has its own theater, where sessions on the subject of that area are conducted. It is actually a great way to organize a conference like this and saves you from going to room to room, floor to floor.

    DevOps everywhereCA World 2017’s main floor segments were:

    • Automation – Basically CA Automic and all of its related partners, integrations and offerings. Primarily a DevOps area.
    • DevOps: APIs and microservices – This has been a staple of CA World now for several years. APIs again are related to DevOps, automation and microservices.
    • Mainframe -This area focused on enabling customers to extend DevOps practices to legacy applications, which most critically included a modern mainframe experience for enterprise developers
    • DevSecOps – There was a whole area dedicated to DevSecOps. Primarily the Veracode team—they had their own theater and lots of space and attention in the middle of the floor. The DevSecOps section did bleed into a smaller security section with the legacy CA security tools.
    • Agile Management – All things agile, based primarily on the Rally business CA bought a few years ago.
    • DevOps Agile Operations – APM and things of that nature.
    • DevOps CD – This area also included continuous testing and the new CD Director.
    • Advanced analytics
    • MSP Zone
    • CA Agility Zone
    • CA Acceleration Zone

    As you can see, a lot of DevOps right there.

    All Your DevOps Are Belong To Us

    But more than the real estate of the show floor, even the messaging coming from CA was “all DevOps, all the time.” The keynotes from the executive team were heavy on DevOps and related topics. The sessions at each theater featured household-name customers mixed with partners and CA people discussing DevOps-related topics.

    One presentation I found interesting was from the GM of the DevOps continuous delivery business, Jeff Schaeffer. It was a demo of a new product CA rolled called DevOps Continuous Delivery Director, a SaaS product that is a UI wrapped around a lot of the CD-related solutions from CA and leading partners. All kinds of testing, including testing from Sauce Labs and security testing from Veracode was possible from within the interface.

    I moderated a good panel on Continuous Testing: Shifting Left, which was well-attended. I was joined by customer reps from Cigna, a large financial institution, Groupon and others. This was also in the DevOps CD area.

    The mainframe theater stage featured a DevOps panel session to showcase a cross-BU perspective. Panelists included Aline Gerew from Automation, Steve Feloney from Continuous Delivery, Scott Morrison from APIs and Microservices, and Jean Louis Vignaud from Mainframe. The video recording is not yet available, but I was able to catch one snippet in a promotional tweet – APIs enabling IAM on Mainframe

    What’s Still Needed?

    As impressive as the DevOps show by CA was, what is missing is a tighter integration between the DevOps solutions. While some rudimentary integration is in the works, really making a 1 + 1 = 3 equation will provide the enhanced value to customers that such a broad set of DevOps solutions promises. I spoke to executives from just about every DevOps-related business unit and to a person they mentioned that this was in the works. But what was pleasantly surprising was the mandate not to force tighter integration that would stunt the innovation that each of the DevOps companies brought with them when they were acquired by CA.

    Of course, we will see if this remains the case. However, I did speak with employees at each of the units and they were all happy with how CA has handled the acquisitions to this point.

    Conclusion

    It is hard to argue when a software company the size of CA Technologies makes such a bold statement regarding DevOps. The company is clearly betting its future on DevOps being the backbone of the modern software factory.

    — Alan Shimel

  • The DevOps Cha-Cha from DOES San Francisco

    The DevOps Cha-Cha from DOES San Francisco

    DevOps Cha-ChaThe 4th annual DevOps Enterprise Summit (DOES) in San Francisco this week was, in my opinion, the best one yet. Lots to report about, but I wanted to call out a new trend I am seeing that I call the DevOps Cha-Cha. You remember the Cha-Cha: three steps forward, two steps back, cha-cha-cha. Actually besides being a great dance with the right beat, that same three-steps forward, two-steps back is about what you would expect from large enterprises that are undertaking profound digital transformations.

    I say that this is normal because, despite all the great firsthand accounts of DevOps transformations on display at DOES this week, there was a bit of a whispered undercurrent. More than several people I spoke to talked about the fact that “this DevOps thing isn’t that easy.” Others spoke about the large number of “failed DevOps transformations or implementations.” Obviously, as the editor in chief of devopsy.kinsta.cloud, I might have a skewed view of this, but let me put in my 2 cents and then some on this subject.

    DevOps Transformations Are Not Easy

    First of all, no one ever said DevOps transformations would be easy. I’m not sure why anyone would even think that. Changing cultures can be gut-wrenching. Sometimes it means replacing people who just can’t wrap their heads around a new culture and way of doing things. Other times it means ripping up the way people and teams interact with job roles and positions. Change is never easy. Frankly, if it was easy, everyone would have done it already. That is just the cultural piece. Imagine coupling that with new tools, new processes and new ways of building, testing and deploying software. Again, I’m not sure why anyone would think such an undertaking would be easily accomplished.

    Is anything truly worthwhile ever that easy, though? The real question is, Is the pain and trouble worth it? If you were at DOES this year or have read other success stories around DevOps and digital transformation, I think you will find the answer is, “You bet it is.”

    If you go into a DevOps transformation thinking it is going to be easy, you are setting yourself up for disappointment. Doing DevOps is not just a matter of being one of the cool kids on the block or trying something new for kicks. It means you are dedicated to seeing it through. It means you are going to think through, plan, learn and do what needs to be done.

    Failure Is Not An Option

    Also important to keep in mind—and this is really the meat of it—is that DevOps transformations shouldn’t and don’t proceed in a smooth linear manner. While at a macro level over a period of time you should be able to discern progress (depending on how you define progress), when you drill down you find fits and starts, steps forward followed by steps backward. There also will be steps sideways and sometimes no steps at all in any given moment. But like life itself, that is how DevOps transformations go.

    I was speaking with someone at DOES (I don’t remember this moment who), who told me every business plan they had ever seen had revenue growth like a hockey stick—just straight up on sharp angle. The same is true for the benefits realized in every DevOps transformation plan. If only DevOps and life worked that way. It is the rare bird that has shows a revenue line that is straight and angled that way.

    Real life is filled with starts and stops. You learn from your mistakes; you get it right the next time. Sometimes you need to take a step back to take more steps forward. DevOps is no different. It is not homogenized and doesn’t always (if at all) proceed smoothly. The real test is whether over a longer period of time you are achieving your goals (did you even define your goals or just thought DevOps would fix everything?). You can’t look at any given moment or event and say, “Our DevOps transformation was a failure.”

    Your DevOps transformation is only a failure if you end it before you get started, or before you can overcome the roadblocks in the way. At its heart DevOps means we keep improving. Think of those failures and feedback loops. You do your post mortem, you learn from your mistakes and you keep plowing ahead. It is only a failure if you let it be one by stopping.

    The DevOps Cha-Cha

    In my opinion, you look at your failures during your DevOps transformation and you make lemonade from those lemons. You learn from them and keep moving forward, one foot after another. Imagine a hot Latin beat in your head. Start moving, one, two, one-two-three, one, two, one-two-three, that’s it—now you’re doing the DevOps Cha-Cha. Keep the beat, keep dancing and keep doing DevOps.

    More DOES Coverage

    If you are interested in hearing what some of the speakers, attendees and sponsors of DOES 2017 in San Francisco have to say, be sure to visit our DevOpsTV YouTube channel, where we have a DOES San Fran 2017 playlist. There are about a dozen videos up there now, but will be adding to that every day as editing completes.

    Also, we have lots of coverage of past DevOps Enterprise Summits. Here is one for this year, but search devopsy.kinsta.cloud for lots more and DevOpsTV for videos of years past.

    — Alan Shimel

  • Bringing Balance To The Force Between DevOps And Security

    Let’s not kid ourselves—I am not sure there ever has been balance among Dev, Ops and security. But with the advent of DevOps, automation and the cloud, whatever balance there was between DevOps and security seems to have been lost. DevSecOps, or DevOps Security, has sought to restore the balance between DevOps and security. At the end of the day, though, it can appear as though they are still working at loggerheads. See the illustration below:

    devops and securityHow do you bring balance to this equation? A new approach, perhaps? Puppet and CloudPassage have teamed up on a white paper that does a decent job of outlining the issues here and suggests some solutions. The diagram above is taken from that paper, as a matter of fact. The paper is titled, “A New Approach for Security DevOps Environments in the Cloud.” You can download it from our download library.

    While there are no magic bullets for making Dev, Ops and security head down to the beach and sing “Kumbaya,” there are things you can do to make a real partnership here. That includes shifting security left and working with DevOps tools such as Puppet, Jenkins and others. But most important is making members of each team feel like they are all part of the same team. All the tools and APIs in the world don’t take the place of good culture and fostering a “we are all in it together” mentality. It’s all in this white paper, so download it—and, while you’re at it, check out the several other great DevSecOps assets available in our library.

    Our download library is quite stocked with lots of useful content. If you are looking to learn about DevOps and related subjects, it is a great place to start.

     

    — Alan Shimel

  • DevOps Connect: DevSecOps Days @ RSAC Call For Speakers Is Open

    DevOps Connect: DevSecOps Days @ RSAC Call For Speakers Is Open

    For the 4th year devopsy.kinsta.cloud is proud to be producing DevOps Connect: DevSecOps Days @ RSA Conference. The event will be on Monday, April 16th, 2018. RSAC is the world’s largest security conference and so the perfect place to hold what we think of as the best day of DevSecOps. You can get full details at the DevOpsConnect.com site. The call for speakers is open now through December 15th.

    devops connect: DevSecOps Days 2018 @ RSAC

    Why Speak at DevOps Connect: DevSecOps Days @ RSAC

    If you have a great DevSecOps story to tell, this is the conference to do it at. Last year we had almost 1000 people stop in during the full day of sessions to catch some of the top speakers in the space, as well as many up and coming thought leaders giving us a fresh look at the latest trends in DevOps and security. This year we expect over 1200 people or more to attend the sessions. Sessions are also video taped and then put up on DevOpsTV for later viewing.

    It is a large stage that gives our speakers a great pulpit to share their expertise and experiences. The fact that it takes place on the backdrop of the largest security show in the world means the spotlight is even brighter.

    More importantly, this is your chance to lead. Your chance to give back to the community as we forge a road ahead towards better, faster more secure applications. Unlike some other conferences, there is a strong preference here for speakers to be practitioners in the space rather than vendors selling to it (though not all vendors are bad, they speak with more practitioners than anyone and do add to the body of knowledge). So there is a strict, no vendor pitches policy.

    What Are We Looking For?

    In fact here are some of the guidelines we are looking for:

    We are looking for practitioners to discuss the unique challenges of adopting security into the DevOps pipeline, the obstacles to security being a contributing and valued partner in DevOps and the ways to overcome them. Specific topics we are looking for include, but are not restricted to:

    • How did you get senior management buy-in? What did you do? How did you quantify the business value?
    • Examples of security teams being integrated into the CI/CD or DevOps process
    • How did you overcome objections inside the organization?
    • How did you design and implement effective controls to mitigate security risks?
    • Which business area (and application) did you start with, why, and what did you do?
    • What were the top challenges, and how did you overcome them?
    • What were your top mistakes, and what advice would you give as a result?
    • In-progress stories (and even nightmares) are welcome!

    Also, beyond the practitioner preference, we are looking for a diverse set of speakers that closely matches the real world. There will be something approaching 50,000 people attending RSA Conference this year. We want DevSecOps Days to reflect that diversity.

    All speakers receive passes to DevSecOps and an expo pass to RSAC itself.

    How You Can Attend DevOps Connect: DevSecOps Days @RSAC

    If you aren’t ready to share your DevSecOps story with the world quite yet, you can still participate and attend DevSecOps Days @RSAC.  All you need is any kind of pass for RSAC. If you are not speaking and have not purchased a ticket yet, or would like a complimentary Expo Hall pass on us, please use these codes.

    • $100 Discount off of Full Conference passes – 18UDEVOPSFD
    • Complimentary Expo passes – 18UDEVOPSXP

    The free expo pass is enough to get you into DevSecOps Days and expo show floors all week, as well as the keynotes. The $100 discount is off a full conference pass good for all sessions.You can register using the codes above at: https://www.rsaconference.com/events/us18/register

    Wait, there’s more

    Following the day sessions, the 5th annual No Wine-ing DevSecOps Cocktail party will take place @ Jillians, San Francisco, 4:30pm till 6pm, down the block from the Marquis. Registration for the No Wine-ing event is required and attendance is free. Register here.

     

     

    The Security @ the Speed of DevOps panel and luncheon, featuring an all star lineup of DevSecOps experts will take place on Tuesday, April 17th, 11:45am, again @ Jillians. The panel will be based on the 2nd annual Security @ the Speed of DevOps reports by George Hulme. Once again admission and lunch are free, but registration is required. Printed copies of the report will be available to attendees.

    So if you would like to tell your DevSecOps story to the world, please apply to speak at DevOps Connect: DevSecOps Days @ RSAC. But whether you do or do not, if you are going to be in San Francisco on April 16th, please join us for what should be another great day of DevSecOps learning, networking and growing at RSA Conference.

    Also many thanks to our sponsors, Sonatype, White Hat Security, Aqua Security, CA Veracode, Checkmarx. If you are interested in sponsoring, write sponsor@devops.com

    — Alan Shimel

  • DevOps Chat: Aqua Security Seeks To Secure Containers

    DevOps Chat: Aqua Security Seeks To Secure Containers

    The migration to container-based application infrastructures is accelerating at a faster pace even than we saw with hypervisor-based infrastructure 18 or so years ago. Hand in hand with this is the race to provide better security solutions that are native to and purpose-built for containerized environments. Aqua Security has established itself in the container security arena, recently raising $25 million in capital funding as it seeks to lock down the container security market.

    In this chat, we sat down with Rani Osnat of Aqua Security to discuss the recent funding round and the state of the container security market. Below is the streaming audio of our discussion. Below that is the transcript of our discussion.

    Audio

    Transcript

    [su_pullquote align=”right”]Rani Osnat[su_custom_gallery source=”media: 1739530″ width=”100″ height=”100″ align=”center”]
    Rani Osnat has more than 20 years of enterprise software industry experience, in project management, product management and marketing, including a decade as VP of marketing for innovative tech startups in the IT security and cloud arenas. Previously Rani was a management consultant in the London office of Booz & Co. He holds an MBA from INSEAD in Fontainebleau, France. Rani is an avid wine geek, and a slightly less avid painter.[/su_pullquote]

    Alan Shimel: Hi, everyone. This is Alan Shimel for devopsy.kinsta.cloud and Security Boulevard, and welcome to another chat.

    Today’s guest is Rani Osnat, VP of Marketing for Aqua Security, one of the leaders in the container security market, and Rani, welcome to our DevOps Chat.

    Rani Osnat: Thank you, Alan. Thanks for having me.

    Shimel: Thank you. Thank you for being here. So, Rani, the big news out of Aqua recently is, by anyone’s yardstick, a large raise of capital to fuel Aqua’s continued growth.

    Osnat: Yep, that’s correct. We raised $25,000,000.00 in a series B round led by Lightspeed Venture Partners, which is a very well-known tier one VC.

    Shimel: Yep.

    Osnat: And, it’s—well, to the best of my knowledge, it’s the biggest funding round in our space in continuous security to date, and it also brings total funding for us to $38.5 million.

    Shimel: That’s fantastic.

    Osnat: So, we’re, I think, in a pretty good position to capture what we think is a tremendous opportunity in this market.

    Shimel: Sure. And so, Rani, we were talking off mic prior to recording today—you know, beyond the sheer magnitude of the number, right, 25 is a big number, 38 is a bigger number—but beyond that, there’s also the validation. Which is, you assume a company like Lightspeed Ventures, Microsoft Ventures is another investor in the company, Shlomo Kramer, of course, from Check Point is another investor. You would assume these people are pretty bright people and they don’t throw their good money away. That, if they’re investing this money, they invest it for two things. No. 1, they see the opportunity in the market, so the market itself is ripe and worthy of that sort of investment. And then No. 2, that the team and the product at Aqua are also worthy of the investment.

    Let’s first talk about the market, if we can, though. I mean, so this is a validation, I think, of the container security market, if you will, right?

    Osnat: Yeah.

    Shimel: The containers are real, that securing them are real, and there’s gonna be a big market for that coming up. What do you think?

    Osnat: Yeah, I mean, definitely, when we started Aqua just under two years ago, we didn’t quite know how fast the market would move and what kind of market it would shape up to be. And fairly early on, even when we were in beta in early 2016, it became fairly obvious that this is an enterprise market. That is that, you know, some of the biggest adopters of container technology are not just Silicon Valley startups or web-scale companies that kind of invented this, but Fortune 500 enterprises across verticals like financials, insurance, retail, aerospace, manufacturing, and so forth, as well as government.

    And so, paradoxically, you would expect this kind of new technology to be first adopted by startups, but the real boom in adoption comes from the fact that enterprises are adopting it very quickly, and I think there are several reasons for that. One is that the benefits of using containers are overwhelmingly positive, and the benefits are pretty immediate. So, you can see benefits in agility in terms of how fast you can deliver applications to the market, you can see benefits in moving to the cloud, and reducing your infrastructure costs and operational costs. And you can see much better control over what kind of applications you’re deploying, where, and when, et cetera, largely through automation.

    So, these benefits are overwhelming, and additionally, containers are easy, right? So, it’s—you know, one of the things that made containers, which in itself is not a new technology, it’s been around for a while, but what companies like Docker did is make containers very accessible and very usable. And so, the fact that they’re easy to use makes adoption easy as well, and you know, you kind of see a pincer movement of, on the one hand, grassroots adoption through developer and DevOps teams of containers, so they develop applications using containers. And on the other hand, you’re seeing a top down approach of, you know, CIOs, CTOs seeing the benefits of containers, adopting them, or mandating their use for, for example, cloud native applications to drive cloud usage, hybrid cloud, cloud migration—all of those good things.

    Shimel: Absolutely. So, Rani, you know—granted, I’m not as involved in container and container security as you are, obviously, but to me, a couple of different thoughts. Number one, in my limited—granted, limited expertise, containers aren’t that easy, right? I mean, I think when we talk about containers and then, like, Kubernetes and stuff to manage the whole environment—for someone who hasn’t developed on them before and is used to developing, let’s say, in VMware or in Bare Metal, there is, there’s a learning curve. Maybe once you pick it up, it’s easier.

    But the other thing is, I always try to compare sort of container adoption, let’s say, to hypervisor adoption or VMware adoption, and I would say that containers, their adoption curve is higher or steeper, faster than sort of hypervisor’s.

    Osnat: Yeah, that’s correct.

    Shimel: And really what I see, the last couple—you know, we’re always doing surveys here at devopsy.kinsta.cloud, announcing the new Security Boulevard site—what we’re seeing is, you know, we always saw people messing with the containers, right? R&D testing, what have you—but the numbers of containers, the percentage of companies that have containers in product deployment, you know, in real, frontline stuff? Where it was—jeez, just two or three years ago was low teens, below 20 percent—is now climbing, getting near that critical mass number, right, of 50 percents and stuff like that. And that’s huge, right? You’re talking about early adopters moving to mainstream in a matter of months, and that’s —

    Osnat: That’s correct.

    Shimel: — that’s the numbers you see as well?

    Osnat: Yeah, we see that. And again, I don’t think this would’ve been the case if containers weren’t easy, as I said. I mean, there’s always a learning curve with new technology, but I think if you’re a new developer, a new programmer working today, working on a greenfield application, there’s really no reason for you to use something that is not containers unless it’s something obscure for technology reasons.

    But mostly, it’s a much easier way to develop applications quickly than previous approaches. And I think, you know, if we take a broader picture, a container is—this adoption of containers does not occur in a vacuum, and we actually see a convergence of three trends that are kinda coming together and containers are probably the biggest enabler of those three trends. And these trends are happening independently of each other. So, you know, one trend is one that you are very familiar with, it’s the name of your site, is DevOps, you know, the proliferation of DevOps as a method, process, organizational philosophy, et cetera, which is all about delivering applications faster and in a more continuous way, and containers make that easier than before.

    Another trend is the move to microservices architectures, you know, for web applications or cloud native applications, which is basically adopting what web scale companies like Facebook and Twitter and Netflix started, and now bringing into the mainstream. That, too, is facilitated to a great degree by containers, because implementing microservices as containers is, today, probably the easiest method of doing that. I mean, there are the so—called serverless architectures, et cetera, but they’re much less mature than containers are at the moment. Not that containers are super mature, but they’re more mature.

    And the other aspect is the whole kind of hybrid cloud, cloud native movement where, you know, it took 10 years, but enterprises are adopting cloud services in a very big way, including industries that you would never dreamed of having on the cloud, on the public cloud, like pharmaceutical, health care, insurance, banking, federal, and so forth.

    So, all of these—and again, containers, because they’re portable, because they can run anywhere in the same way, they’re a really good way to realize this notion of hybrid cloud. For example, we at Aqua have a customer—who, unfortunately, I can’t name, but it’s a well-known company. And they are, for them, this is already a reality. They are deploying applications on both Amazon and Azure using the same framework, using the same security policies, and in a way that makes these clouds interchangeable for them, so they can run application A on Azure today and they can run the same application on Amazon tomorrow. So, that’s a real change that we see, and containers are a big part of that.

    So, all of these things together, I think, are what’s driving this adoption. And yet, you know, I think we have to distinguish between adoption and penetration or, you know, maybe some other word. But the fact is that today, if you look at the total workloads that enterprises are running, containers are a very, very small percentage of that. But, if you look at any new applications delivered over the next five years as well as looking at migrating legacy applications to the cloud, you’ll see this number growing exponentially over the next few years.

    So, yes, in terms of the number of enterprises now either looking at, working with, or already deploying containers, that number is growing very fast, and I think there’s probably hardly a large enterprise on the planet today that is not at least thinking about containers if not already using them. But at the same time, you know, it’s early days for them. Most of them—not all of them, but most of them, the vast majority are looking at the first few applications being deployed, and this is just the first drop of rain before the deluge. So, it’s gonna be a lot bigger.

    Shimel: Yep. Rani, a couple of comments, questions, follow ups. So, first of all—yes, DevOps, containers, they seem to go like peanut butter and chocolate. Again, so does microservices and containers, but to me, I—you know, when I was a kid, a teacher once taught us that all spaghetti is macaroni, but not all macaroni is spaghetti.

    Osnat: Sure.

    Shimel: So, it almost seems that, you know, wherever you see containers, you see microservices, but you don’t always see containers when you see microservices, right? In some regards, microservices can be even bigger, right? It has even more of a use footprint. Actually, on devopsy.kinsta.cloud, we’re launching a microservices channel which we hope will eventually grow into a standalone site, because I do think microservices is that big and has the potential to be that big.

    Osnat: Yeah, but microservices is not a technology; containers are. Microservices is an architecture, you know what I’m saying? There’s a difference.

    Shimel: Yeah, fair enough. Yep. But, you know, bringing it back—and, of course, loud usage and all of that. But, let’s turn for a moment and talk about the mission of securing containers and all of these architectures and platforms and so forth. That’s really what Aqua is, and when we talk about why they invested money, these investors, not just because the containers are so big, but because the mission of securing them is also big.

    Osnat: That’s true. So, yeah, I mean, when you look at—so, first of all, we’re not really, I mean, the fact that we’re a container security company might allude to the fact that we secure containers. That’s not exactly true. So, you know, we don’t look to secure a container or containers, we look to secure the workloads or applications that are running on containers.

    Shimel: Mm-hmm.

    Osnat: And that’s a difference. Because—and again, here, there are several trends that come into play. One is really that these things that I mentioned before, the DevOps trends, the microservices, architecture, and moving to the cloud, they also affect how you can and want to do security. You know, if we look at the cloud first—when you go to the cloud, a lot of the basics, you know, the bread and butter security that you use to invest in as an enterprise disappears. Why? Because these are services that are already taken care of or provided by the cloud service provider.

    So, you know, when you run your applications on Amazon, you don’t really have to worry about things like data center security, infrastructure security, network security to a degree, identity management to a degree. And so, a lot of these things are—you know, they’re basically taken care of for you. So, the focus shifts to the application layer, and that is one aspect.

    Another aspect, which is a really positive one for using containers, is the fact that, since you are now breaking up the application into a bunch of microservices, you can have much more visibility and control into what the application is doing. You know, if you look at an individual container or microservice, it’s much easier to understand the intended function of that container or service, and consequently, be able to understand what is considered good behavior, and be able to identify pretty easily what is bad behavior. And you do that at a very granular level.

    Additionally, if you look at the networking aspect, in a way, the networking has been brought into the application in a more visible way than before. Before, you could have things done within the application that maybe a malicious actor did within the application, and it’s all done internally, and it’s a black box. You don’t have visibility into it until it actually gets out.

    With microservices, you are able to see the interaction between the different components of the application, sometimes at a very fine grained level and, again, be able to identify any kind of weird or abnormal communication between, you know, parts of the application that are not supposed to be communicating that way. So, that’s another benefit. So, these things really allow us to have much more control and visibility over what the application is doing.

    The last piece is around DevOps, which is often nowadays coined as DevSecOps, which is the whole notion of shifting left security—i.e., bringing some of the control points not to the run time environment but to the developer environment. And why is that? Because containers are also immutable, right? So, if you’re using containers directly, you’re not supposed to see any change in one time environments. You’re not supposed to see patching, nobody is supposed to SSH into your host that’s running containers, it’s supposed to be entirely orchestrated and automated.

    And so, anything that happens there is by definition not good. But, at the same time, you have the opportunity to make the application more secure from the start, which is in the development phase, and that includes things like, you know, removing vulnerabilities, ensuring the configuration is correct, enforcing best practices. And if you can automate that—which we do—then you’re winning, right? Because you’re delivering a much more secure application to start with, you’re gonna have a smaller attack surface, and then in run time, all you need to do is make sure that there is no drift or no unexpected changes to the run time environment, which would be considered malicious or at least suspect.

    Shimel: Got it. So, Rani, we’re running a little low on time. We’re actually out of time, but let’s keep talking. [Laughter]

    Osnat: [Laughter]

    Shimel: So, now, we’ve got—what are you gonna do, how are you using the 25 million? What’s the plan?

    Osnat: Right, so you know, in our short life of two years, we managed to launch the product very early and get quite a few enterprise customers, many of them Fortune 100 customers across many industries, and that sort of traction is what really made Lightspeed and the other investors invest in us, and we need to continue this. The market is growing, right? As we mentioned, adoption is growing at an accelerated pace, so we need to be there.

    That means, you know, investing in the quality as well as the breadth and depth of our solution. There is—containers are not a singular technology. I mean, there’s a lot of variation in the stack, not just in orchestrators and OS’s, but in the container engines themselves, and this will become even more so over the next few months as things like, you know, additional run time engines are introduced, and not just the Docker open source run time engine.

    And so, this requires investing in the right technologies and making sure that we can fulfill the requirements of our customers and, additionally, of course, we need to expand our presence, both in the U.S. as well as in other parts of the world.

    Shimel: Let me talk to you about that a sec, Rani. So, I’m gonna assume U.S. probably represents at least 50 percent of your market, is that about right?

    Osnat: That’s correct, yeah. [Cross talk]

    Shimel: And probably Ameya the lion’s share of the rest.

    Osnat: At the moment, yes, but Asia is also growing, you know, there’s—

    Shimel: I also wanted to ask—what about AP?

    Osnat: Yeah, so Asia Pacific is growing as well. There are a lot of container users in places like Australia, China, Japan, and so forth. And so, this is—these are obviously big economies, there are big companies there. They’re as advanced in terms of cloud adoption as the U.S. in some cases. So, we need to be there.

    Shimel: Absolutely. Well, how do you—so, I was actually out at RSA APJ this summer, and it was in Singapore. And, you know, I had a chance—I actually put on a DevSecOps event there with RSA. So, I had a chance to talk to many of the RSA attendees, some of the vendors and stuff.

    I mean, what’s interesting there is, your infrastructure, you know, even in Europe, AWS is an 8,000-pound gorilla, right?

    Osnat: Correct.

    Shimel: Where do you—we don’t see that in Asia Pac. AWS is still a player, obviously, but there are other solutions there.

    Osnat: Mm-hmm. Yeah, that—

    Shimel: Go ahead. How does that affect you guys, or how do you deal with it?

    Osnat: Well, it affects us partially because mostly, you know, we’re pretty much cloud agnostic, right? We run on all the major clouds. It’s not a major effort for us to run on additional clouds. You know, even today, we support Amazon and Azure, Google, IBM Bluemix. And so, it’s relatively easy for us to support additional clouds, and it’s not a—that’s not the stumbling block, in most cases, right? It’s more like things like esoteric OS’s or weird configurations that we encounter sometimes. But, in most cases, that would not be an issue. Not to mention that a lot of companies are also running private clouds, using VMware or other types of virtualization infrastructure. So, that is really not a stumbling block for us, at all.

    Shimel: Good, good. Interesting. Rani, as I said before, we’re way over time, I need to wrap this up. But, first of all, congratulations on the raise. I’m sure Aqua has 25,000,000 good uses for this money as well, and we’ll see more coming down the pipeline in terms of both functionality products as well as reach around the world. You know, always good to have you on, you have a great handle on where the container market is and of course where the container security market is.

    So, thanks for being our guest today. We’ll have you on again soon.

    Osnat: Thank you.

    Shimel: Thank you. This is Alan Shimel for DevOps and Security Boulevard Chats. Thanks for listening. We’ll hope to see you soon on another chat. Bye bye, everyone.

    — Alan Shimel

  • Puppet CEO Sanjay Mirchandani Reflects on a Year at Puppet

    Puppet CEO Sanjay Mirchandani Reflects on a Year at Puppet

    As Mike Vizard detailed, this year’s Puppet Conference featured an impressive lineup of new products and services brought to market. The company appears to be firing on all Puppet CEOcylinders. The event also marked the first anniversary of Sanjay Mirchandani as Puppet CEO. I had a chance to sit down with him to review the past year, as well as the announcements at the conference.

    I will leave the product stuff to Mike’s article, but I asked Sanjay what he thought was his greatest accomplishment over the last year. He said that hands down it was assembling the great team he has put together. To be frank, I agree with him. In a time when execs at tech companies seem to hop around like fleas, Sanjay has assembled a world-class, enterprise-proven leadership team.

    In my opinion, this builds on Puppet’s greatest strength, which is its community. Puppet, like many successful DevOps companies, builds on its free, open-source roots and is nourished by a passionate, involved worldwide community. This was once again in full view at Puppet Conference. Frankly, my favorite time of the day was lunch (no surprise there, but not for the obvious reasons), where I would get a chance to sit down with “strangers” and listen to their experiences, what challenges they face at their jobs and where they see things going. I love those opportunities for unfiltered dialogue with real practitioners. The feedback I heard was pretty consistent.

    They enjoy using Puppet and they appreciate what the company is doing. They noted was that even though the company is developing products that compete with other tools they are using currently, they like the fact that Puppet doesn’t force them to make an either/or decision. They can continue using the tools they are comfortable with or start adopting Puppet’s new tools, all the while using Puppet for what they have always used it for.

    I asked Sanjay another key question: “What is your biggest failure or disappointment this year?” The answer was surprising. He said he failed to understand that some people really were not clear whether they could use Puppet in a cloud environment. Mind you, this is during a conference in which several relationships with cloud providers were announced. But evidently, some people did not understand that it works in cloud environments as well as on-premises—and, for that matter, in a hybrid environment as well.

    Mirchandani is not underestimating this view any longer. Puppet is emphasizing its cloud chops at every turn. As I mentioned, I was not aware of this view either, so it is interesting.

    In any event, this year’s Puppet Conference was the biggest (about 1,200 people) and best yet. I thought the company did a great job trumpeting a number of new products, ideas, partnerships and a clear path forward. As one of the founding and leading DevOps tools providers, its future continues to look bright.

    — Alan Shimel