Category: Features

  • 2017 DevOps Dozen Finalists Announced

    2017 DevOps Dozen Finalists Announced

    We are today announcing the 2017 DevOps Dozen finalists. When I first came up with the idea of the DevOps Dozen 3 years ago, I hoped that one day it would grow into an award that really did recognize the best of the best in the maturing DevOps space. In its third year, I am happy to report that the DevOps Dozen has achieved its mission. This year our categories, the votes, the process and the judges are all aligned to bring you what we think is the strongest DevOps Dozen finalists ever.

    We had to go through thousands of votes, many of them write-ins to pick out the six finalists in each category. It was not an easy task as we couldn’t automate it, we had to do it by hand. We opened nominations back in early October. Many thanks to the team here at devopsy.kinsta.cloud for going through them all. We have notified the finalists in each category and they are submitting information which we will pass onto our panel of judges, who will pick the winner in each of the 12 categories (it is the DevOps DOZEN). We will announce the winners in early January, so stay tuned.

    Before I give you the lists of finalists though, a quick thank you to our panel of judges who will now pick the winners. George Hulme, Ericka Chickowski, Jayne Groll, Helen Beal and Rob Stroud, along with myself will now have the tough job of picking among the best group of finalists we have ever seen. BTW, you can see a much better version of this finalist list by jumping over to the DevOps Dozen site.

    Here are your finalists:

    Category 1 – Best DevOps Open Source Project

    1. Jenkins
    2. Cloud Foundry
    3. Taurus
    4. Artifactory
    5. Open Stack
    6. Docker

    Category 2 – Best DevOps Commercial Solution

    1. CloudBees Jenkins Enterprise
    2. IBM Cloud Garage
    3. CA Automic Release Automation
    4. Datical
    5. XebiaLabs DevOps Platform
    6. Electric Cloud Electric Flow

    Category 3 – Best DevOps Solution Provider Exec

    1. Sacha Labourey/Kohsuke Kawaguchi
    2. Steve Robinson
    3. Jeff Scheaffer
    4. Jennifer Tejada
    5. Rachel Reinitz
    6. Todd DeLaughter
    7. Yoav Landmen

    Category 4 – Best DevOps Solution Provider

    1. CA Technologies
    2. CollabNet
    3. IBM
    4. PagerDuty
    5. Electric Cloud
    6. JFrog

    Category 5 – Most Innovative DevOps Solution of the Year

    1. CA Continuous Delivery Director
    2. CloudBees DevOptics
    3. Chef Habitat
    4. IBM DevOps Insights
    5. Electric Cloud DevOps Insight
    6. Tricentis Tosca

    Category 6 – Top DevOps Evangelist

    1. Brian Dawson, CloudBees
    2. Sanjeev Sharma, IBM
    3. Aruna Ravichandran, CA Technologies
    4. Robert Reeves, Datical
    5. Baruch Sadogursky, JFrog
    6. Derek Weeks, Sonatype

    Category 7 – Best DevOps Transformation

    1. NBC Universal
    2. Lincoln Financial Group
    3. Capital One
    4. Bendigo and Adelaide Bank
    5. Westpac New Zealand

    Category 8 – DevOps Transformation Leader

    1. Brock Beatty, Capital One
    2. John Comas, NBC Universal
    3. Dawie Olivier, Westpac
    4. Alice Raia, Kaiser Permanente
    5. Paula Thrasher, CSRA Inc.
    6. Pauly Comtois, Hearst Business Media

    Category 9 – Best New DevOps Solution Company

    1. ShiftLeft
    2. Harness
    3. LightStep
    4. AppOrbit
    5. Heptio
    6. nClouds

    Category 10 – Best DevOps Book/ebook

    1. A Seat at the Table, Mark Schwartz
    2. DevOps Adoption Playbook, Sanjeev Sharma
    3. DevOps for Digital Leaders, Aruna Ravichandran,‎ Kieran Taylor,‎ Peter Waterhouse
    4. Starting at Scaling DevOps in the Enterprise, Gary Gruver, Jez Humble (Foreword)
    5. The Science Behind DevOps, Nichole Forsgren, Jez Humble, Gene Kim
    6. Making Work Visible, Dominica Degrandis

    Category 11 – Best DevOps Presentation

    1. Next Generation of Continuous Delivery Containers, Robert Stroud, Eric Minick
    2. The 10 Commandments of Continuous Delivery, Viktor Farcic
    3. Is Your Testing a Trick or Treat?  The New Paradigm of Testing in a DevOps World, Adam Auerbach 
    4. DevOps: The New Reality for Enterprise Transformation, Angel Diaz, Gene Kim, John Comas, David Lindquist, CJ Paul
    5. What We Learned from the 2016 State of DevOps Report – Nicole Forsgren and Jez Humble, RSA DevSecOps
    6. What Legacy government organizations need to advance the state of DevOps, Suzette Johnson and Robin Yeman

    Category 12 – Best devopsy.kinsta.cloud Article

    1. Why DevOps Requires a new operating model, Mustafa Kapadia
    2. Continuous Testing: Solving the Biggest Bottle Neck, Aruna Ravichandran
    3. Get the Full DevOps Picture with the CD Map, Scott Wilson
    4. Should You Go Serverless, the pros and cons, Asaf Yigal
    5. 7 Best practices for continuous delivery success, Yani Yehuda
    6. Continuous Integration vs. Delivery vs. Deployment: What’s the Difference? ,Chris Tozzi

    Good luck to all of the finalists!

    Also if you want to be included in next years DevOps Dozen awards you need to subscribe to devopsy.kinsta.cloud and look for announcements next September.

     

    — Alan Shimel

  • DevOps Chat: Chef Habitat Project Continues to Mature

    DevOps Chat: Chef Habitat Project Continues to Mature

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

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

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

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

    Audio: Chef Habitat

    Transcript: Chef Habitat

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

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

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

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

    Shimel: Thank you.

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

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

    Blake Irvin: Yep.

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

    Irvin: It’s called smartB.

    Shimel: smartB.

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

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

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

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

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

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

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

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

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

    Drew: Yeah, yeah.

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

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

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

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

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

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

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

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

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

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

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

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

    Irvin: Yeah, you could say that.

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

    Irvin: Yeah, that’s true.

    Shimel: Let’s talk about why.

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

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

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

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

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

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

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

    Shimel: Wow.

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

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

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

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

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

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

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

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

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

    Shimel: So, it’s Habitat.sh?

    Drew: Yeah, yeah.

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

    Drew: Thanks so much.

    Winsor: Thank you.

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

    — Alan Shimel

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

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

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

    CA World 2017

    What Was All That DevOps?

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

    DevOps everywhereCA World 2017’s main floor segments were:

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

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

    All Your DevOps Are Belong To Us

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

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

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

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

    What’s Still Needed?

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

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

    Conclusion

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

    — Alan Shimel

  • The DevOps Cha-Cha from DOES San Francisco

    The DevOps Cha-Cha from DOES San Francisco

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

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

    DevOps Transformations Are Not Easy

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

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

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

    Failure Is Not An Option

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

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

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

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

    The DevOps Cha-Cha

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

    More DOES Coverage

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

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

    — Alan Shimel

  • Automation and Its Impact on Cultures

    Automation and Its Impact on Cultures

    Let me tell you about my granddaughter. She’s 14 years old and wicked smart. For a while we did pair programming together online in Python. In the old days you took your grandkids fishing. Today we code. Go figure.

    These days, we don’t program together as much. She’s too busy preparing for math competitions. As I said, she’s wicked smart. Needless to say, my granddaughter has quite the future in front of her.

    A few weeks ago, I had the opportunity to visit her in real time and space. We sat around drinking hot chocolate and cappuccino, talking about Big Picture stuff. That’s what grandparents are supposed to do with their grandkids, talk about matters beyond the day to day. At one point during the conversation I asked her the following question, “Are you friends with anybody who has trouble reading?”

    Her reply was, no. All her friends read quite well and were interested in things that interested her. She wasn’t bragging or anything like that. It was just a matter of fact. All her friends are smart, engaged, have cell phones and know how to work a computer.

    My question came from a book I had just finished reading, “Coming Apart,” by Charles Murray. One of the key points that Murray makes is that we’re dividing into two cultures and the distance between the two is growing wider. A key way to figure out how far from that “other” culture you are is to tally up the number of friends you have who have trouble reading. One camp will have a lot. The other will have practically none.

    Back when I was my granddaughter’s age I had friends who had trouble reading. We met playing pickup basketball. The ability to read wasn’t important in that context. We based friendship on other factors. We played ball and rubbed off on each other. Some of the things that the poor readers were good at rubbed off on me. I like to think some of my better qualities rubbed off on them.

    But that was then and this is now.

    In the book, “Brave New World,” written in 1932, people are born in test tubes according to genetic recipes. Some grow to be highly intelligent, creative, analytic Alphas. Others grow up to be be Betas, people that can perform highly complex tasks such as mixing volatile chemicals, but without having an inkling of understanding as to why they are doing the task. Gammas were good at adding up numbers and thus, become bookkeepers. Deltas are the truck drivers and elevator operators. Epsilons are grown to be three feet tall and abhor the outdoors. They do the dregs of factory work, climbing in and under machines.

    Now, hold that thought while I tell you about my daughter.

    My daughter is a high school teacher. Most of her students are from what is termed, the wrong side of the tracks. They don’t read that well and are not terribly engaged in school. But, they do have cell phones and they know how to use them—mostly to text back and forth to home and with friends in classes in other parts of the building. To use the transportation analogy, for all intents and purposes they use of technology not so much to explore but to get from one place to another, something a driverless vehicle will do better than the human counterpart in the not-too-distant future.

    So, what does this have to do with DevOps?

    We in DevOps are the people who are going to drive most, if not all, the technology that will control the world. We are the Alphas. To get into our club you need to be very, very smart. Our work is complex and requires both commitment and ability to engage in continuous learning. When my granddaughter comes of age, she will mostly likely get into the club, maybe with honors. She lives in a world of increasing returns. Because she is smart, she hangs out with smart people. Because she hangs out with smart people, she will get smarter. To use an analogy: Those who know how to work GitHub have a universe of code at their disposal. Thus, they will make a lot more code for the world to use. Those who can’t do a pull request are stuck dead in their tracks. Access to opportunity provides more access to opportunity.

    Using the model in “Brave New World,” those using GitHub creatively as part of the software development life cycle can be considered Alphas. Those who can’t are Betas, Gammas, Deltas and Epsilons. The really bad news is that the work of Betas, Gammas, Delta and Epsilons is low-hanging fruit for replacement by automation and robotics. The work of Alphas is a lot more difficult to emulate with machine intelligence. Corporate employers will still need them. The Alphas will do just fine.

    Hopefully, those who are displaced by automation will be assuaged by low-cost television and cell phone plans that offer unlimited data and texting. Otherwise, they’re going to be looking around for something else to do instead of working. Hopefully there will be “something else to do” while the other culture is prospering.

    My granddaughter’s world reflects the trend that Murray and others describe. We’re dividing into two cultures and the distance between these cultures is growing. The sad part is that the experiences that used to provide a bridge between cultures are becoming less common. There are fewer common spaces in which we can rub off on each other benignly, with no other agenda than to get the ball through the hoop. If the trend continues, the cultures will grow so far apart that they will become unrecognizable to each other. Once recognition leaves the landscape, understanding and empathy are not far behind. You cannot have affinity for that which you cannot see.

    Is it possible to reverse the trend? Is it possible to have an outcome other than the very probable one on the horizon? I don’t know. But, if we don’t try, the ramifications will be dire.

    — Bob Reselman

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

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

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

    devops connect: DevSecOps Days 2018 @ RSAC

    Why Speak at DevOps Connect: DevSecOps Days @ RSAC

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

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

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

    What Are We Looking For?

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

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

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

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

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

    How You Can Attend DevOps Connect: DevSecOps Days @RSAC

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

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

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

    Wait, there’s more

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

     

     

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

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

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

    — Alan Shimel

  • Nutanix Extends DevOps Ambitions

    Nutanix Extends DevOps Ambitions

    Nutanix at its .NEXT Europe conference has signalled its ambitions now extend into the realm of DevOps. The company announced it will make available an Acropolis Compute Cloud (AC2) and an Acropolis Object Storage Service on top of its Enterprise Cloud OS software that creates an instance of a hyperconverged infrastructure (HCI) platform that can be deployed on-premises or in a public cloud.

    In addition, Nutanix is embedding an App Marketplace in its Nutanix Calm orchestration software through which applications developed on top of Enterprise Cloud OS can be accessed.

    Finally, Nutanix has added Veritas Technologies to the list of providers of data protection software that can be employed to provide backup and recovery software for applications running on top of its core AHV hypervisor.

    Greg Smith, vice president of product marketing for Nutanix, says his company is now moving well beyond simply trying to combine compute and storage in a locally deployed appliance. It envisions organizations employing Enterprise Cloud OS to drive hybrid cloud computing applications across a consistent set of automated orchestration services based on a common platform optimized around an HCI architecture.

    HCI architectures were pioneered by cloud service providers, and Nutanix applied those concepts to local data centers in the form of an appliance. The company then took the software it developed for the appliance to create a portable cloud operating system environment it is now extending with, for example, an object service that is compatible with the S3 interface defined by Amazon Web Services (AWS).

    Smith says Nutanix is making the compute and storage services available on top of Enterprise Cloud OS as an alternative to more expensive compute services based on platforms such as VMware. Nutanix is essentially in a race against other providers of HCI software to extend the reach of its platform. VMware, for example, has made its software stack available on the IBM Cloud and similarly is working to make its software available on AWS. Smith says the Nutanix approach gives IT organizations more control over where they want to deploy HCI software on any platform, including server platforms from Cisco Systems, Dell EMC, Lenovo and Hewlett-Packard Enterprise (HPE) if they so desire. All three of those vendors also provide access to rival HCI software platforms.

    Nutanix developed its own hypervisor on which Enterprise Cloud OS is built to enable its software to be deployed on multiple platforms. But just to make things more interesting from an IT operations perspective, Nutanix also has HCI software that can be deployed on a VMware hypervisor.

    Against that backdrop, IT organizations are trying to determine the rate at which they want to replace traditional rack-based systems with HCI platforms, which combine compute and storage to reduce the total cost of operating an IT environment. Most legacy applications still expect to access external storage. But as new applications are developed, the expectation is that most of them will run on some form of an HCI platform that can scale out to support a much broader range of applications.

    It’s not likely legacy applications running on rack systems will go away anytime soon. But it is apparent that IT operations teams will be managing a mix of rack and HCI systems for years to come.

    — Mike Vizard

  • AT&T Democratizes Acumos Code for AI

    AT&T Democratizes Acumos Code for AI

    AT&T and India IT outsourcing company Tech Mahindra announced that code the companies jointly developed to drive artificial intelligence (AI) applications is being contributed to the Linux Foundation.

    Mazin Gilbert, vice president of advanced technology for AT&T Labs, says the goal of Acumos is to not only democratize access to AI software, but also consume it as a microservice with a standard set of DevOps processes.

    Gilbert says AT&T decided to contribute Acumos to the Linux Foundation because it’s become clear the proprietary implementations of AI platforms will prove to be too difficult and costly to support. AT&T is addressing this issue because it currently has 10 proprietary AI platforms attached to its network and was looking at having hundreds attached within a matter of months.

    Making Acumos available as an open-source project should go a long way to reducing that complexity by providing a standard interface to integrating various AI platforms, says Gilbert. Acumos includes a standard mechanism for downloading AI code from an app store, bringing AI functionality to where data resides instead of requiring developers to load data into a proprietary cloud service to access AI functions. In the case of AT&T, that integration is accomplished via the company’s Indigo software-defined network (SDN).

    Gilbert notes that much of what passes for advanced AI today has been around for decades. Many of the algorithms being used to drive AI applications are now over 50 years old. The only real differentiation is how these algorithms are being combined to drive applications to access enough data to make the algorithms useful. Because of that simple fact, AT&T doesn’t believe giving Acumos to the Linux Foundation represents any major loss of intellectual property.

    As AI becomes more democratized, DevOps teams will manage massive amounts of distributed data pipelines. AI applications require access to massive amounts of data that must be consumed via a consistently applied information architecture. Sometimes referred to as DataOps, the pipelines created by operations teams enable the algorithms embedded in a developer’s application to continually learn about changes that impact the recommendations being surfaced by the AI engine.

    At this point it’s now only a matter of time before every application is infused with some form of AI. In many cases, the front end to those AI capabilities will be a voice-enabled digital assistant trained to optimize a specific processor or answer a broad range of capabilities. Applications that don’t provide these capabilities soon will be deemed archaic. The result from a DevOps perspective should be a massive series of rolling upgrades to infuse AI capabilities into existing applications or replace them with one that provide those capabilities. Regardless of how that is accomplished, without some form of integrated DevOps processes in place there can be no data for AI applications to consume.

    — Mike Vizard

  • IBM Adds Cloud Foundry PaaS to Cloud Private

    IBM Adds Cloud Foundry PaaS to Cloud Private

    As IT organizations are being asked to provision and support an ever-growing number of platforms, they increasingly require an approach that abstracts away as much of that complexity as possible. With that goal in mind, IBM created IBM Cloud Private, an on-premises platform that automates the deployment of a private cloud based on Kubernetes container orchestration software. This week, IBM announced it is extending the reach of IBM Cloud Private to include support for the open-source Cloud Foundry platform-as-a-service (PaaS) environment.

    IBM Cloud Private is designed to be deployed on top of virtual or physical servers, including instances of hyperconverged infrastructure based on software from Nutanix. Michael Elder, an IBM distinguished engineer for IBM Cloud Private, says IBM has developed tools for automating the provisioning of not only underlying infrastructure, but also containerized and legacy versions of IBM middleware such as IBM DB2 databases, the Open Liberty Edition of WebSphere application server and IBM Microservice Builder. In addition, Elder says IBM Cloud Private can be employed to deploy a variety of open-source databases, including MongoDB and PostgreSQL.

    Also available for an additional fee with IBM Cloud Private are a plethora of DevOps tools including APM, Netcool, UrbanCode, Cloud Brokerage, Jenkins, Prometheus, Grafana and ElasticSearch. Regardless of the platform employed, IT organizations should be able to apply a consistent set of DevOps processes to manage either Kubernetes or Cloud Foundry, Elder says.

    IBM is also addressing security issues by including Security Vulnerability Advisor to scan containers and an ability to encrypt all data in flight.

    Elder says many IT organizations will deploy 12-factor applications on a PaaS environment alongside containerized applications running on Kubernetes. IBM Cloud Private is designed to provide a common management framework for managing both environments. However, IBM is not extending that management framework to the IBM public cloud. Elder says the company determined that attempting to create a common management framework for both would result in too much complexity, especially for administrators of public cloud services that require a much more streamlined user interface experience.

    Most IT organizations could, of course, craft their own private cloud. IBM Cloud Private simplifies that process by providing all the pieces required under a common management framework. Rather than spending months putting those elements together, IBM is making a case for an integrated platform that enables IT organizations to concentrate more of their efforts on deploying applications instead of managing infrastructure.

    The debate occurring across the IT industry now is to what degree will container-as-a-service (CaaS) environments based on Kubernetes supplant traditional PaaS environments. IBM, as a major supporter of both Kubernetes and Cloud Foundry, is clearly betting there will be room for both. The Cloud Foundry Foundation recently furthered that goal by adding support for a Kubernetes runtime.

    Thus far, however, the complexity of standing up a PaaS environment has limited the adoption of Cloud Foundry to Fortune 1000-class IT organizations or cloud service providers. Meanwhile, CaaS environments based on Kubernetes increasingly are being stood up by developers and then handed over to IT operations to manage. Given that disparity in deployment models, it may not be too long before the number of CaaS environments simply overwhelm the number of instances of traditional PaaS environments.

    — Mike Vizard

  • Digital Transformation Survey: Help Us, Help You

    Digital Transformation Survey: Help Us, Help You

    The term digital transformation is probably one of the most overused, if not abused, terms in the tech/DevOps world today. Everyone is doing it, but what is it? Is it a synonym for adopting DevOps? What are its effects on you, your job and organization? What does it mean for software development and deployment? So many questions. Actually, they’re only a few minutes’ worth of questions in our new survey, Digital Transformation and Your Organization.

    digital transformation surveyThese surveys really help us understand where the market is, what our readers and community members are dealing with and what we can do to serve them better. You helping us by taking the survey allows us to help you—not only you, but the wider community as well. Your opinion is important and it counts. So please take a few minutes and help us. Take this survey now.

    You still here? OK, if our words didn’t persuade you, let me go one better: We are willing to pay you to take this survey. We will give one in every 10 people who take the survey a $50 Amazon gift card. To be eligible for the gift card, you need to enter your email address in the optional last question of the survey. Otherwise, we don’t know who to send it to. So that is another reason to take the survey.

    We will make the report of the survey findings available as well, and everyone who registers will receive a copy. The survey is open to anyone, so please feel free to share the link with your colleagues.

    Beyond taking the survey, I don’t want to minimize the importance of digital transformation. While for some—especially in our DevOps audience—digital transformation means DevOps transformation, that is not its only use or meaning. For many businesses, just adopting a digital footprint, using the internet as an active part of their business or adopting modern methods, software, Agile methodologies, etc., opens up unimagined new ways of business. At the end of the day, digital transformation may, in fact, be one of the biggest agents of change in our world over the last 20 years.

    We’re looking forward to analyzing the responses and seeing your digital transformation experiences. Please help us help you by taking the survey.

    — Alan Shimel