devopsy.kinsta.cloud

Category: Features

  • DOES 2018: DevOps Providing Greater Business Outcomes, Yet Challenges Remain

    DOES 2018: DevOps Providing Greater Business Outcomes, Yet Challenges Remain

    The DevOps Enterprise Summit turned 4 years old this year, and what a difference four years makes: At the inaugural summit, perhaps a few hundred attendees participated. This year, there were roughly 2,000, according to the organizers.

    The energy at the first year’s event felt like that of a skunkworks team that knew they were on to a great new way—they only had to sell the rest of the world on their radical ideas. This year, it became clear that the battle of ideas is over: The DevOps evangelists have won, and DevOps is here to stay.

    According to a DBmaestro study, more than 80 percent of organizations have adopted DevOps to some degree, but only 30 percent have done so across their entire organization. That study shows the popularity of DevOps, but also that there’s much more work to be done.

    That state of work was reflected at this year’s DevOps Enterprise Summit. This year the focus was on improving the pipelines that have been built, pushing the limits of DevOps even further and learning how to cope with the limitations of legacy business-technology systems that refuse yet to be retired.

    Greater Focus on Business Outcomes

    It seems DevOps has arrived. As Scott Prugh, chief architect and VP software development at CSG, said during his DevOps Enterprise Summit talk, “Product Management Meets DevOps,” it’s about business leaders from across the organization coming together to deliver better outcomes.

    That’s an aspect of DevOps that stood out boldly this year. DevOps practices in the enterprise are starting to move beyond the common cloud-native toolsets and are being applied to other areas in the organization, from the cloud back to mainframe and many systems in between.

    This unleashing of systems detached from the typical DevOps workflows turned out to be a central theme of the summit. For instance, Eric Robertson, VP product marketing management at CollabNet, explained how customers are exposing services on their mainframes and enterprise resource planning systems. As a result, customers are better able to deliver capability and value without having to re-create and re-release services.

    “It’s about knocking down the silos and optimizing functionality around business value,” said Sam Fell, VP of marketing at Electric Cloud. Those who aren’t doing it right, he said, are those who are not aligned well enough to provide the best business outcomes, the right user experience or the most optimal architecture, security and performance necessary to succeed in creating those user experiences.

    “You need to take a multidimensional approach and put the right people in the room early enough so that the right focus is maintained on outcomes,” said Anders Wallgren, CTO at Electric Cloud, during the DevOps Enterprise Summit.

    Both Fell and Wallgren agreed that more organizations have embraced the kind of architectures necessary to support the agility necessary to succeed. This includes container architectures that can be changed rapidly and safely so that in the event errors are introduced, systems can be remediated quickly.

    Challenges Remain

    In his talk, “DevOps for the Enterprise: 2018 Trends and Insights,” Wesley Pullen, chief strategy officer at Electric Cloud, detailed how enterprises are working to manage IT complexity. According to findings he shared from 451 Research, enterprises are taking a hybrid approach to cloud and container adoption, with 81 percent of organizations adopting a multi-cloud strategy, 58 percent adopting containers and 48 percent traditional on-premises systems. “What we have today are multiple teams working on independent and interdependent systems and target platforms with overlapping tools, platforms and release cadences. Managing all of this effectively is a challenge,” he said.

    One area where these challenges show themselves is with security. According to the “Sonatype2018 State of Software Supply Chain” study, since the Equifax data breach in 2017, there has been a 55 percent increase in open source breaches and 1 million downloads of vulnerable open source libraries. Fortunately, more organizations are embracing DevSecOps and making sure security processes are integrated into their DevOps processes, Pullen said.

    When it comes to extracting value from their existing enterprise systems, Pullen noted more organizations are making self-service catalogs available to their teams so that if a service is needed and it’s already been built, teams can access these resources quickly.

    Finally, he said more organizations are applying artificial intelligence and machine learning to their development pipelines. About one-third of organizations are making machine learning a top investment priority. They are using the technology to identify patterns using in-depth statistical analysis, predict future risk using previous patterns and provide recommendations to reduce risk, he said.

    While DevOps has outgrown its skunkworks roots, this year’s DevOps Enterprise Summit made it clear there is still much more work to be done before most DevOps organizations reach their full potential.

    — George V. Hulme

  • Predict 2019: Forecasting the Future at a Virtual Summit

    Predict 2019: Forecasting the Future at a Virtual Summit

    That time of year is drawing close: Sometime right after Halloween, heading into Thanksgiving, our thoughts turn to the holiday season. A new year is on the horizon. What will it bring? In the tech media world, we are swamped with folks who want to share predictions and thoughts on the new year and beyond. This year, we are wrapping all of these up into one great virtual summit called Predict 2019.

    Similar to the environment we created for the DevOps Experience, Predict 2019 will feature a virtual environment with a conference lobby, presentation theater, expo hall and more. More than a series of YouTube live presentations, it is truly a conference experience from the comfort of your desk.

    Predict2019Speakers

    The content at Predict will be first and foremost. To that end, we are lining up some great speakers. I am happy to announce that celebrated DevOps author and practitioner Mirco Herring will be keynoting the DevOps tracks. Securosis and DisruptOps co-founder Rich Mogull will be keynoting the DevSecOps tracks. Our third keynote on containers, security and DevOps is Batchagalupe himself, John Willis.

    Predict 2019 Keynote

    John Willis, Rich Mogull and Mirco Herring

    We have added another keynote speaker in addition to the three above to Predict 2019.  We are really proud to announce that Chenxi Wang will be presenting her predictions for 2019. For those of you not familiar, Chenxi is the founder of Rain Capital and a former VP at Forrester. She also held executive positions at Intel Security, Twistlock and Cyphercloud, and is a professor at Carnegie Mellon University, as well as one of the most influential women in cybersecurity. Her keynote should not be missed.

    Chenxi Wang Predict 2019

    Chenxi Wang

    In addition to the keynotes, a CEO panel discussion on AIOps will be moderated by me. Plus, we’ll have several other panels on key topics for 2019 and individual presentations. All told there will be 15 sessions at Predict 2019.

    There will also be an exhibit hall where you can interact with other attendees and sponsors, watch videos and download more information. Just about everything you can do at a conference in the physical world, you will be be able to experience at Predict 2019—but without the airfare and hotel bill.

    It should be a great day of learning and networking right from the comfort of your own chair.

    Registration and Sponsor Info

    You can register now at https://predict2019.com. Attendance is free.

    If you are a interested in speaking or sponsoring Predict 2019, there are a limited amount of sponsorships available. Sponsor info can be obtained at sponsor@devops.com. Additionally, speakers can write us at predictspeakers@devops.com

    If you are curious about what the experts, pundits and luminaries think will be the big trends and stories of the coming year, mark your calendar and attend Predict 2019.

    — Alan Shimel

  • Security Through ‘Legisurity’: Impacts of SB-327

    Security Through ‘Legisurity’: Impacts of SB-327

    With more devices connecting to the internet every day, security through obscurity should have died a long time ago. Still, high-profile cases of devices with mass-produced default login credentials and easily cracked crypto keys persist. As a result, say hello to security through “legisurity”: California SB-327—“Information privacy: connected devices”—became law Sept. 28. How will this impact DevOps teams?

    What SB-327 Does and Doesn’t Do

    Here’s a quick look at what SB-327 does, starting with its timing and scope. The provisions go into effect Jan. 1, 2020, giving teams a little more than a year to prepare compliant connected device designs. The legislation defines a connected device as one “… capable of connecting to the Internet, directly or indirectly, and that is assigned an Internet Protocol address or Bluetooth address.” Authentication is “… a method of verifying authority of a user, process, or device to access resources in an information system.”

    The operative passage in SB-327 calls for a “reasonable security feature … appropriate to the nature and function of the device.” (Before you get too excited, it explicitly shuts the door for individuals suing manufacturers over non-compliance.) With implementation left open, the legal standard is very clear. Reasonableness is a device with features meeting either of two requirements:

    “(1) The preprogrammed password is unique to each device manufactured,

    “(2) The device contains a security feature that requires a user to generate a new means of authentication before access is granted to the device for the first time.”

    Also written into SB-327 is a list of things it does not do. The law does not extend these requirements to third-party software a user installs, and it does not force retailers or software providers to review compliance of a device. It doesn’t apply to devices sold only to federal agencies or the military, and it yields to HIPAA requirements. It does not permit manufacturers to hinder law enforcement agency access to a device with these required features.

    What Should DevOps Do Now?

    As with most first attempts at legislation, the unwritten implications of SB-327 may be even more interesting. Here are a few things I see changing for DevOps teams securing devices and infrastructure:

    • SB-327 only applies to devices sold or offered for sale in California. However, setting up California-only design efforts, supply chains and customer support would be costly. (For $20,000 cars? Sure. For $200 devices? Not so much.) Practically, I see these becoming de facto requirements nationwide by the 2020 rollout. Companies should start now to be ready.
    • If you’re a device manufacturer, you should add both requirements into your minimum viable product baseline, if you haven’t already. You’ll obviously need a strategy for assigning and tracking default passwords and a crypto key authentication method for setup connection. Customer support procedures and documentation also need to change. Consider using one-time programmable non-volatile memory or PUFs (physically unclonable functions) to establish a unique device identity.
    • On the deployment side, you’ll need added tracking for unique default passwords in your device provisioning database. Your customer support teams will need device-specific information at their fingertips to get new or factory-reset devices back online quickly. Crypto key authentication methods will be a more important criterion for device evaluation and selection.
    • If you don’t have a good UX person and an experienced pen tester on your team, hire or contract those roles right now. Simplicity with security is always going to be the right answer.

    More Laws Ahead?

    Will the debut of “legisurity” satisfy lawmakers and stem connected device breaches? My guess is this is only the beginning; SB-327 does nothing about requiring stronger passwords or thwarting more sophisticated protocol-based cyberattacks. The main point of SB-327 doesn’t seem about securing a single device, although it should help; rather, it’s trying to prevent rapid compromise of an entire population of that device. (Pro tip: whatever you do, don’t use a device’s MAC address in a simplistic algorithm, or you’ll end up like this sad, not-so-smart lock story. Cracking one device cracked them all.)

    For the more curious, here’s the entire text of SB-327, and some other analysis on legislative proposals at the federal level. What are your thoughts on SB-327, how you see it affecting DevOps, and if legislation is the right path for securing connected devices?

    — Don Dingee

  • Unlocking the Power of AIOps

    Unlocking the Power of AIOps

    AIOps is becoming quite the hot topic lately. It seems as though everyone is realizing that Ops is difficult. As we have to deal with more big data at greater velocity with more automation and complexity, there is no way humans alone can tame the beast. AIOps seems to be the answer.

    I recently sat down with Dave Link, CEO and founder of ScienceLogic to discuss how to unlock the power of AIOps to empower IT ops. We video taped the conversation, along with some accompanying slides that help explain what the challenges are that ops faces and what are some of the ways to tackle this using AIOps.

    I should mention that Dave and I are old friends, having worked together 20-plus years ago at a dotcom era company called Interliant. Since 2003 or so I have watched Dave build ScienceLogic into the powerhouse it is today. I couldn’t be more happy and proud of him.

    ScienceLogic has been named by EMA as a top vendor in the AI/ML for IT Operations. Dave gives us a good background on ScienceLogic as well as a good background on the use cases and challenges that IT Ops faces that AIOps seems to be the answer for.

    Dave also talks about the differences between AI and machine learning or ML. This seems to be an area of confusion today as well.

    The video is about 30 minutes and excuse Dave and I reminiscing, but there is some really great information here.

    Video on AIOps

     

    — Alan Shimel

  • DevOps Chat: CHAOSSEARCH New Spin on Big Data Analysis

    DevOps Chat: CHAOSSEARCH New Spin on Big Data Analysis

    Analysis is the dark cloud overhanging big data — it’s difficult without the right tools. Elasticsearch by Elastic has become ubiquitous in helping organizations, but it can get unwieldy, as storage combining with compute is tricky. CHAOSSEARCH is an early stage startup designed to  make searching massive amounts of data using elasticsearch and Amazon S3 easy.

    Pete Cheslock, VP of Products at CHAOSSEARCH and a good friend of devopsy.kinsta.cloud, joined me in this DevOps Chat to discuss his latest company’s technology and how it might make big data searches less daunting. The key for big data search and analysis is separating storage from compute, using Amazon S3 and Elasticsearch.

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

    Audio

    Transcript

    Alan Shimel: Hey everyone, it’s Alan Shimel, devopsy.kinsta.cloud, and you’re listening to another DevOps Chat. Today’s DevOps Chat features a returning guest to DevOps Chat. He’s actually probably been on DevOps Chat a number of times, right from I think the very beginning of when we first launched devopsy.kinsta.cloud. He’s pretty well-known in the DevOp community and really needs no introduction from me. It’s Mr. Pete Cheslock. Pete, welcome to DevOps Chat.

    Pete Cheslock: Hey, thanks a lot. Thanks for having me.

    Shimel: Yep. Pete, always a pleasure to have you, man. You know, I remember speaking with you – actually it was probably before I even launched devopsy.kinsta.cloud, up in Boston. And you kind of gave me your views on what was then a very kind of just starting to blossom DevOps community and DevOps movement. And since that time obviously a lot of water under the bridge and many different hats that you’ve worn, Pete. Here to introduce today though with your latest position in helping a company grow, and that company is called CHAOSSEARCH, correct?

    Cheslock: Yeah, that’s correct.   

    Shimel: And Pete, you’re VP of Products?

    Cheslock: Yeah, yeah, VP Products, Products, VP of Products? I don’t know, it’s a working title. We’re still trying to figure out what the best way to –

    Shimel: As long as they don’t call you a DevOps engineer, it’s all good. [Laughs]

    Cheslock: Exactly.

    Shimel: I hear ya. So Pete, well let’s start off with this. I’m going to assume a lot of people listening to this today don’t really know or are not familiar with CHAOSSEARCH, so why don’t we start with that? What’s CHAOSSEARCH?

    Cheslock: Yeah, absolutely. And yeah, I think that’s definitely a good assumption. You know, we’re an early-stage startup. We’re just going through seed funding right now, so we’re just going through an A round of fundraising, so then we’re going to be coming out to the market in a few months here. But basically what CHAOSSEARCH is is they’re trying to make it easier to access and make query-able your data as it exists on object stores. So if you think of an object store like Amazon’s S3 service. And so they developed basically a technology that allows you to store data. They basically process your data from S3 and store it back into your bucket. So what’s really interesting is they don’t hold any of your date. They’re simply – you know, you give them like a read-only to your S3 data. They’ll read in that data and shove the compressed, processed data back into your bucket. And then from there they expose APIs to allow you to access it.

    So for example, they’ll extend the S3 API to give you some really interesting capabilities of slicing and dicing your data. But the thing that they’ve exposed that’s most interesting, which got me excited about the company, is that they’ve exposed the elasticsearch APIs on top of your data on S3. And so it’s really compelling, because I spent a very long time as a really early user of elasticsearch, and it’s a great technology; it’s a great open source database. But it gets unwieldy over time. And so what really blew me away when I saw the product and what they’d built is that I can point open source log tools like Kibana to the CHAOSSEARCH APIs, accessing my own data on S3. No elasticsearch required. And so the kind of short pitch, we’re trying to make that long tail of data available to people, whether it’s log data or event data of some kind, where customers can run much smaller elasticsearch clusters of their log data or event data, and then they can essentially push the data up to S3. We’ll process it, and now they can get access to that data for weeks, months or even years.

    Shimel: Yeah. And Pete, that really highlights sort of a soft-white underbelly or a dark corner around the whole big data issue. It’s great to have – I mean, big data and – big data is only as good as the analysis we can do with it, right? That we can perform on it. And with big data we could certainly get some really keen insights to show us relationships, trends, facts that we might otherwise miss. But the dirty little secret was, for big data, to really get the value out of it, generally you needed big money kind of search to perform that kind of analysis. Because the bigger your data got, the harder it was to actually manage it, search it, analyze it. And so CHAOSSEARCH seems like a real solution for those people who are literally drowning in data.

    Cheslock: You’re exactly right. I worked at a company eight or nine years ago called Sonian, which – not a lot of people have heard of Sonian. They were one of the earliest users of Amazon’s S3 and EBS. At the time we were probably the top-three user of S3 and maybe the top-five user of EBS. What’s amazing about Sonian is the number of companies that actually came out of that place. Companies like CloudHealth, which just got acquired by VMware. Sensu was a technology that was built inside of there. Stackdriver was another one. And the reason all these startups came out of Sonian is because they were so early in the cloud space, they had to build out the technology to support it.

    One of the other ones that kind of came out on the side, not really related to us, was elasticsearch. We were trying to index customer e-mail data, like an e-mail archiving product. And so we got connected with Shay from elasticsearch before he really started the company because we were so blown away by what he had built. And elasticsearch at the time made sense, right? Using Lucene to store indexes of customer e-mail data allowed the indexes to be much smaller than the sourced e-mail files. But then over time, over the last say eight years or so, elastic’s been around, there’s been this explosion of using elasticsearch for log data. And in many cases, like structured JSON that we’re shoving into elasticsearch. And due to the inverted index nature of Lucene, the data blow up inside of Lucene where you might actually store four or five times more in disc storage on elasticsearch.

    So if you shove in a terabyte of JSON logs into your elasticsearch cluster, that could be three or four terabytes of Lucene indexes. And then you have to think about like, “Well, I want durability and reliability, so now I need to like run a replicant index.” So now you’re talking for every terabyte into elasticsearch you need like eight terabytes of physical disk. What was really amazing about what the founders and the early team here has created is the format, kind of solving for the Lucene problem. They’ve actually been able to reduce the size, yet still making the data query-able, using kind of the same APIs, which is what really blew me away, in that it’s now – you know, so many people have to make the choice. Do I keep my data for analysis, at a really high price of elasticsearch? Or, do I throw it away? And I think a lot of people just throw that data away, because they just can’t make it worthwhile in any sort of cost effective way. 

    Shimel: Right, not in an economic way. Pete, we’re far from a big data solution here at MediaOps, between our seven or eight websites, but I will tell you, just pure search, like an index search on devopsy.kinsta.cloud has become a struggle. Because a lot of the native WordPress search – you know, especially if it’s on server, is killing resources on your web server and so forth. So you want to do it sort of off-server search and it’s just a pain in the butt. Take my word for it. So this is great. You said the company’s launching in a few months though? Not that it’s launching – it’s looking for seed money now. Product will be in market. Where exactly is it now in terms of – is it in beta? Is it alpha?

    Cheslock: So yeah, we’re probably going to be closing our A fundraising round over the next 30 days or something like that. The company actually started about two and a half years ago, and so they’ve been essentially building this technology out over the past couple of years and really trying to refine it as they were kind of were coming up with this like product market fit. Like what’s the market we’re going into? And as the founders really looked at the space, they realized that log and event management is where a lot of pain is right now. What’s interesting is when people start using the product, they realize that they can process any kind of data with this and query it. And that’s where there’s a lot of interest, where maybe it’s not just log and event data. Maybe it’s like some long tail of data that you want to get access to or to monetize for your customers.

    But where we’re at right now, and what was exciting about me coming onboard is not only did my role change completely – I used to run Technical Operations for Threat Stack, which is a pretty successful cloud security company that’s still just crushing it. I changed my role over to become the Head of Product. So working with customers to understand their use cases and how they’re using tools like elasticsearch. So where we’re at right now is I’m basically looking for what we’re calling design partners, where – the best way to describe the product is in that beta phase, where we’re looking for people with really interesting datasets and maybe people who are on Amazon and have data on S3 or are using elasticsearch, and getting them into our proof of concept setup right now, where we can have them run queries, test the analysis, test how they might use it and really help us refine the final bits as we kind of _____ things up towards GA.

    And then, once we go to GA, towards – I would say October timeframe I think is what we’re aiming for, it’s really to continue to refine these really specific use cases like, “I’ve got data on S3 and I want to process this data.” We’ve had some customers that want to push their elasticsearch indices up through the service, which is a really interesting idea, because those loosing indexes already have a defined schema. And so that way, instead of storing seven days of data in elasticsearch, maybe they just store one day and that’s in their hot cluster in elasticsearch on EC2 or something. And then days two through 365 are up on S3 and are available through the CHAOSSEARCH service. So yeah, that’s kind of what the next month or two looks like for me. You know, really trying to work with customers, people with interesting datasets. You know, people who have just way too much elasticsearch and they want less of it. You know, they want to kind of run less servers, spend less money – which I feel like is kind of everyone out there right now.

    Shimel: Excellent. Very cool stuff. I mean, Pete, look, for you to get up and leave Threat Stack and come over here, obviously it had to be something really appealing and compelling, to bring you over there. Pete, it’s interesting. My background prior to devopsy.kinsta.cloud was founding and building companies, and one of the things I learned is it’s great to have these grand – come up with the idea of Docker for containers and change the way – you know, the basic platform that we use, right? For our apps and for IT. But those revolutionary kinds of things are really kind of few and far between, especially the ones that succeed. Really IT moves along in evolutionary kind of ways, where it’s a thing like this. It’s thing like with CHAOSSEARCH is doing, that makes it easier, better, faster, more economical to really get a hold of your big data and do the analysis and get a handle on it that you need to make it valuable. Right?

    Cheslock: Yeah. Exactly right.

    Shimel: And so, you know, this just feels that way to me – that this is a lot – some people may say, “Well, it’s not earthshattering.” But no, but it’s the logical step. It’s the glue that you need to – you know, big data is a big concept and it’s great and it’s going to revolutionize things when we get it. But you need the CHAOSSEARCH or sort of the glue to make these things happen, right?

    Cheslock: Yeah, what’s amazing is, as I’ve talked to people running a lot of elasticsearch, a lot of data on S3, it’s a really easy sell, because I can go to them and get them away from running these huge clusters that – they may not even take a lot of queries too. That’s what’s interesting is maybe they’re only querying their data in an automated way the last hour or 24 hours. But then you start looking out seven days, a few weeks, maybe a few months; those queries are significantly less. And so you have to either build out like a tiered storage. But at the end of the day the storage and computer are coupled so tightly that your scalable units on Amazon or any cloud provider is a lot of disk and a lot of CPA all together. And what CHAOSSEARCH has done, it uncoupled storage and compute, where the storage is on S3, specifically your S3 account, and the compute is the CHAOSSEARCH service.

    And so it’s a totally different way of thinking about, “How do I access my data? How do I make it query-able?” And now, because it costs so little – and we’re talking like go-to-market pricing a tenth of the price of running elasticsearch yourselves, and significantly less than a lot of the other kind of hosted management, log manager vendors. You know, it’s like now I can keep my data for month and a year and I can run machine learning models cost-effectively, because I can keep so much data. That’s the part that’s super interesting, is, how does this change data science and those companies that really want to have the long tail of data for ML/AI testing, and how does this change how they work their models, how they build it in? And we’re even trying to build in like tenser-flow integration into the application so that you can just access it from within without needing to have all this crazy data science experience.

    Shimel: Excellent. It really is. Pete, you know, 15 minutes goes quick. We’re coming up on our thing here. You’re VP of Product. Where do you see this going six months, a year, two years out? It’s a long way to look, but where do you see yourself taking the product direction here?

    Cheslock: Yeah, no, I always like to joke that the next six months are clear and in focus. Things get really fuzzy really quick after that. But the nice thing is I think we have a pretty clear plan going out of it. Through the end of the year, reaching GA, bringing some customers onboard that we can solve a problem for them. But really, early next year we’re going to start beta-ing a self-service kind of model, where people can come in and try it out. And probably doing even a freemium model, because since the data is in your S3 bucket and we’re just processing that data, cost is very low. So being able to provide someone a couple of gigs a day of data processing, it’s pretty easy for us. And then that way people can kind of get their feet wet and try it out and we can really start building a community around it.

    And then from there, I think the sky’s the limit. You know, we’re looking at some time end of next year, the ability to run it within your own data centers. Right now we want to be kind of pure SaaS so that we can continue and build it out and improve it in our kind of very quick, iterative development cycle. But really it’s a data platform we’re building. I mean, we’re going after that log and event management space because it’s so painful for so many people and it costs a lot of money. But the long-term for us is, what other APIs could we expose on top of your data on S3? Elasticsearch seemed to make a lot of sense, given the market. We’ve extended S3 with some interesting features. But like what else is there? What are different ways people are trying to access different data? And so I think that will be a lot of fun to kind of chat with people, understand their pain and maybe actually bring them a nice solution to that pain.

    Shimel: Yeah, absolutely. And I’m sure you’ll have a ball doing it, Pete. Anyway, we’re over time here. Pete Cheslock, newly minted VP Products, CHAOSSEARCH. Thanks for joining us on this episode of DevOps Chat, and we look forward to hearing more about CHAOSSEARCH and about your adventures, Pete.

    Cheslock: Yeah, thanks a lot. Thanks for having me. This was a lot of fun.

    Shimel: Always a pleasure. Pete Cheslock, CHAOSSEARCH. This is Alan Shimel for devopsy.kinsta.cloud. You’ve just listened to another DevOps Chat. 

    — Alan Shimel

  • DevOps and Containers: A Network Divided

    DevOps and Containers: A Network Divided

    The growth of DevOps and containers has created some interesting split responsibility scenarios. Not that this is necessarily a bad thing, but it is something that bears watching and fixing when it becomes problematic.

    Today’s topic is networking. Plenty of bits have been spewed about the situation, but it persists and is even getting more complex as architectures diversify.

    Specifically, today’s topic is about the dual responsibility built into today’s networking. Generally speaking, network operations staff are still managing the complex hardware and software environments that deliver packets to your systems. What they do and how they do it is changing—but at a much slower pace than areas fully pulled into DevOps. There are many reasons for this, and I won’t delve into them here, but the truth is that managing a production network and dealing with hardware vendors bring unique responsibilities and constraints that aren’t there in a software world.

    That’s experience talking, from a developer who learned network administration. Software is easier and more adaptable, and that is directly reflected in the impact of DevOps.

    But we have drifted into a world in which that infrastructure is still mission-critical and still has those same constraints, while the software layer of networking—driven primarily by containers—has grown up in parallel with a different set of people often responsible for it. And that software network can be mighty complex. I shudder to think about what the iptables look like on some—maybe hundreds—of your machines.

    Cloud has much the same effect, but since cloud instances often are publicly exposed, they tend to have networking people involved to make sure routing is correct and verifiable, and to help InfoSec people determine that the instance is as locked down as possible (and we can all name companies that wish this were true).

    Still, the complexity of cloud spawned companies including CloudCoreo (now a part of VMware), which automate a bunch of network verification and security checks just because there are so many points that require touching. So cloud isn’t the nirvana of shared responsibility either. Yet.

    As DevOps and container adoption has grown, it is natural that responsibility for container/container management networking would have spilled over into the development or application administration side. After all, once a subnet is configured for a cluster and software is managing the subnet, which is integrated with the rest of container management, it feels right to have the Dev/deploy team manage it.

    And it might be. Like all things DevOps, this is a continual improvement exercise. Having someone who knows exactly what is going on between pods/clusters/networks is important, though. Breaks can cause outages that cost money. Knowledge is the key to fixing breaks and container networking is generally super-complex. Even if you are providing standard IP addresses on a corporate subnet to each container, container management networking is still complex and can still break.

    So if you haven’t already, get the networking team involved in inter-/intracontainer communications. Make certain you know what is going where and what should go where.

    You won’t regret it, when things inevitably break that cannot be repaired by dropping the instance and spawning a new one to replace it.

    — Don Macvittie

  • DevOps Chat: disrupt:Ops Brings Security Closer to DevOps

    DevOps Chat: disrupt:Ops Brings Security Closer to DevOps

    Shifting security left during the software development process can be tough for companies because of the sheer number of operational things that go along with implementing security that must occur somehow in the realm of DevOps. It can be easy to lose control over their security processes without some sort of guardrails in place to help.

    A brand new company is helping do just that. I’m excited to introduce disrupt:Ops, which bills itself as a guardrails platform to help companies include and enforce best practices across security and operations, bringing security into the DevOps process at the beginning. My friend Mike Rothman, disrupt:Ops co-founder and president, joins me in this DevOps Chat to discuss the vision of his company and how it hopes to help make security truly a part of DevOps.

    You can read more about disrupt:Ops and their guardrail approach to cloud security and devsecops from another co-founder of the company, my friend Rich Mogull at https://devopsy.kinsta.cloud/building-great-cloud-security-guardrails

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

    Audio

    Transcript

    Alan Shimel: Hey everyone, it’s Alan Shimel, devopsy.kinsta.cloud, and you’re listening to another DevOps Chat. Breaking some big news today on DevOps Chat, the launch of a labor of love of some friends of mine. I’m happy to be joined by Mike Rothman, cofounder and president of disrupt:Ops. Mike, welcome.

    Mike Rothman: Alan, it’s great to be here, thanks. It’s always fun to catch up with old friends.

    Shimel: Yep, and old friends it is, Mike. We should let our audience know – maybe we shouldn’t let them know. But we are old friends. We go back a long time now, back to the beginning of blogging and security –

    Rothman: That’s right.

    Shimel: It’s got to be 2004, 2003 or something like that.

    Rothman: Yeah, that’s right, that’s right. When I had dark hair. Actually I didn’t have dark hair back then, but you know, it’s –

    Shimel: I had hair.

    Rothman: You had hair. That’s right.

    Shimel: I had hair. But you know what, Mike? I said it was a labor of love and everything else. Just in the way of background, why don’t you share with our audience your personal sort of journey in tech and, you know, work history.

    Rothman: Well sure. I started out, God, in what feels like 100 years ago, as a mainframe programmer. Ended up doing some local area networking stuff. Kind of found my way to network security. Went into research for quite a while. Did a couple of companies and then went back to research and for the last 10 or 11 years at this point I’ve been partnered up with Rich Mogull and Adrian Lane at Securosis, doing a bunch of kind of information, security-centric research. And actually about a year and a half ago we spun out some technology that we had prototyped within Securosis in cloud management and cloud automation into our new company disrupt:Ops, and have been just making a lot of progress over the last year with that. And that’s what we’re announcing this week.

    Shimel: Yep. So Mike, you’re being humble. When you say you did research, you were an analyst at Giga, were you not?

    Rothman: META Group, yes. META Group, exactly.

    Shimel: META Group. And then you were also – you had executive positions in several cyber – we didn’t call it cyber – infosec companies back then. 

    Rothman: It was. Yeah, you bet. So companies like TrueSecure and CypherTrust, you know, back early in the e-mail security days. I did a network monitoring company called EIQ. So yeah, I’ve been there, done that. Have the road rash and kind of the screw-ups under my belt to prove it. But you know, it’s interesting in terms of just how long and how small an industry security is for being actually a really big thing nowadays. 

    Shimel: Being so big, yeah. It really is. And Mike, again, for many people in our audience who come from DevOps or even from security – but they’re worldwide and they not be familiar with Securosis. You know, Rich Mogull comes over from Gartner. Adrian’s been CTO at major companies. You know, you guys are probably the leading, let’s call it independent security analyst research firm – you said 10 years-plus. Certainly in my time you guys laid the fundamental kind of – a lot of the fundamental backbone of what Cloud Security Alliance teaches and so forth. 

    Rothman: Yeah, that’s exactly right. So it was interesting. So I guess it was probably eight and a half years ago we partnered up with the Cloud Security Alliance and helped them build their curriculum for their CCSK certification. And that got us to be much deeper than your typical analyst in terms of having to play around with cloud, having to understand automation, having to build a number of the kind of scripts and – I’ll call it the inherent messiness of building out a stack in the cloud and really making it operational, because we were eating our own dog food. Our website, a lot of the stuff that we had prototyped was really demonstrative of the challenges that organizations face as they move a bunch of their stuff into the cloud, and really as they embrace a DevOps mindset of trying to be agile, trying to be innovative, trying to move towards more of a continuous type of deployment model. We really came across a number of the challenges these organizations have in terms of just really maintaining control, right? Once you have multiple DevOps teams doing things in multiple kind of accounts, you start to run into challenges relative to how you enforce best practices.

    And that’s really one of the challenges that security people have with this whole DevOps revolution, which is, “Hey, this sounds great, but we’ve got a playbook, a set of practices and policies that we really require all of our environments to adhere to in order to protect that data.” And obviously the faster you move, the more agile and continuous you try to operate, the harder it is to enforce those best practices.

    Shimel: More about that in a second. You touched on two things there that we’re going to dig into. Let me just finish laying my groundwork. Mike, besides you, Rich and Adrian, the Securosis gang, there are at least two other key people on the founding team of disrupt:Ops who also happen to be friends of ours for years –

    Rothman: Yeah, that’s right.

    Shimel: Give them their due. Why don’t you give them a shout out?

    Rothman: You bet. So back when we spun the technology out of Securosis, we brought on two guys, very experienced guys in the security space. Our CEO is Jody Brazil. So Jody was a cofounder and long-time CEO of a company called FireMon, which I know you’ve done work with for a long time –

    Shimel: Sure.

    Rothman: So Jody kind of is really the driving force behind a lot of what we’re doing at disrupt:Ops. And our CTO is a guy named Brandy Peterson, another longtime security professional. He was actually the CTO of FishNet Security for 15 or 16 years.

    Shimel: As was Jody before Brandy, right?

    Rothman: Yeah. I met both of them around the same time.

    Shimel: Yes, when I first met Jody, he was CTO and FishNet, and he said, “Who is this Jewish guy with the New York accent?” I went out to visit him in Kansas City to tell him why you shouldn’t use Qualys, and he should use StillSecure, and he made fun of my accent. [Laughs]. Good times. Anyway. But Mike, let’s turn back to a couple of things you were saying about kind of the genesis driving disrupt:Ops. You touched on one thing; you said, “multiple DevOps teams.” So this is something we see, and I call it almost second-generation DevOps. You know, when a company or an organization is first embarking on their DevOps journey and they do sort of a trail balloon, and they pick a project and they have a DevOps team – you know, and they may not call it DevOps. They  have a team that’s practicing DevOps sort of principles on this one particular project. And oftentimes, wow, great success, because you are – you know, it’s an isolated environment, right? In some ways you’re not in the quote/unquote real world.

    And then you say, “This is great. Let’s take it out. Let’s expand that beachhead. Let’s expand the bubble.” And all of a sudden – you know, larger organizations; small teams or smaller organizations not so much, but larger organizations – now you start having two, three, four, six different projects that are being run with a DevOps mindset and you have multiple instances of Jenkins and you have three different – this team’s using Puppet; that one’s using Chef. And serverless. And all of the complexities that we see in today’s modern software factory. And it’s chaos, right? And then at some point the CIO or VP or director of IT says, “Oh my God, this DevOps thing isn’t working so good. It’s all over the place.” Let alone the security guy’s screaming, you know, right out of the Phoenix Project, “No, no, no!”

    Rothman: That’s right.

    Shimel: And that’s a problem that we see with a lot of second-gen, if you will, DevOps installs, where it goes beyond the initial team to several teams.

    Rothman: That’s right.

    Shimel: That’s what you guys see.

    Rothman: We do. And it’s interesting, because what you have are really kind of two paths at that point, in terms of how these teams start to behave when starting to be put under scrutiny in terms of, kind of again, their ability to enforce operational and security best practices. You know, one group kind of buries their head in the sand and continues to move forward and really don’t do much, right? They’re like, “Oh, it’s okay,” and you know, they’ll maybe run a vulnerability scan to kind of prove that they’re sort of within policy, but they really don’t have an operational environment that is built to work in concert with the rest of their factory. I love that term, right? That really does encompass a lot of how software is being built today. And then the other part ends up being folks starting to build their own scripts, right? They take maybe an open source-looking thing, they start to build a bunch of their own scripts and code around it, and then what they find is they’ve got a suitcase full of these scripts that they end up having to maintain, upgrade. They don’t have any means of reporting or any scheduling for how they enforce and run a lot of these scripts.

    It’s really – you know, we call it automation, but it’s manual automation, which I get is a total oxymoron. But that’s really how it is. You know, you have a bunch of folks, they’re building these scripts out, they’re executing them manually or through very simple triggers, without any means of maintaining, upgrading or scheduling or reporting on what these really key aspects of their operational environment are doing. And it becomes, again, a big problem, where you have – it’s unwieldy because of just the sheer number of things that are happening in a modern DevOps environment with multiple teams. Then you compound it with a number of very tactical scripts that are built to surround the environment, if you’re doing anything. And then at some point somebody says, “Hold on a sec, folks. This is just not where we want to be. We really need to think about it more from an operational excellence perspective and make sure we’ve got an environment that we can enforce our best practices for security and operations.”

    And that’s kind of when they get the sense that, “Well, I’m either going to have to make a significant investment in this and become like” – Rich calls them the unicorns of cloud land, right? You know, the Netflix and the Capital One and, you know, the folks who have whole teams of environments that are building tools to do this. Or they have to start looking for some kind of commercial option, because there really is no option, but you’ve got to do something. You can build it yourself or you can look to buy it. And candidly, until the last handful of months, there really wasn’t a realistic commercial offering to start implementing some of these capabilities.

    Shimel: No, no. I think the bigger – you know, a lot of what you’re saying certainly obviously rings true. The other fundamental piece of this is, even if you are using one of these homegrown, cockamamie, you know Rube Goldberg kind of things –

    Rothman: Yeah.

    Shimel: – is it the security guys who are? You know what? Shame on me. It’s not the guys. Is it the security team who’s doing this, people? Is it the DevOps cross-functional team? Is it a little bit of both?

    Rothman: Yeah, yeah.

    Shimel: You know, how many of – look, here’s my basic, fundamental belief. You are not going to find a developer who raises his hand who says, “I want to write shitty code. I can’t wait to put something insecure out there.” No one says that. No one says that, right? They’ll tell you they’ve got time pressure, there’s pressure to release, pressure to release, they wish they could do more on security. And some of them, the enlightened ones, as you said, they’ll even try. They’ll run a vulnerability scan, because there are certainly open source kind of tools out there for them to mess with.

    The problem is, they go to a lot of the security guys, and as you alluded to before, security guys say, “Well we have our rules and procedures here. This is a no.” Right? And they don’t want to hear no. They’ve got to go.

    Rothman: You know, what’s interesting, Alan – I want to hit on a couple things that you alluded to there, because they’re important, right? The first is kind of where you start to see the agitation for better operational and security practices. And it’s not that it’s not the security folks. Obviously they’re always going to push for that. But it really is – you mentioned it, right? The DevOps teams that we’ve worked with, they’re very cognizant, they’re very serious stewards of kind of the corporate data, and they want to do the right thing. But in a lot of cases they don’t know what to do, right? So you have a whole bunch of folks who don’t know what they don’t know and they don’t want to go to the internal security team because of a lot of those things you were just alluding to. They’d say, “No, we can’t do that. We have all of these rules.” And in a lot of cases the security team has not updated their set of conditions, their set of policies – 

    Shimel: Exactly.

    Rothman: – to work in a DevOps type of environment, so these folks really struggle. They talk to – again, on the consulting side of our house at disrupt:Ops, we do a lot of work with those teams in terms of helping them understand what cloud native architecture looks like and how to integrate cloud security into their environment, and really just to help them build a program in order to do that. So then you do that with one DevOps team, then you end up talking to another DevOps team and maybe the third DevOps team, and finally IT, at some point, they’re like, “Um, what are you telling our folks? They seem to like what you’re doing and they seem to be doing things in a more secure way. So can you help us?” And then IT starts to get religion. The security team starts to get a little bit of religion about what they have to evolve to. And it really is kind of that interesting transition where it has started kind of out in the DevOps community with, again, those enlightened ones going, “I don’t know what I don’t know. Let me get some help,” and then it kind of back-ending into security. That’s not always the case, but probably three quarters of the time, that tends to be the transition that we see.

    And the other thing I want to hit is just about velocity, right? JA very forward-thinking DevOps leader that we’re working with, he said it the best. And he’s just like, “I’ve got 20 DevOps teams. I cannot slow these people down. They are doing stuff; they are making progress. The last thing I can do is put a bunch of onerous security requirements on what it is that they’re doing. They’ll ignore me, they’ll go around me and that’s counterproductive. I can’t do that. What I really need is to be able to build and enforce a set of guardrails around their environment.” Right? That term, “guardrails?” It just really kind of opened up and was a light bulb in our head when we were having this conversation. It’s not about stopping them from doing things. If anything, it’s about allowing them to go faster, yet making sure they don’t drive the car off the road, right?

    And that’s really the metaphor that resonates relative to what we’re doing at D:Ops, and really just kind of where the environment is going, in that we have to be able to move faster. Slowing things down is not an option, yet you want to make sure that you are not putting corporate data at risk. You are not opening up significant new attack services just – because people are moving so quickly. Sometimes they make mistakes. Sometimes automation isn’t done in the perfect way. Sometimes humans get involved and certainly are fallible from that standpoint. But with a lot of the inherent, underlying automation orchestration that’s possible within the cloud and DevOps and continuous, you have options to enforce these best practices in a way that we couldn’t do in our traditional data center with our traditional waterfall types of development and operational motions.

    Shimel: Absolutely. And you know, Mike – I mean, I’ve spoken about this a lot at various conferences and stuff. A lot of that has to do – you know, we use this term “shift left” in security and all that. A lot of it does have to do with getting to security earlier, faster. Yeah, we’re going to have to automate it. Yes, we can’t be the roadblock. But we can be the appendix after – when I say, “we,” I mean security. We can be the appendix after the delivery or after the deployment.

    Rothman: I’ll raise you. I see your point and I’ll raise you one, right? I’m of the opinion that security isn’t a thing. Right? Security should be within everything.

    Shimel: Yeah.

    Rothman: And that’s really the mentality that we’ve been trying to push on the industry for a long time.

    Shimel: Amen.

    Rothman: And it’s one of these things where we really can’t afford to wait and be in a position where we’re trying to retrofit poorly architected systems that are moving faster than we’ve ever seen before and then say, “Oh hey, we’ve got to change it because of security,” or because of any other operational gap that we see there. Right? What we have to do is be building in a way that allows us to use architecture as security control, right? Isolation, segregation, multi-factor authentical, identity management – all of these things that are fundamental building-blocks of what we do in the cloud and DevOps can be utilized to build in a much more secure fashion. And it’s really about those kinds of practices that are going to make the biggest difference relative to what it is that we see and what it is that we deploy over the next couple of years.

    Again, like I said, I don’t think security is a thing five to seven years from now. Because if it’s not embedded within everything that we deploy, we screwed up.

    Shimel: Yep. You know, I heard – because I never come up with original ideas. I just listen. But I heard something awhile back – “Security needs to become synonymous with quality.” And we’ve had QA as a concept in software technology forever or for a long time. Security needs to be just built in, like as part of the quality control. Right? The same way shit or stuff gets tested, whether it be hardware or software or whatever. Security needs to be part of that quality. 

    Rothman: You bet. To use a software term? Right? Why is a functionality defect different than a security defect?

    Shimel: Exactly.

    Rothman: Right? And they should all be within the same thing. And again, that’s a lot of when you start talking about immutable, when you start talking about kind of building security testing into your pipeline, which again, is stuff I know that you guys at devopsy.kinsta.cloud write about quite a bit. Again, it’s really not any different than you managing and making sure that you hit your functionality kind of specs from the standpoint of just building code, right? Part of that factory. So yeah, the code has to work, but it also can and should be secure, and there really aren’t different operational motions to make that happen. And that’s what’s so exciting. For a guy who spent 25 years trying to retrofit and get people to think about security as part of their core structure and to treat it as really a business function, it’s really enlightening to be in a situation where you actually can implement a lot of those functions within the core processes that you use to develop the technology.

    And again, are we there yet? Of course not. Is there a lot of education to be done? Without a doubt. But we at least have the option now, right? That’s the aspirational goal to what it is that we all do every day, which is to make sure that we’re pushing for the right types of decisions to be made as early in the process as we can, because we all know how much it costs to fix it later.

    Shimel: Absolutely. Mike, I’ve got to tell you, listening to this conversation, I’m thrown back to, “NAC: is it a feature or stand-alone?”

    Rothman: You’re dating both of us, man. Stop that out. Cut that out.

    Shimel: It’s such a pleasure to talk a little theory here with you. But let’s turn for a second to real stuff. Not that what we’re talking about isn’t real. But I wanted to give our audience a little bit of a taste – so disrupt:Ops – great people, great big problem to tackle out there. Give us some specifics. What are you guys doing?

    Rothman: Yeah, so what we’re doing is we’re basically building a cloud management platform to implement a lot of these ideas that we’ve been talking about for the last couple of minutes, Alan. Initially it’s a guardrails platform. So what we have is the ability to, in an AWS environment, enforce a set of best practices across security, operational and also cost management. So one of those things we don’t talk about too much is that developers don’t really like to shut their stuff down because, “No, it’s going to mess with something. I don’t have to. The CFO bitches but we don’t really care.” What we can do is also implement best practices in order for folks to clean up their room, right? We try to do that with our kids all of the time, too. You know, so we try to do that with our developers as well.

    So really implementing a platform for security, operational and cost management guardrails, to again, immediately not just find the issues – there are a lot of tools, as you said. A lot of vulnerability scanners can kind of look at your cloud environment and tell you you have problems. The issue with that is that most operations people are overwhelmed with the number of other things they have to fix every day. Adding more stuff to their list doesn’t really help them. So disrupt:Ops is really focused not just on finding the issues, but also fixing them and enforcing those best practices. Let me give you an example of that. So let’s just say some person decides they want to open up a server to the internet because it’s just easier for them to do that. Well obviously that would be a pretty significant security problem. So as opposed to just taking that server offline, what you can do is you can basically change the security group to make sure that it’s only accessible via a known, good IP address range within your corporation. That’s a good example of a guardrail. Or making sure that you’ve got MFA turned on for every account that gets spun up by your magical Terraform environment that may not build that out as a core security requirement.

    So again, there are 50 to 60 of these guardrails, in effect, that you can implement in your environment, to again, make sure that you are not just alerting when you get out of policy, but actually fixing the issues, in a lot of cases before you even know they’re issues, so that you’re not sitting there trying to pick up the pieces after half of your data is in Chechnya.

    Shimel: Exactly. Or Romania.

    Rothman: Or Romania. It’s somewhere.

    Shimel: Mike, how is the offering packaged? Is it a SaaS kind of offering? 

    Rothman: Yeah, it is. What we found is since – you know, remember the days where people were like, “Oh, I don’t know about this cloud thing or SaaS. I’m not sure I’m comfortable with that”? Now it’s like, “Wait, you want me to install software in my environment? What? What’s wrong with you?”

    Shimel: That would be kind of oxymoronic for a DevOps tool, but –

    Rothman: That’s right. That’s right. So we deliver as a SaaS service. It’s actually a very cool kind of one-click provisioning process where, when you’re logged into your AWS account, you run basically a cloud formation script that really kind of gives us cross-account privileges to your environment. And again, we’re security guys, right? So at the end of the day, we are basically not even just assuming but enforcing least privilege. So we only have read-only access. When we need to make changes, we grant the privilege as we need it, then we revoke it. Because again, what we’re trying to do is make sure we enforce operational best practices; not add more attack service. So again, we’ve built the environment to be secure by design. We use all of our own dog food, to make sure that we are adhering to kind of common best practices. And again, we’re all 25-plus years security folks, so we do take that pretty seriously.

    Shimel: Excellent. Mike, for people who maybe want to download – not download, excuse me – sign up for it or check it out more, where can they get more information?

    Rothman: Yeah, disruptops.com. So by the time you hear this little interview, the site will be live. There’s a place you can sign up. You know, first we start with a demo and show you what it’s about and then you can sign up for early access. And again, we’re kind of expanding towards the end of this month, in October. We’re going to add a bunch more folks to the system with the goal of kind of being ready to actually sell the product by the end of the year.

    Shimel: Fantastic, man. Well, I don’t have to tell you, Mike. I wish you, Rich, Adrian, Jody, Brandy and the rest of the team nothing but success. We’ll be checking in, I have a feeling, pretty often here, whether it be through Security Boulevard, devopsy.kinsta.cloud, Container Journal or what have you. And you know, fantastic. It’s good to have you back in the game.

    Rothman: Yeah, no, I’m excited. Again, really it’s not just a big promise and not just a huge opportunity. You know, and what Rich, Adrian and I, and now Jody and Brandy have always done is – you know, we’re trying to do the right thing to evolve the practice. Right? And that’s what it’s about. It’s a big world and there’s a lot of opportunity. There’ll be a lot of folks talking about guardrails over the next year. And that’s great, right? Because what we want to do is get to a position where we can move faster but move more securely, and I a lot of cases, in the world that we grew up in, those were counter indicators. Right? You couldn’t move fast and be secure. You couldn’t do operational excellence and make sure that you’ve got a lot of these things enforced. And now you can, and that’s what’s really exciting to us. Again, we’re just excited to partner with you, as always, and again, just go out and solve some bring problems for a lot of organizations.

    Shimel: Fantastic. All right. Mike Rothman, president and co-founder of disrupt:Ops, a hot new entrant in the DevSecOps space, with a great pedigree and a real reason for being our guest today on DevOps Chat. I hope you’ve enjoyed this. This is Alan Shimel for devopsy.kinsta.cloud. Until next time, everyone, have a great day. Bye-bye.

    — Alan Shimel

  • Modern Software Development Helps KPI Achievement

    Modern Software Development Helps KPI Achievement

    A new survey by Frost & Sullivan in collaboration with CA Technologies clearly shows that business executives believe modern software development helps them achieve KPIs. This is the latest in a string of surveys showing that modern software development practices such as DevOps result in higher-performing organizations, more profits and greater KPI achievement.

    Key findings of the survey show that organizations with more mature programs are:

    • Eight times more likely to declare that applications are very good at supporting the achievement of
      business KPIs;
    • Seven times more likely to say their apps are completely integrated to enable functionality, data
      sharing, authentication and security; and
    • Able to achieve two times’ higher profit growth.
    Ashok Reddy, GM DevOps CA Techologies

    I spoke with Ashok Reddy, Group GM, DevOps at CA Technologies about the findings. In addition to the key findings above, Reddy emphasized another key point: The survey showed that in organizations with modern software development programs, business executives outside of IT are key software decision-makers.

    Traditionally, IT was viewed as servicing the rest of the organization as their customer. A key constituency of this customer base would seem to be non-IT business executives. They recognize that software and applications are so important to achieving KPIs. They are moving beyond just being a customer of IT to actually being involved in the software development process itself, according to Reddy.

    key metric

    Some Troubling Findings

    Not all of the findings from the survey are rosy, though. Pressure to release software endangers quality and security, according to 69 percent of the business executives surveyed. More than two-thirds of respondents said that security is sometimes overlooked to expedite development. Software issues negatively impacting KPIs was cited by more than half of the respondents.

    With modern software development practices becoming so important, the findings above seem logical—logical, perhaps, but not acceptable. We must continue to strive to make security a more organic part of the software development process. Security concerns cannot continue to be overlooked because they are a drag on software development. One of the key points that I believe about DevOps and modern software development is that you can have more velocity, speed and security by following these practices.

    All in all, this survey is yet another brick in the wall showing that organizations around the world adopting modern software development practices such as DevOps, Agile, etc., are outperforming their competitors who don’t. It is quickly becoming a case of DevOps or die.

    — Alan Shimel

  • DevOps World | Jenkins World 2018 San Francisco: Video Interviews, Day 2

    DevOps World | Jenkins World 2018 San Francisco: Video Interviews, Day 2

    The recent DevOps World | Jenkins World 2018 San Francisco conference offered a bevy of interesting conversations with folks from all corners of the DevOps space, from testing to automation to security and beyond. All of those conversations are available for viewing on DevOpsTV.

    My two days in the Broadcast Booth on the show floor at the conference was busy, busy, as a number of attendees stopped by for a quick chat with Jayne Groll, CEO of DevOps Institute, or me. Topics ranged from the growing influence of artificial intelligence to the importance of testing and DevSecOps. Below is a recap of the Day 2 video interviews (Day 1’s recap is available for viewing here):

    Contrast Security Discusses DevSecOps

    Mahesh Babu of Contrast Security stopped by to discuss his company’s technology, which helps an app protect itself through agents that constantly monitor the code to see in real time any problems within the application.

    Smart Bear Talks AI and Testing

    Daniel Giordano of SmartBear chatted with us about how his company is using artificial intelligence technology in its testing products to test things beyond objects such as images and charts.

    Perfecto’s Kinsbruner Debuts Continuous Testing Book

    Eran Kinsbruner of Perfecto talked with us about the launch of his book, “Continuous Testing for DevOps,” which he wrote in conjunction with CloudBees.

    JFrog Offers Take on DevOps Culture

    Baruch Sadogursky of JFrog discussed the challenges in DevOps with respect to culture and ways companies are finding ways to make the cultural change.

    Electric Cloud Offers Technology Update

    Electric Cloud’s Sam Fell stopped by the Broadcast Booth and offered up an update on the company’s technology stack and its potential impact on the development environment.

    IT Methods Talks Cloud Adoption

    Paul Goldman of ITMethods talked with us about the evolution from on-premises to cloud deployments and the various reasons why organizations are making the change.

    Go2Group Offers Service Provider Perspective

    Mike Maheu of services provider Go2Group discussed the trends his company is seeing regarding organizations that are undergoing DevOps adoption, including the tooling and practices.

    Services Provider Zivra Talks DevOps’ Global Impact

    JJ Alvarez of Zivra, CloudBees’ Partner of the Year, talked with us about the global expansion of DevOps and the recent surge of Latin American and South American countries adopting DevOps principles.

    SauceLabs Talks Testing and Security

    Clint Sprauve from SauceLabs stopped by to discuss the correlation between testing and security in DevOps as companies struggle to maintain quality in their application development process.

    Releasing the Gitcracken

    James Quigley of Gitcracken talked with us about the role of his company in helping developers improve their coding performance and productivity and increase the comfort level of less-experienced developers.

    Twistlock Talks Kubernetes

    Matthew Barker of Twistlock discussed the impact of Kubernetes on application development and trends he’s seeing in the Kubernetes space as a whole.

    Pivotal’s Approach to DevOps

    Pivotal’s Nima Badiey schooled me on his title and chatted about how his organization approaches DevOps with its customers, especially large enterprise companies that have legacy systems and mindsets.

    NowSecure Talks Mobile Development

    NowSecure Chief Mobility Officer Brian Reed discussed trends in the mobility space, including the use of mobile app projects as a “gateway to DevOps.”

    — Charlene O’Hanlon

  • DevOps Chat: All Day DevOps Preview

    DevOps Chat: All Day DevOps Preview

    All Day DevOps, the virtual event featuring more than 100 sessions from practitioners around the world, is happening very soon. Now in its third year, this year’s event will take place Wednesday, Oct. 17, starting at 3 a.m. Eastern. But if you don’t feel like getting up, each 30-minute session will be available on demand as well.

    In this DevOps Chat, All Day DevOps founders Derek Weeks and Mark Miller, both also from Sonatype, offer a preview of what’s in store during this year’s virtual event, which is free to attend.

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

    Audio

    Transcript

    Alan Shimel: Hey, everyone. It’s Alan Shimel, devopsy.kinsta.cloud, and you’re listening to another DevOps Chat. Really happy to have two friends of mine join us on the chat today. We have none other – those crazy guys from All Day DevOps and Sonatype, Derek Weeks and Mark Miller. Mark, Derek, welcome to DevOps Chat.

    Mark Miller: Thanks, Alan.

    Derek Weeks: It’s good to be here. Always happy to chat with you.

    Shimel: Yeah.

    Miller: Thank you, Alan. Welcome to New York, welcome back home.

    Shimel: Yeah, it’s good to be home. So Mark, you know, this is an audio only, people don’t know, but you have a Fighting Okra hat on, is that correct?

    Miller: You know, some of my followers from around the United States are sending me hats and right now the Delta State Fighting Okras have sent me a hat so I’m gonna be giving them a good callout during All Day DevOps. Derek, you haven’t seen this one yet.

    Weeks: No, I haven’t. That’s pretty cool-looking.

    Shimel: All right, a shout out to the Fighting Okras.

    [Laughter]

    But Mark, you mentioned All Day DevOps. We’re getting close, right? What’s the date?

    Miller: We’re next – we’re gonna be on Wednesday, October 17, and as we looked at this morning, as we looked at it, we’re over 19,000 registrations this morning. Once again, the community has gotten behind it. Derek, you’ve got a bigger hand on it, too. You’ve got some ideas about what’s going on with the viewing parties even, right?

    Weeks: Yeah, I think the – you know, we’re at 19,000, I think we’re easily headed over 30,000 by the time we get to the conference, and I think part of that is what we’ve seen with the viewing parties this year. So, you know, it’s an interesting kind of evolution of the conference where we started this thing as, hey, let’s have this virtual conference so that everyone can attend wherever they sit, and then people said, “You know, I want to participate but have others in my company or my community participate as well, so we’re just gonna gather in a place to have this viewing party.” In the first year that we did it there might’ve been 10 because it wasn’t a formalized thing. Last year we kind of encouraged people to do it but didn’t have anything on the site that really mentioned it too much, and I think we had 35 viewing parties.

    This year we have 115 viewing parties that have registered in 24 countries, and the interesting thing is not only has that changed the conference and how it evolves and how people share this education within groups but we’ve heard some amazing stories just come out of this community where organizations like RBC in Toronto, they’re planning for up to 1,400 people in RBC to attend their viewing party. State Farm in Dallas has 500 people that they’re planning in their viewing party. National –

    Miller: They went up to over 800 this weekend.

    Weeks: Yeah. National Australia Bank; you know, they’re planning, I think, 250 people in their viewing party. And when you think about the size of some DevOps conference that all three of us have been to, anyone having 500 people at a DevOps conference has a successful DevOps conference. The fact that one company, you know, is setting up a viewing party just for our conference that’s as large as some DevOps conferences out there it’s pretty interesting. But, you know, the same point – and this is a conversation I had with someone this morning in Munich, he said – you know, we’ll get into talking about Club 20 – but he said, “Hey, do we have 20 people registered yet because we want to get our company into Club 20,” and I hadn’t heard of this organization really before.

    And I looked; they had 16 people. Now they actually have 20 so they’ll make the list. But I said, “I’m curious; how many people in your organization could attend All Day DevOps that, you know, are DevOps practitioners?” And he said, “You know, like I want to get on the Club 20 list, but I think we could get 100 people at our viewing party and in a perfect world we could have 1,000 people participate in All Day DevOps.” And that – you know, Mark, as we started this whole thing, that was really the aim, like how do you get to those 1,000 people and give them some free education?

    Miller: Yeah. One of the topics that you just touched on – and you and I talked this morning too as we were putting together how our day was gonna go – Alan, when you think about it, can you imagine 20 people showing up at a live conference? I mean think about that. If you get four or five people at a live conference from one company you’re blowing out the budget, right, already. In this case, we can literally allow dozens and dozens of people from the same company to attend 120 sessions in a live conference. It’s a pretty phenomenal way to look at it.

    Shimel: And, you know, so one way of looking at it, Mark, is wow, what would the cost be to fly in a dozen, two dozen, three dozen people to a physical conference? The other thing, you know, to make it a truly win-win is what are the benefits of a team that size sharing that common experience, right? It’s almost priceless, right? It’s like the MasterCard commercial: $45 for the conference ticket, $60 on Uber, $20 on lunch. Sharing it as a team? Priceless.

    Miller: Yeah.

    Shimel: And that to me is the real one plus one equals three of it.

    Weeks: Yeah, I think – and that’s something that we see – you know, as we’ve seen the past two years that we’ve done this and I think we’ll see again in spades, is that we have the Slack channel set up during the conference for conversations, and last year during the 24 hours of the conference we saw 30,000 conversations on Slack, and that ability to exchange information, whether it’s with people on your own team and you have your internal Slack channel set up through your own company because, you know, you’re State Farm and that’s what you did and how you shared information, or you’re participating in the global channel, you know, I think it’s all about that kind of exchange of information and also the anonymous – somewhat anonymous level of that communication.

    We all know it’s a lot easier to ask a question in a conference if no one can see you’re the person raising your hand or asking the question; you’re just one of many on a Slack channel saying, “Hey, I have this question,” and there’s – you know, it opens people up to sharing a little bit more or asking questions they might not otherwise get to ask.

    Shimel: Absolutely, absolutely. Guys, I want to turn the conversation a bit if I can from numbers and viewing to content. Let’s talk – you know, people out listening to this, some of them may already be registered, some may not, some may not even know of All Day DevOps, right?

    Weeks: Yeah.

    Shimel: Mark, if they register – and registration’s free. You don’t have to be part of Club 20, you don’t have to have your whole company. If you’re just one person who’s digging DevOps you can register for free for All Day DevOps and sit in on 24 hours – up to 24 hours of DevOps, right? They don’t have to listen to all of it; you pick and choose what you want. But give us some of the highlights. What are some of the big hot topic speakers that you’re looking forward to?

    Weeks: Mark, why don’t you go –

    Miller: One of the things that you just – sure. One of the things that you just said is interesting to me, Alan. You said 24 hours of DevOps. Actually, when you do the math it’s more like 50 to 70 hours of DevOps because we have simultaneous channels happening. The things that I’m excited about seeing is, one, we have David who runs a CRE team and an SRE team at Google coming to talk about site reliability engineering. That’s a new topic for us this year, and to have Dave step in from Google, who is actually running that whole initiative for Google, it’s gonna be an exciting one for me. The other one that I’m – how do I say it?

    I’m exciting that Cindy’s coming, Cindy Healy. She is the one that wrote some of the code that went on the Mars Pathfinder to send to Mars. Now that’s – the personal story behind how Cindy did that and how she became involved in it, what’s she’s doing now to encourage women in technology, that is a story that I really want people to be able to hear, so we’ve got her set up as a keynote. Derek, you’ve got some interesting things that you’re looking forward to, right?

    Weeks: Yeah. You know, one is a conversation I just had last week with one of our keynote speakers, George Swan. He’s at Autodesk. Super interesting story of DevOps in the enterprise. So these guys knew, you know, the needed to transform the entire company – and I think they have about 200 products, 4,000 developers in their organization, and they needed to transition from an Agile organization to an organization that had DevOps practices top to bottom. At the same time that they were doing this they needed to transition into the cloud. They also needed to transition from a traditional license business to a subscription license business.

    They had, like, four or five transformations going on at the same time – you know, become cloud-based infrastructure, transition to SaaS, transition to DevOps and some other things, and it was like, oh my gosh, one, this is a multiyear journey he’s gonna tell his story on, so it will be fascinating to kind of get lessons learned and also understand it’s not just hey, you know, transition to DevOps; it’s there are a lot of other things that are moving parts of our business that have to change, you know, along with this as the marketplace evolves for them and other participants. The other one that I’m really excited about, and a guy that I’ve got to see a couple of times at live conferences, is Navin Vembar. He’s the CTO over at GSA, the Government Services Organization.

    They do all the main procurement for the U.S. government. But he is going to talk about how they transformed their organization into a DevOps practice and kind of looking at the maturity models that they use and kind of used as milestones for measuring their progress within their organization and also, you know, coming from an organization that loves silos, they love regulation, [laughs] they overly love governance sometimes, but to hear his journey, he’s a fascinating speaker and someone that I quote often, so always looking forward to hearing people like that join in.

    Shimel: Sure.

    Miller: Alan, the other thing is as Derek was talking I went over to the All Day devopsy.kinsta.cloud site and clicked the speaker link. We’ve got 124 speakers this year. We had so many good submissions that we actually went above our quote. We had set it at 100 and we’re at 124 right now. It’s hard to go and cherry pick out of those. What we want to make sure people understand is two things; No. 1 is we want to bring 124 practitioners to everybody’s desktop. We want you to be able to pick and choose what you’d like to hear.

    No. 2, Derek and I guarantee to the community is there are no vendor pitches here. Alan, you’ve been with us long enough you know. We really hold to that creed, that what we want is practitioners, and when you come here I think that you can trust us to provide that to you.

    Shimel: Absolutely. That’s another aspect I want to just highlight too, guys. You know, we – you both highlighted what – some of the ones you’re – some of the talks you’re looking forward to most. Well, Mark, there’s 124 as you mentioned. All Day DevOps is a global phenomenon, and though we may have GSA and we may have some U.S.-based practitioners, Mark, I’ve been around the world with you, right? You and I have traveled – [laughs] literally traveled the world, and DevOps is a worldwide thing, and I think the speaker lineup reflects that. Have you had any stats, like how many different countries are represented?

    Miller: Yeah, Derek’s got that, but before he jumps in with the stats I got a story that you’ll recognize. You and I went to Singapore, Bangkok, Sydney and Melbourne about two months ago.

    Shimel: Yep.

    Miller: While we were having dinner with Rob England in Sydney, I went, “Man, you’ve got a great story, Rob. Why don’t you speak at All Day DevOps?” Meaning because of our travel, because of our ability to meet people in the community, it gives all of us the ability to say this guy’s got a story that deserves to be told, and I think that that’s one of the things when Derek and I were first putting this together we actually talked to – amongst ourselves and said what we want to do is give exposure to people that are doing DevOps that deserve more recognition for what they’re doing, and our global platform has allowed us to do that. Derek, how many countries are we dealing with now?

    Weeks: I think, you know, we’re around 130 different countries participating.

    [Laughter]

    It’s amazing, you know, to see that list grow because some of these – you just imagine like who’s practicing DevOps, and in my head like maybe 22 countries and maybe if I stretched it like maybe 40, right? But to see participants from all over the place – you know, and I just did a quick look at the registrations in the top cities. So No. 1, Bangalore, second, London, Toronto is high on the list, Melbourne, Australia; Sydney, Australia, Atlanta, New York, Istanbul, Chicago, Singapore, Amsterdam, San Jose, Seattle, Santiago, Jakarta.

    Shimel: That’s amazing.

    Weeks: You know, in the top 20, right? So it’s really, you know, a global kind of phenomena that we’re seeing. You know, where is the DevOps kind of center of expertise? Where are these people around the world? It’s pretty interesting to see where they all come from.

    Shimel: Agreed. You know, Mark, listening to you talk –

    Miller: I don’t want to leave anybody out but when we –

    Shimel: Go ahead. You go, Mark.

    Miller: Go ahead, Alan, go ahead.

    Shimel: No, no, you go.

    Miller: Yeah, I just – I don’t want to leave anybody out, but there’s some names I’d like to give out a call to, is like Midu in India, who’s helped us so much with the community in India. Look at Bangalore; it’s No. 1 on the list. When you look at Michael Mann, you look at Mark Cluett in London; those are community people that have said this is something worthwhile and I want my community to know about it, and that’s kind of – I don’t know if heartwarming is the word, but it means that we have actually resonated with various communities, cross-cultural around the world, and that means a lot to me.

    Weeks: Yeah, I just – you know, curious, I just looked at the list of what cities have 40 people registered – Alpharetta, Georgia – that’s near Atlanta – Johannesburg, South Africa, Istanbul, Dubai, Barcelona, Seoul, Sao Paolo, and McLean, Virginia, where I’m sitting.

    Shimel: Seoul, I haven’t heard Seoul yet.

    Weeks: Yeah. So fascinating, just that list of only cities with 40 is extremely diverse.

    Miller: Wow.

    Shimel: You know, that’s really – that’s the power of the internet and it also speaks, Mark, to the power of DevOps, is if it was all centered in San Francisco or London, great. All the cool kids, right, are doing it. But it’s not; it is – it’s diversified, decentralized. You couldn’t snuff it out if you tried. You know, Mark, listening to you talk though a little bit about we met this one here and this one there, I can’t help but think of you as sort of the Anthony Bourdain of DevOps, venturing into parts unknown.

    Miller: You know, I’m a story guy. I gotta jump in there. When I was in Manila, we got Anthony Bourdain’s driver to take us around to all those places. It was fascinating.

    Shimel: And I’ve been on those trips with you. You like to off the beaten path. But, you know, this is a PG-rated show and, you know…

    [Laughter]

    Weeks: I’m gonna give Mark a new title of the Anthony Bourdain of DevOps.

    [Laughter]

    Miller: I’ll take it, I’ll take it.

    Shimel: Anyway, hey guys, we’re about out of time here, but I wanted to check in ’cause we are getting close. We would be remiss if we didn’t at least mention where can people go to register for All Day DevOps? Derek?

    Weeks: AllDaydevopsy.kinsta.cloud. It’s that easy. It takes 15 seconds to register. You’ll get a link to the schedule once you register so you can start to build your own schedule for yourself and your organization. And like we always say, once you register yourself encourage your team to register so that everyone can watch together.

    Miller: Alan, the last thing that I’d like them to look at on the site too, is once they register go to the viewing party page. With over 110 viewing parties there has to be something local, that’s relatively local, if you would like to participate with other people.

    Shimel: Fantastic.

    Weeks: You know, the other thing just really quick before we go is one way that we do this conference for free for everyone is we have a lot of sponsors, like devopsy.kinsta.cloud, Scaled Agile, Cisco, Puppet, Chef, GitLab, Sonatype, CloudBees and other organizations that help fund the conference to actually put this on and make this happen. We also have 245 community groups around the world that are helping us spread the word to say here’s free education for our members, and that’s really at the heart of this conference is the financial support to make it free for everyone and the community’s support to really spread the word to everyone that this is available to them.

    Shimel: Excellent. Absolutely, Derek. These – as someone who’s done enough conferences, it really – it doesn’t happen without the sponsors, and a lot of people say, “Oh, the sponsors just want to spam me or contact me.” Yeah, you can talk about that all you want but they make the world go round on these things, right?

    Weeks: Yeah.

    Shimel: We can’t do it without them and don’t lose sight of that.

    Weeks: Yeah. It doesn’t cost $10 million to run but it’s not free to run. [Laughs]

    Shimel: Exactly. But we all know that. Anyway, guys, two of my good friends in the DevOps – well, not only in the DevOps space, in the world in general. Mark Miller, who I have traveled around the world with and eaten in some very –

    Miller: Thank you, Alan, so much.

    Shimel: – fun places – Anthony Bourdain there – and Derek Weeks.

    Weeks: Thanks, Alan. Always a pleasure.

    Shimel: Always a pleasure, man. I haven’t seen you in too long.

    Weeks: Well –

    Shimel: But hopefully we’ll see each other soon.

    Weeks: Yeah.

    Shimel: All Day DevOps coming to a computer near you Oct. 17, right?

    Weeks: Yep.

    Shimel: All day.

    Miller: Starting at 3 a.m. New York Time, Alan.

    Shimel: Excuse me?

    Miller: Starting at 3 a.m. in New York. I’m sure you’ll be with us for the opening.

    Shimel: Yes, I’ll be up bright and early at 3:00. But if you want to register, go to AllDaydevopsy.kinsta.cloud, guys. It’s free. Jump on it. It’s a great event. Have a great day, guys. Thanks for joining us. This is Alan Shimel for devopsy.kinsta.cloud and you just listened to another DevOps Chat.

    — Alan Shimel