devopsy.kinsta.cloud

Category: Features

IBM and Red Hat: Now, That’s an Interesting Combination
Like everyone else, Sunday night I got a surprise with the pre-announcement of IBM’s intent to acquire Red Hat (I might have seen it a little earlier than the rest of you, as a friend from IBM shared it as soon as it was public). I’ve been mulling this over and checking out the information being provided thus far, and have some early thoughts:
- No matter what, some people aren’t going to like this.
- Very much like Microsoft purchasing GitHub, you’ll see negative knee-jerk reactions.
- Early indicators are that it is good for everyone.
Of course, since the acquisition isn’t expected to close for about a year, all we have is early indications, but they do seem positive.

Fear for Open Source

IBM goes a long way to assuaging the instant fear that many will have. From the press release to the investor relations call, the company makes it very clear that Red Hat will operate on its own. IBM stops short of saying, “wholly owned subsidiary,” but is keeping all that makes Red Hat, well, Red Hat. That will likely change over time—it does for any acquisition—but for the near future, Red Hat’s strategies and values will continue. So those people who will inevitably equate this to the death of open source can be safely shushed or ignored.

Customer Concerns

Red Hat knows that there is an open source equivalent to everything it does, and as such it treats those willing to fork over money either for support or more polished products as if they could walk away tomorrow. There is nothing in any of the released documentation to suggest this will change. In fact, “keeping Red Hat’s strategy” specifically was mentioned to investors, and this world view informs all of their strategy. One Red Hat person I worked with years ago put it: “We need to give them a reason for paying us when they don’t have to. That’s where support and service come in.” In the short term, that does not appear to be changing.

Cloud Boom!

IBM is right, the future of cloud is in two narratives: one of cloud portability and another of on-premises for stuff that just isn’t that portable. IBM plus Red Hat is in a unique position to serve those two markets and offer up DevOps toolsets based on standards that will spin up whatever, wherever. Between them, they work with every major public cloud vendor, support containers and have fingers deep into the private cloud space. If their predictions that workloads will continue to move toward on-demand is accurate, it will be difficult to find a better solution set than the two can offer together.

So Overall, it Looks Good

I was in discussions on several social media platforms over the course of Sunday evening about this, and the consensus seems to be that it could be far worse. If Red Hat were for sale, think through all the companies that would see benefit in owning Red Hat, and could afford the price tag IBM paid. There are not a lot that could be counted on to “Let Red Hat be Red Hat.” Over the long term, IBM can’t either, but that is simply business. In the short term, it is reasonable to expect that not much will change except Red Hat customers get pitched more IBM software and gear, while IBM offers Red Hat standard with their other offerings. Other potential purchasers would likely completely fold Red Hat into their business, thereby destroying what makes the company unique. So if Red Hat was going to be sold, the face the two companies are putting on it is the best we could hope for.

Ops Side Love

Red Hat has done a good job of integrating containers as they came along, and Ansible provides decent configuration support for a variety of deployment targets. Merging that with IBM’s cloud work should offer a streamlined DevOps pipeline that can handle whatever target you want it to configure. Oh, certainly there will be speed bumps along the way—we do live in a time of change, which brings them along—but portability plus programmed configurability will (as IBM has hinted) equate to prequalified stacks that can then be dropped into deployment toolchains.

Not too Long to Wait

While the official merger will not be consummated until late next year, expect to see the two organizations use their longstanding partnership to begin exploring cross-company cooperation before that. We should see the first fruits of this arrangement relatively quickly, and unless Red Hat’s investors find some reason to vote down a HUGE raise of their per-share stock value, expect that the cooperation will continue to ramp up until the acquisition is completed.

If Red Hat Stays the Same…

Given that IBM has said Red Hat would stay the same for the foreseeable future, that means all you are doing with the company can keep going, and you can pick and choose which of the partnership options that are bound to come along pre-completion you wish to take advantage of. That’s a benefit to the customer. So grab what you like and keep making your DevOps environment better.

— Don Macvittie
October 31, 2018
IBM Acquires Red Hat to Create DevOps Behemoth

In a move that has massive implications for DevOps teams across the enterprise, IBM today announced it is acquiring Red Hat in a deal valued at $34 billion.

Red Hat will join IBM’s Hybrid Cloud group as a distinct independent unit. Red Hat will continue to be led by Jim Whitehurst and Red Hat’s current management team. Whitehurst will join IBM’s senior management team and report to IBM CEO Ginni Rometty. IBM intends to maintain Red Hat’s headquarters, facilities, brands and services practices.

IBM expects to close the deal, which will be financed using both cash and debt, in the latter half of 2019. IBM also said the deal will be accretive within 12 months after close, as the combined entity moves to address a total market that spans application development and deployment, IT services and security and collectively exceeds $1 trillion, or more than one-fifth of the total global IT market valued at $3.7 trillion in 2018 by Gartner.

IBM and Red Hat have had a partnership in place for 20 years, spanning everything from reselling and supporting Red Hat Enterprise Linux (RHEL) to collaboratively working on open source projects such as Kubernetes.

IBM officials said they expect Red Hat to significantly bolster IBM’s hybrid cloud business, which already generates $19 billion a year in revenues. IBM noted that about 80 percent of application workloads have yet to move to the cloud.

The move to acquire Red Hat comes on the heels of Red Hat acquiring CoreOS, which augments the company’s existing open source expertise with a container management platform built on top of Kubernetes.

Once the deal is closed, IBM said the two companies will remain committed to open source software licensing, including initiatives such as Patent Promise, GPL Cooperation Commitment, the Open Invention Network and the LOT Network.

IBM and Red Hat also plan to continue to build and enhance existing Red Hat partnerships, including those with major cloud providers Amazon Web Services, Microsoft Azure, Google Cloud, Alibaba and others that compete directly with IBM Cloud.

It’s too early to say to what degree those cloud service providers will be open to continuing to work with Red Hat as unit of IBM. In recent months Red Hat increasingly has been positioning itself head to head against VMware, which operates as a unit of Dell Technologies. IBM also has a strong relationship with VMware that could change in the years ahead. What is clear, however, is that any deal of this magnitude usually begets others in very short order.

— Mike Vizard

October 28, 2018
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

October 26, 2018
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.

Speakers

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.

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

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

October 23, 2018
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
October 22, 2018
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

October 22, 2018
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 DevOps.com, 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, DevOps.com, 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 DevOps.com. 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 DevOps.com, 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 DevOps.com 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 DevOps.com 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 DevOps.com. You’ve just listened to another DevOps Chat.

— Alan Shimel

October 19, 2018
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

October 18, 2018
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://devops.com/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, DevOps.com, 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 DevOps.com 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, DevOps.com, 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 DevOps.com. Until next time, everyone, have a great day. Bye-bye.

— Alan Shimel

October 17, 2018
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.

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
October 15, 2018