Category: Features

  • The 5th Industrial Revolution: When It Will Happen and How

    The 5th Industrial Revolution: When It Will Happen and How

    Industrial revolutions have always dominated and changed the world in a big way. The first one happened way back in 18th century, and the second industrial revolution occurred almost two centuries later, in the 20th century. The third one happened only a half-century later, while the fourth one was observed within three decades. By the speed these transformations are occurring, a fifth industrial revolution is already around the corner.

    The next technology revolution will be faster and more scalable, and will be adopted by a lot more people as compared to the previous ones. Everyone on the planet will undergo a “personal” revolution by the kind of technology at their disposal. 3D-printing, wearable technology, robots. driverless cars … everything will be readily available and will make lives simpler and faster. With every industrial revolution brought a substantial increase in the GDP, and lifestyles improved manifold. The next revolutionary technology, however, does not aim to simply improve the lifestyle or help people make more money; rather, it focuses on the higher form of intelligence. Now humankind is ready to take the big plunge and step into space. With ideas such as SpaceX and affordable space travel, a future that we cannot imagine today might be possible tomorrow.

    The definition of industrial revolution includes the use of sophisticated machinery to make the work of humans easier and faster. Today, that includes robotics, machine learning, artificial intelligence and a lot more things that nobody could think would become a part of industrial revolution someday.

    In future, we can only expect technology to become more superior and sophisticated in every sense: augmented reality, big data, virtual reality, artificial intelligence and the most disruptive one—cryptocurrency—are a few to name. Cryptocurrency is something so revolutionary that it is making news every day. Bitcoin’s price is touching the sky and investors of cryptocurrency believe that the prices are sure to touch the moon in coming years. With the number of people investing in cryptocurrency and people holding on to their alt-coins, one thing is sure: A fifth industrial revolution has “already” arrived.

    Industry not only runs on machinery or ideas, but also on money. Today, people are spending their hard cash and fiat currency to buy cryptocoins, including Bitcoin, Ethereum, Litecoin, Ripple, Monero, Dash, Golem IOTA and even tokens (ICOs). A popular crypto-exchange claims it adds more than 30,000 new user accounts every day—a number not to be ignored!

    It is true, cryptocurrency currently is not regulated or controlled by any government, but it’s possible governments could impose taxes on the income generated from it in future. There is still much to be worked out in making cryptocurrency a validated form of currency. But even high-end investors such as Warren Buffet claim cryptocurrency is here to stay, and it is indeed something that will bring a bigger revolution than expected.

    The Fifth Industrial Revolution is poised at the cusp of a future in which things considered unimaginable today become the norm, and concepts such as universal basic income (UBI) help ease the sting of automation and mass unemployment. Mankind is ready to take a step forward.

    The world currently is in a disruptive stage, as the fifth industrial revolution unfolds to impact our lives—for better or for worse. Now we wait and observe what the future has in store for us.

    About the Author / Emma Rundle

    Emma is a professional content writer currently providing her freelance services to Edubirdie. Emma’s favorite topics to cover include business, software, high tech, and web development. She has a Master’s degree in Economics from The University of Texas at Austin. Follow Emma on Twitter.

  • Making Software Maintenance Cool Again with DevOps

    Making Software Maintenance Cool Again with DevOps

    What makes DevOps so important? Part of the answer lies in how DevOps encourages more appreciation for and investment in software maintenance.

    Traditionally, the IT industry has been like the construction industry. People who design new things (architects or software developers) are at the top of the value hierarchy, whereas the folks who build and maintain them (construction workers and IT Ops admins) are not held in such high esteem.

    This isn’t to say people hate admins, of course (or construction workers, for that matter). What I mean is that the work of building and maintaining tends to be seen as less creative and exciting—and ultimately less important—than the work of designing new things.

    This is why software developers in the pre-DevOps world got most of the glory. They created new code that did exciting things.

    Meanwhile, admins on the IT Ops team were stuck deploying and maintaining that code—and occasionally cleaning up messes created by developers who wrote bad code. Admins were also the first folks to take the blame when something went wrong.

    This isn’t to say that developers cause all the problems, of course. Some mistakes can be attributed to admins. Others are the result simply of poor communication between developers and admins.

    Still, in general development work—which involves creating new features and innovations—was what was celebrated. Maintenance work performed by IT Ops was less glorious.

    DevOps and Software Maintenance

    One of the most important—yet also most underappreciated—results of the DevOps movement is that it has made software maintenance cool again.

    In addition, DevOps provides more organizational support for maintaining software, while also facilitating the type of communication between developers and admins that leads to better maintenance.

    DevOps does this through principles such as the “you build it, you own it” mantra, which stipulates that whoever writes code is also responsible for deploying and maintaining it.

    Even if your organization doesn’t adopt that particular DevOps practice, it probably still seeks greater collaboration between developers and IT Ops. As a result, when something breaks in production or needs to be upgraded to maintain reliability, developers are involved, too.

    Celebrating Software Maintenance in DevOps

    Despite the emphasis that DevOps has brought to software maintenance in practice, you still don’t hear a lot of talk about maintenance work in the DevOps world.

    In essence, coding is still seen by many people as the coolest type or work that is done in the DevOps world. What DevOps has done is break down the silos separating those who code from those who maintain. It hasn’t necessarily made maintenance itself the object of more excitement.

    It may be time for that to change. Forward-thinking organizations should recognize that software maintenance—which includes tasks such as applying updates, monitoring applications and scaling host infrastructure—is just as crucial for a seamless application experience as the applications themselves. This should become an explicit part of the DevOps conversation.

    — Chris Tozzi

  • When is Big Automation Too Big for Comfort?

    When is Big Automation Too Big for Comfort?

    There’s a joke traveling around the tech-o-sphere that goes like this:

    How many software developers does it take to change a lightbulb?

    Answer: None, it’s a hardware problem.

    In the world of modern DevOps, physical infrastructure has been abstracted to code. I can count on my fingers the number of people I know who have done a physical memory upgrade in the last year. Fortunately or unfortunately, depending on your outlook, I am one of them. Nonetheless, for the most part, hardware left the building a long time ago, no pun intended. All that remains is the laptop we use to move the bits around.

    However, for those who don’t sling code, the world of automation is much bigger than our software-centric view. Most of us are aware that today there is hardware that can roam around our living room unassisted and vacuum up dirt from the floor. There’s 3-D printing, which is a technology my dentist uses extensively to fabricate crowns in the privacy of a closet next to an examination room in his office. And of course, the driverless car and truck is predicted to soon be a regular part of our day-to-day landscape.

    But, this is the small stuff. There’s a lot of hardware automation that goes well beyond the dimensions of consumer appliances and room-size automation technologies being used in factories. In fact, machine automation is becoming gigantic, as in Godzilla-size, particularly in mining.

    Mining: Let’s Eat a Mountain

    Equipment has been essential to mining since the first days when a man was sent into a cave with a pick and shovel to extract ore. Mining has come a long way since then—today, it’s a gargantuan undertaking that has become more incredibly machine-intensive. Whereas, in the past, we’d send men into a shaft in the ground to get the goods, these days, we just let a machine eat the ground, literally.

    The Bagger 293, shown below, is a bucket-wheel excavator. The 315-foot-high machine can dig a 8.5 million cubic feet of earth per day.

    bagger-293

    The Bagger 293, with a height of 315 ft, is taller than the Statue of Liberty

    To give you a sense of how big this whole operation is, first understand that, 315 feet, the height of the machine, is approximately the equivalent of the height of the Statue of Liberty, from ground to torch top. The amount of dirt that the machine can remove in a day is equivalent to digging an eight-level sub-basement beneath the floor of the Roman Colosseum. The Bagger has been in use since 1995, and no matter how you cut it (again no pun intended), that piece of iron has eaten a lot of dirt.

    Presently, the Bagger requires a crew of six to operate. But, if trends keep steady, it’s only a matter of time until machine excavators of this size can operate autonomously.

    Sound far fetched? It’s not, really. The Komatsu AHS already has a mind of its own.

    The Komatsu AHS is an autonomous earth-moving vehicle that can move a payload of 290 tons. The machine is the size of an average house.

    komatsu AHS

    The Komatsu AHS (right) is an autonomous earth moving machine

    In the past, it would have taken a small army of men weeks, if not months, to mine raw materials. Today, using technologies such at the Bagger 293 and the Komatsu AHS, the work can be done with a workforce of six. And, in the not-too-distant future, the work will require no human intervention whatsoever.

    So we’ll have machines that can get massive amounts of dirt out of the ground and move it around without the need for any human intervention, But, once mined, where does it all go?

    Hold that thought. The answer is coming.

    There’s More to Container Automation than Kubernetes

    Yara, a shipping company out of Oslo, Norway, in partnership with Kongsberg, a maritime engineering group also out of Norway, has created an autonomous container ship, the Yara Birkeland, that is set to hit the high seas in 2018. This ocean-going vessel will be manned by a crew of none. It’s completely driverless.

    Yara Birkeland

    The Yara Birkeland, to be completed in 2018, is a zero-emission, autonomous container ship that is estimated to remove up to 40,000 truck journeys

    According to the Bureau of Transportation Statistics, more than 19,000 vessels entering U.S. ports in 2010 were container ships. That’s 31 percent of total maritime activity on American docks that might very well see the elimination of seafaring crews.

    Container shipping is useful because it allows for the easy transport of goods from a variety of shippers. In the past, dockside longshoremen loaded individual bails, crates and barrels into the hold of ships by hand using winches, conveyors and stackers. Container shipping made it so the shipper loads a container and then a machine loads the container onto the ship like stacking Legos. One human does the work of dozens.

    Mining transport does not have the burden of having to accommodate a variety of goods in different sizes and shapes. There is only one product: raw ore. Thus, it’s quite conceivable that an autonomous container ship, maybe one the size of four soccer fields, can be repurposed as a giant, seagoing container holding nothing but a single product: unprocessed ore.

    So, let’s look at the dynamics of the supply chain overall. In the not-too-distant future, a machine will roll up to a mountain. It will start to eat the mountain, spitting out dirt one gigantic mouthful at a time into the bed of an equally gigantic, autonomous dump truck. And that dump truck will unload its contents into the hold of an autonomous, seaworthy vessel that very well might take the contents to an automated mineral refinery for processing.

    Those of us who have had to change a lightbulb recently understand the implications. They’re profound. Those of us still trying to figure out how to program our smart home to do the light bulb-changing might need a bit longer to catch on. But, the notion remains: If we can create a machine the size of a building to act on its own, how long will it be until we are creating building-size data centers that can act on their own? Automation on such a gigantic scale is not only possible, it’s inevitable. Controlling an out-of-control home vacuum is one thing. But, what happens when something on the order of a Bagger 293 goes beserk?

    I don’t know. But I can guarantee you that it will not be business as usual. The good news is that the Bagger only moves at about a mile and a half a day. But still, if it learns how to speed up, then might we one day wake up to find our favorite hiking hill gone due to the whims of an independent intelligence that cares not or knows not of our love of nature? What then?

    As they say in the terrain, forewarned is forearmed.

    — Bob Reselman

  • 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 DevOps.com 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 DevOps.com 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 DevOps.com 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 DevOps.com 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 DevOps.com 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 DevOps.com, 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 DevOps.com 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 DevOps.com 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