devopsy.kinsta.cloud

Category: Features

  • Why Open Banking Should Consider DevOps

    Why Open Banking Should Consider DevOps

    There is a craze sweeping Europe, and rippling across the world—and no, I’m not talking about the next British Invasion. Open banking is a trend that’s significantly altering how banks work with fintechs and maintain agility in the global marketplace.

    A main enforcer is PSD2, a piece of EU legislation that sanctions access to personal banking data. It’s resulted in an explosion of EU banks providing public application programming interfaces (APIs) for fintechs to develop with. The implications aren’t limited to Europe; many banks all over the world are looking to PSD2 as a baseline, forcing some tough evaluation of how financial architecture should adapt.

    Banks are also under consumer threat to evolve or get out — a 2016 Accenture study found that 78 percent of respondents would bank with a tech firm such as Amazon or Google.

    As banks transition into savvy software providers due to market pressure, one thing is certain: they must adopt agile software development strategies that streamline the deployment and maintenance of these services. In other words, banks must adopt a DevOps philosophy to maintain a market advantage.

    Open Banking Evolves Bank Architecture

    The bank has become programmable. Many banks are now required to allow third-party authentication and access to payment, account information, fee details and other data. This involves support for various integration methods; SDKs, APIs and OAuth for authentication, as well as documentation, sandboxes and other developer tools. Whether they like it or not, banks are now SaaS providers.

    It should be noted too that open banking is not limited to the European Union. The UK’s open banking standard is the Competition and Markets Authority (CMA), and Australia, Japan and other countries are making similar inroads with regulating banking data. The excitement has also encouraged North and South American players to open up.

    The new bank APIs help bypass traditional methods, saving a ton of time. In an article in American Banker, BBVA noted that online e-commerce system Dwolla was able to slash the typical three-day to six-day deposit time frame using their payment APIs. “We’re allowing that all to occur in real-time,” said Chad Ballard, director of mobility and new digital business technologies at BBVA Compass.

    Letting FinTechs focus on web UI development helps banks focus on their core competencies: banking and authentication. Establishing connections via API-driven microservices is also a safer alternative to screen-scraping.

    Why DevOps for Banking?

    Banking Exchange defines agile banking as “the future of retaining relevancy for banking as a whole.” For open banking to be successful, the platform must be tested, monitored and secured for fintech consumers. Sounds a lot like the hallmarks of quality DevOps practice.

    Popular services Google Maps, Uber, Stripe, Twilio and others have adopted an API-as-a-product mentality. These programs adhere to best practices, iterative feedback and agile development methodologies to excel. Similarly, for banks to remain competitive, they must treat their platform architecture and public gateways with the same tenacity.

    For banks, uniting iterative development with stability testing—essentially the Dev + Ops mantra—for their APIs, microservices and frameworks will go a long way to help reach open banking goals and maintain future regulations on API performance standards.

    A DevOps mindset is crucial to consider early on in the open banking journey, as it can impact how banks address:

    • Iterative development and testing: By tying in iterative development with stability testing, organizations can surpass the time limitation often incurred between shipping versions between development teams and testing teams.
    • Continuous monitoring: Many tools are available to monitor the CI/CD pipeline, helping banks respond to issues and improve uptime.
    • Versioning strategies: DevOps in banking will see the larger picture, working in the REST mantra to build on the scale of decades to avoid breaking change.
    • Transition to microservices: As enterprises dispose old monolithic architectures, bitesize services are arguably more appropriate for modern banking; however, they come with unique caveats that DevOps can address.
    • Collaboration between silos: By pivoting to more point-to-point, collaborative processes, banks can reduce friction to meet the responsive expectations set by FinTech, who are becoming new public faces for banking.

    An end result of DevOps is to increase agility in an organization. Especially for large banks, this signifies drying up the traditional “waterfall” development life cycle known to stigmatize the corporate approval process.

    Case Studies: How Banks Are Utilizing A DevOps Cycle

    Many banks have been vocal about what they are doing to ignite positive technological innovation alongside third parties. For example, Capitol One’s DevExchange recently announced a new initiative called experimental APIs. “They are designed with the goal of getting early feedback from the community around API desirability and design before the product release,” the company noted in a blog post.

    In this experimental setup, operational cues inform development. Getting the two sides to talk and respond to community feedback is paramount for DevOps to succeed.

    For banks to adopt an agile makeup, Manfred Bortenschlager, Red Hat’s director of Business Development for API-based Integration Solutions and API Management, recommends what he calls an “agile integration.” This involves a distributed integration for greater flexibility, containerization for the ability to scale better and managed portals for reusability.

    Another interesting effort is that of CIBC, a Canadian bank that is responding to the open banking movement with a responsive microservices framework the company has developed using open source components.

    What’s evident is that many banks already acknowledge DevOps principles as key for innovation in their sector. Through the the use of iterative testing, innovative tooling and automated workflows, banks can achieve greater operational efficiency.

    Open Banking Must Follow Software Development Practices

    A result of the open banking movement is that banks must keep technological pace with fintech. Especially with regulatory pressure, banks must consider how best to approach new technological initiatives.

    DevOps is a way to mitigate concerns. As a philosophy for uniting technical procedures with responsive operations, it’s a prime strategy for banks to consider when readdressing their technology.

    In defining what “agile” embodies for banks, Steve Williams of Cornerstone Advisors said: “The idea is you need to start taking the management and operations of a financial organization and start adapting some of the things that have made technology companies viable.”

    American Banker echoes this, believing that “banks should be more like software companies.”

    Now prodded by open banking, it’s high noon for luddite banks to embrace contemporary software development practices; that means incorporating DevOps into the open banking agenda.

    — Bill Doerrfeld

  • DevOps Chat: Post-DOES Workshop w/ Gary Gruver & Helen Beal

    DevOps Chat: Post-DOES Workshop w/ Gary Gruver & Helen Beal

    Post-DOES WorkshopGene Kim’s DevOps Enterprise Summit UK is just a few weeks away, June 25-26. While DOES UK this year is shaping up to be a must-see event, there are also some great events taking place around DOES. One is sponsored by Electric Cloud (also a founding sponsor of DOES). It is a post-DOES workshop, featuring classes taught by Gary Gruver, John Willis and Helen Beal.

    The workshop session lineup includes “DevSecOps,” by John Willis, “Leading the DeOps Transformation,” by Gary Gruver and “DevOps Essentials,” with Helen Beal. Helen’s DevOps essentials and Gary’s executive leader workshops are both half-days, so you can attend both. Each of these are great learning events as well as a great way to network with your peers. If you are in London on June 27, be sure to check them out.

    As usual, immediately below is the streaming audio of our conversation, followed by a transcript so you can follow along.

    Audio

    Transcript

    Alan Shimel: Hey everyone, it’s Alan Shimel and you’re listening to a special edition of DevOps Chat. We have three folks on our panel for DevOps Chat today, and each one of them, actually, are really kind of special people to me within the DevOps community. And let me introduce them to you right off. First and foremost, ladies first.

    I want to introduce Helen Beal. Helen of course is DevOps fantastic at Ranger Four. But also, Helen was one of the first people I met in the DevOps community over in London and has been a friend ever since. Also has a position with the DevOps institute – an advisory role at DevOps institute as well. So Helen, welcome to DevOps cChat.

    Helen Beal: Thank you very much, it’s a pleasure to be here as always talking to you.

    Shimel: Thank you. My second guest really needs to introduction in the DevOps community. He has three – count them, one, two, three books around DevOps as well as many years of leading DevOps teams at HP and Macy’s and now consulting for many, many different organizations and helping them with their digital transformations and DevOps journeys, none other than Gary Gruver. Gary, welcome.

    Gary Gruver: Hi, thanks great to be here, nice to be speaking with you again.

    Shimel: Nice to have you here. And then certainly, last but not least – one of my good friends in the DevOps world, he runs marketing at Electric Cloud, which is also of course the founding partner of the DevOps enterprise summit (DOES) with Gene Kim and ITREV– Sam Fell. Sam, welcome.

    Sam Fell: Thank you, Alan. Happy to be here.

    Shimel: Okay, first thing I want to talk about today is we’re getting close to DOES London, which I believe is what? June 25 and 25 over at the O2 in London.

    And I know you’ll all be attending there and of course we can – Electric Cloud is again one of the founding sponsors and we can get all that information over on the IT revolution site. But part and parcel with Does London this year, I wanted to mention two special events taking place on the heels of Does London.

    One is a special post-Does workshop which, Sam, you and the Electric Cloud folks have driven. Why don’t you give us a little background here on what you guys are doing and why?

    Fell: Yeah, great – thanks, Alan, I appreciate that. So Gary – you mentioned, he has had all this experience helping these large  companies with their digital transformations. When we started our user conference back in 2013, Gene Kim came and spoke, Jez Humble came and spoke.

    And we were talking together, we said these are exactly the kind of people – these old horses that are trying to do these transformations that we want to try and attract to a large conference, which is sort of what the genesis of the DevOps enterprise summit. The folks that show up at that show, a lot of them are in a tough spot.

    They know they need to transform. Their business wants them to transform, they don’t know how to go about doing it. And so having a community of people that are available to talk to and learn from, admit mistakes to in a safe way, to know that you’re gonna get advice and counsel, it’s a fantastic show that the team has put together. And you can see by the success of it that the community really embraces it.

    So our thought last year with Gary was why don’t we take somebody who has helped companies with these transformations and go to DevOps enterprise summit and listen to those stories and see what people are going through and then directly after that you get in a room with an expert coach who can say, now, let’s apply that to you. Let’s apply that to your situation. All those stories that you’ve heard, how does that work for you?

    And last year we had just a fantastic time and so we decided to do the same thing this year at Does London. We’ll be doing the same thing at Does Los Vegas in October as well. And it’s just an opportunity for people to really put in practice and make real a lot of the things that they heard at the fantastic DevOps Enterprise Summit.

    Shimel: Fantastic, Sam. And it is, it’s a great workshop. Gary and Helen – before I jump over to you, Sam – I forget I apologize. For people to register for the workshop, what’s the cause? What’s involved? Where do they go?

    Fell: So it’s a heavily subsidized workshop. Helen, the DevOps institute, Gary, John Willis – these guys are giving their time in order to provide this for the community. Electric Cloud is helping to pay for the room and all this other stuff. So the cost is pretty minimal. I think it’s £195.00 for our early bird.

    We don’t have that many tickets eft but there are some tickets. There’s a group rate as well. So you know, non-expensive and it’s an opportunity for you to really rub elbows with people who are always wanting to learn how to do these types of things. And as you mentioned, John, we do have these couple different workshops.

    John Willis is doing Dev-Sec-Ops hands on technical workshop that same day. So we’ve got two tracks that we’ve got set up basically. I don’t want to spill the beans on what Helen and Gary are going to be talking about, but the John Willis workshop  we’re really excited about that. He’s gonna be showing people with a live pipeline how to incrementally improve it. how to bake security into your deployment pipelines.

    And one of the types of things that you can do to enable your teams and your developers to ship secure codes. Fantastic stuff.

    Shimel: Yeah, no, that’s gonna be a great hands on workshop for anyone interested in DevSecOps. We’ll have more info about DevSecOps in a little bit. But first, let’s turn to Gary. Gary – what is your workshop going to be about here?

    Gruver: I think I’m gonna follow your lead. Let’s go with Helen’s first with lady’s first and get to that and I think that’s the order that we’re going in with the day. Why don’t you lead off with Helen and then I’ll follow up.

    Shimel: Chivalry is not dead. Helen – go ahead.

    Beal: Thanks, Gary. So I’m going to be doing the half day DevOps institute course – the essentials of DevOps which essentially kind of what it says on the tin, the fundamentals or the foundation and relevance of DevOps and things like the three ways and coms and how it fits with Agile and IT send and Lean, PK studies, linking it to this integration.

    And continuous delivery. How they lead from one another. So that’s it. It’s a course really for people that are quite new to DevOps and they should expect to leave the course, really with an understanding of where DevOps has come from, why it’s important and what sort of business benefits people can anticipate from using DevOps practice and principles.

    Understanding some of the vocabulary that those of us that kind of live and breathe DevOps are quite familiar with. So things like the theory of constraints and CD and things like that and hopefully with some kind of action plan of what they can take back to their desk the next day and start making some DevOps differences in their own organization.

    Shimel: And it is the DevOps essentials course it’s really sort of a big time version of the full DevOps foundation, which Helen – you were instrumental in refreshing for this latest– I think it’s released three of DevOps foundation?

    Beal: Yeah, it’s very nearly ready. So it’s been updated with lots of additional case studies, we’ve updated things like the surveys too, the latest versions of the state of DevOps surveys. I know there’s another one coming out. I don’t think we’re expecting it for another few months, and actually part of what we’ve been doing this update is following our own principles. So we’re actually aiming for a much more incremental release cycle as we move forwards rather than in frequent big updates.

    I’m sure we’ll all be on board with that. And then, newer things have been coming through like liability engineering and more stuff around services and containers and those sort of things. Focused on safety culture, learning organizations and some of the things that John and Gene can cover in their beyond the finished product audiobook, also featured in there.

    As is some of the material from Nicole’s and Jane’s book – accelerate. And some references to that. And then we’ve removed some of the stuff that kind of isn’t really around anymore in the DevOps World.

    So things like NoOps – think it’s really gone away now. Rocket DevOps has been very overtaken by DevSecOps. So it’s a good solid refresh and hopefully the foundation will be able to keep refreshing it more frequently as this is such a fast changing world that we’re in – this DevOps world.

    Shimel: It certainly is. Okay, that’s fantastic Helen. And I encourage listeners that may be in the London area that week, if you’re near to DevOps or you really haven’t taken any formal DevOps sort of education or classes, you know, listening – goes to Does is a great way to learn from real life examples. But really this is a great class to give you a nice foundation in DevOps. Gary, how about you?

    Gruver: I’ll be doing my executive workshop that I do with most organizations when I go in and work with the executives to really help people put together their plans and figure out how do they approach it. The people that are gonna be at. Does are gonna be hearing a lot of different ideas, and a lot of perspectives on what they should be doing and I’ll hopefully be trying to help them put that in context.

    My big thing I champion is there are different approaches you need to use when you’ve got large tightly coupled systems than you do when you have small teams that can independently develop and qualify and deploy code. We’ll be going through a lot of those differences. We’ll be going through the role of the executive in terms of leading the transformation.

    A lot of this can be empowered if you have loosely coupled small teams but if you’ve got large groups of people who have to work together to coordinate the deployment pipeline in terms of being able to develop, qualify and release as a system, then you need to have the executives playing a pretty active role in coordinating the work across those teams and prioritizing the improvement. So we’ll be going through that.

    How do executives get the team all on the same page? And then how do you get them to a common definition of what they’re gonna go do and agree to that? So my analogy is a pipeline ____ described an elephant feels like most discussions I start with organizations that are starting to go down their DevOps transformation.

    And what I work to is a process and approach to give them a common view of the elephant and get people all rowing in the same direction. And helping people understand that the types of things they can and should do are different for large, tightly coupled systems versus loosely coupled systems. And then we’ll go through and we’ll help them understand where they should really be starting their transformation.

    Which is different for a lot of different organizations. And I feel that starting point is really important, because this is a lot of energy. It’s gonna take a lot of effort to transform how you do software development.

    And you really want to pick the changes that are gonna have the biggest impact on your business first off so you can create that positive momentum. I think if you just go down the path of doing DevOps without picking those things that will have the biggest impact, you’ll start doing it, you won’t see the benefits, and over time the organization will kind of disengage and you’ll lose momentum on your transformation.

    So a lot of what we focus on is trying to highlight those key lynchpins that you can really start making the big differences and how to go analyze that for different deployment pipelines in your organization.

    So it’s really that. I’ll be there. But there will also be a lot of your peers in the room. So it’ll be a good opportunity to take the things that you learned at Does to reflect on them and talk with myself and your peers about what you’re thinking about doing.

    And learning from it. And I would say that I’ve been doing this for a long time, and what I tell people is that just gives me more opportunities to have made the mistakes that you’re gonna make.

    And so if I can help you avoid the mistakes I already made so you can go make some new ones, learn from that, that’s kind of my goal. My experience is this stuff is such a breakthrough for the business that we’ve gotta have more people doing it. But how can we help people best we can so they realize those same benefits.

    Shimel: Excellent. Gary – you know, one of the things I think sometimes people get confused or question is when we talk about this is aimed at executives. It’s sort of a loaded term. In a large organization like a Macy’s, executive might mean CIO, it might mean VP of IT. in other organizations it may mean a director level. Can you give us a better definition or how you define you know, the executive who is gonna get a lot of good out of this workshop?

    Gruver: I think they all will. I’ve done it all the way from the CIO and I do execution workshops down to – to the leaders that are responsible for a tightly coupled deployment pipeline and then some organizations that might be a director or senior manager that’s over development and ideally, it’s nice that you can bring your partners in QA if it’s separate, and in operations if it’s separate. Maybe your security people, maybe your audit people.

    And come together as a team after Does. So if you’ve got a group of people that have gone to it and gone to a lot of different presentations, having them come together on that will be helpful. So this is the group at whatever level in the organization you think will be leading the transformation, or driving the changes. It can be – typically the CIO when I do the executive workshop is more to inform them of their role in it. Then at some level, we get down to a specific deployment pipeline.

    And the deployment pipeline may still be 1000 people if you’ve got a large tightly coupled system, like we had at Macy’s.

    Which requires large numbers of people working together, or it may be small. And if it’s small, you can do a lot of the things that you’ve seen unicorns do. And if it’s larger, the same principles apply but the practices are a little bit different.

    Shimel: Excellent. Yup. Great. So guys, we’ve covered a lot of ground here. Let me do a quick review. Sam, what day is the workshop?

    Fell: The workshop is the day directly after DevOps enterprise summit. Wednesday June 27.

    Shimel: It’s June 27.

    Fell: That’s correct. Right before… DevSecOps days on the 28th!

    Shimel: Yes, and Sam – I will put in our show notes a link to the URL about the workshop and registration. But where is it being held specifically?

    Fell: It’s conveniently located in exactly the same location as the DevOps Enterprise Summit which is the InterContinental – O2 in London. So if you’re in London, very convenient area to get to also. So come on by.

    Shimel: Excellent.

    Gruver: And you don’t have to have gone to DOES or the DevSecOps. If you’re in Europe and you wanted to stop by.

    Shimel: Excellent point. It’s not a pre-req if you’re looking for some good, hands on DevOps training and networking and education, this workshop is a standalone event. It’s fantastic as well. So let’s cover the three different workshops actually being conducted that day though. Number one is we’ve got none other than John Willis himself leading a real hands-on DevSecOps. Is Anders working with John on that one, Sam?

    Fell: Anders will be in there, yeah, he’ll be hanging around. But this is really John’s show. And this is his passion. And he’s driving the technical aspects of this workshop where people are really gonna be able to get their hands dirty with the technology, have a pipeline. Put some vulnerable code through it, and deploy it and then figure out how do we put automated steps in place and how do we sort of put the – get the developers thinking the right way to make sure that that kind of stuff can happen and what are the practices that need to be put in place. So really, for folks who want to try and get that level of specificity of how to do it, not just the high level, interesting, interesting workshop for people.

    Shimel: Absolutely. We’re all hearing a lot about DevSecOps. Gary made reference to DevSecOps. I think Helen did as well. And we talk about this DevSecOps rugged DevOps etc. This is really gonna be hands on. so it’s great whether you’re a DevOps person or a security person. Then we have Helen who is delivering the pre-req 101 DevOps essentials, based on the latest upcoming version of DevOps foundation from the DevOps Institute. And Helen, people who take essentials – do they get any kind of credit or anything towards a foundation or being able to take a certification or anything like that?

    Beal: As you said earlier, it’s basically a cut down version of the DevOps foundation course and that’s a certified course. This isn’t a certified course, so I’m sure if people wanted to follow up with the DevOps foundation, we could sort something out.

    Shimel: Fantastic. And then certainly, last but not least, aimed at DevOps leaders and executives, Gary is gonna be in essence, delivering what many organizations are paying thousands and thousands of dollars for. His course on kind of leading the transformation. That’s taken right from one of your books, Gary. I apologize. But really, dollar for dollar, what a great line up, what a great deal for anyone who is looking for DevOps training and education. I also wanted to quickly before we run out of time here, I wanted to mention that the day after the workshop is the first DevSecOps days in London.

    Again, headlined with John Willis. I think, Helen, you’re speaking there as well. Correct?

    Beal: I am, indeed. Yes.

    Shimel: Give us a little preview, what are you talking about?

    Beal: So John saw a talk I think I did in Belfast or somewhere – maybe last year. It might have been all day DevOps, can’t remember. Anyway. But basically we’ll be talking about DevSecOps engineering as a concept. As you probably know, the DOI at DevOps institute is just about to release a new course for DevSecOps engineering. So we’ll be talking about that role and what the requirements are to be successful in that area.

    Shimel: Yup. And DevSecOps days also promises to be a fantastic day. Sam and the Electric Cloud folks – we’re grateful for your sponsorship. Electric Cloud is one of the sponsors there. I will put in the show notes where you can get more information on DevSecOps days as well. But you can go to DevSecOpsdays.com and that’s the long and short of it right there. Guys, a couple of minutes left, let’s wrap up.

    Helen – beyond all of the great stuff you’re doing with DevOps institute, what any good news? Any new things going on with Ranger Four?

    Beal: One of the nice popular things that we’re doing at the moment is one of my favorite things conveniently as well. Which is our version of Phoenix project simulation game. That we kind of developed with our partner Gaming Works out in Amsterdam. So it’s a one day business simulation so experiential learning rather than classroom learning. We’ve got a free, public version of that coming up in London on the 19th of July. It is quite close to being fully booked.

    But if people want to find me on Linked In or would like to come along, we do have a couple of spaces left.

    Shimel: Excellent. And I’ve done the Phoenix Project simulation game, I love it and I’m sure you guys will deliver a rousing version, highly recommend. Gary, how about you?

    Gruver: Oh, I’m just spending more of my time with individual companies, learning from their journeys and trying to help them avoid the mistakes I’ve made and help them to learn from new mistakes they’re finding so I can help point it out to other people so that people can accelerate their journeys and be more successful. So that’s where I spend most of my time is just coaching different teams that are trying to transform their software development delivery processes.

    Shimel: You know what, Gary – what we should have mentioned though – for maybe folks listening out there who may want to engage your team to help them, where do they get information?

    Gruver: They can just go to garygruther.com – my website. And they can also go there and download a free copy of my latest starting scaling DevOps and enterprise, the electronic copies are there. I self-published that so I can give it away. Authors don’t really make money on books. So it’s out there, so I can give it away.

    If you read the first three chapters and then click at the end, you can get the rest of the chapters if you just give me your name, your title, where you work and where you live so that if I happen to be in the region – I keep thinking I’ll use that as a marketing tool. I haven’t sent anything out to it yet, but I’m still collecting names of the people that read the book because it feels like a good contact for me.

    Shimel: And of course, you’ve updated your privacy regulations to be GDPR. Anyway, Sam let’s see – DOES – you guys are the founding partners of DOES, you’re doing these workshop, you’re helping us with sponsoring DevSecOps days. What are you doing in your spare time?

    Fell: Next week we’re gonna be at Velocity San Jose if anybody is in the area, we’d love to have you stop by and see us. Yeah, we’re just looking forward to seeing everybody out in London. And it’s gonna be a super fun filled week. I mean, it’s a whole week of DevOps. I could not be happier. I’m super excited about it. really appreciate all the work that everybody is doing to try and make this community event a success. And looking forward to being in London.

    Shimel: As am I. I will be at all three of these events as well and you hit it there, Sam. Both the workshop and DevSecOps, these are community events. London has a fantastic DevOps community. Looking for your support, and I think it’s gonna be a great week for DevOps. So with that being said I think we’re about out of time here. Helen – as always it’s a pleasure to hear your voice and have you on the show with us. Look forward to seeing you in person.

    Gary, always a pleasure, my friend. I’m sorry, Helen – I stepped on you there.

    Beal: I was just gonna say, thank you very much for having me on and really looking forward to seeing you guys as well.

    Shimel: Great. Gary – as always, a pleasure.

    Gruver: It’s always a pleasure to get a chance to speak with you, Alan, and look forward to helping out the DevOps community.

    Shimel: Very cool – and Sam, what can I say that hasn’t already been said?

    Fell: I don’t know. You could say “goodbye?”

    Shimel: Okay – in that case, goodbye. This is Alan Shimel. You’ve just listened to another DevOps Chat. See you all in London for DevOps week.

    — Alan Shimel

  • DevOps Chat: The Kitty Hawk Venture & Continuous Testing w/ Aruna Ravichandran

    DevOps Chat: The Kitty Hawk Venture & Continuous Testing w/ Aruna Ravichandran

    A great new book on DevOps is coming out called “The Kitty Hawk Venture.” In the vein of “The Phoenix Project,” it is a novel about one fictional company’s journey specifically with continuous testing. Based on a real-life airline company, the book is great case study and learning experience around continuous testing and its importance to the entire CI/CD and DevOps experience.

    The book is written by Jeff Schaeffer, general manager of the Continuous Testing business unit at CA Technologies; Alex Martin, CTO of Continuous Testing at CA Technologies (and former CTO of Rally Software); and Aruna Ravichandran, vice president of  Gobal Marketing at CA Technologies and author of “DevOps for Digital Leaders.” Beyond the book, there is a companion ebook on continuous testing, as well as other related content.

    In this DevOps Chat, we speak with Aruna, who is a frequent guest on our chats, about the book, continuous testing and the overall DevOps market. It is an excellent chat and, as usual, Aruna’s passion for what she does and DevOps shines through.

    For those not familiar with our DevOps Chats, the streaming audio of our conversation is immediately below, followed by the transcript of our conversation.

    Audio

    Transcript

    Alan Shimel: Hey everyone, it’s Alan Shimel. DevOps.com. You’re listening to another DevOps chat. This is gonna be a really great chat. I have one of my dear friends in the DevOps industry joining us. Aruna Ravichandran Ravichandran, VP of Marketing DevOps at CA technologies. But more than that, now a multi-time author as well as a code engineer and a bunch of other things. She’s had an amazing, amazing life and career. Aruna Ravichandran, welcome.

    Aruna Ravichandran: Thank you, Alan. I am very excited to be here with you today talking about my latest book.

    Shimel: Yup. So it’s a new one coming out, hopefully in July I guess is the current timeline. And it’s called, “The Kitty Hawk Venture.”

    Ravichandran: That is exactly right. So you know, I think we chatted about a year ago when I wrote my first DevOps book. It was called, “DevOps for Digital Leaders.” And what we decided to do based upon the substance of the book is to basically to take a leaf from the Phoenix Project and write this book in terms of a real life story about one of our customers. I can’t name who the customer is. And the book is actually called, “The Kitty Hawk Venture.”

    And it’s a novel about continuous testing in the world of DevOps in order to help customers as they’re going through their digital transformation journey. So it’s not written as a continuous testing handbook.

    But it’s basically a real life example which happened with one of our customers and tells the story of the journey they actually went through in terms of how they actually transformed their testing discipline, lines of automation down to continuous testing and how they actually addressed some of the bigger challenges they actually had internally across the board.

    Shimel: Got it. So Aruna Ravichandran, I promised you and I promise our audience, no spoilers on this. So I don’t want to go too much into the actual story of the book, let’s keep it at a high level and say that it is about continuous testing and it is based on a real life customer experience. Maybe an amalgamation of customers.

    But you know, Aruna Ravichandran, you mentioned your first book, “DevOps for Digital Leaders.” So this is then your second book on DevOps.

    Ravichandran: Yes, it is. But this time I’ve actually focused on one of the emerging disciplines within DevOps. the first book was primarily focused around DevOps as a discipline, some of the challenges customers actually face.

    Where do they actually start. Because you know, there is no hard and fast rule in terms of DevOps. you can start with continuous integration. You could start with continuous operations. Or you could start with continuous testing.

    The book was primarily focused around end to end DevOps and gives some amount of coaching to the end reader on where to start, what’s the maturity model, what are some of the metrics, how do you measure the substance of DevOps.

    It also talks about several different customer examples on the journey they actually went through. But and speaking from that, we saw that a whole bunch of our readers are interested in learning more about an emerging discipline around continuous testing. So this book is primarily focused on continuous testing as a discipline and why it’s a very important area within the world of DevOps.

    Shimel: Yup. Now, Aruna , though, you hear it in your voice when you’re speaking to our audience here – it comes through loud and clear. this whole area of DevOps – continuous testing specifically with the book. It’s something that you are passionate about. I get it, you’re a VP in the DevOps group. You should feel an affinity. But this seems to go beyond your title and your job. It’s truly something you have a passion for.

    The book is almost 200 pages from the early view I saw. You don’t write 200 pages, you know, blah, blah, blah. You’ve gotta have sort of a burning passion. What is the passion that’s driving you?

    Ravichandran: So the passion that drives me is my customers. As I talk to my customers in the DevOps space, I am very passionate about solving customer problems. And as I talk to my customers, especially customers who want to make an impact, who are on their digital transformation journey, what I learned was testing is a discipline which has existed for several different decades across the board, the very first time when this actual code was actually implemented.

    But what you – what I actually found is that people have testing practices. But it’s mostly around islands of automation. Very, very few customers actually are doing end to end testing, which I call continuous testing.

    And even though you have islands of automation, what I actually find is that testing still continues to be manual. I did a poll of a whole bunch of enterprise customers across the board, and I was shocked to find that testing still appears to be 70% manual across the board.

    And given all of the – this is my personal reason for why I am very passionate about continuous testing, because I think that DevOps has gained a tremendous amount of precedent, but if you don’t embed continuous testing as a discipline across the software development life cycle, you really cannot go through DevOps.

    So continuous delivery has a lot of what do you say affiliation with the market. More and more people are getting educated on how to basically go through the CICD pipeline so that it can go from code to production in minutes. But what they realize is that if you don’t have the testing discipline embedded across the SCLC, going through the pipeline doesn’t buy you anything.

    And so that’s why this is a very important topic which I am very passionate about.

    Shimel: I mean, Aruna Ravichandran, on some level it’s almost – and I think I’ve heard you say this, continuous testing is almost the missing link. Right? In the continuous delivery, in the software development life cycle delivery chain. Right?

    For a lot of – you know what I mean? Companies, they focus on configuration management, on CICD, even on security. But that continuous testing is – it’s right there. It’s a lynchpin. The other thing I wanted to just quickly mention about it is continuous testing isn’t just a pre-delivery —

    Shimel: It’s truly continuous.

    Ravichandran: You nailed it. I would 100 percent agree with you on everything you stated. It is the missing link within DevOps. continuous testing is a practice of testing across every activity in the software development life cycle with the hope that you can uncover and fix unexpected behavior as soon as it’s ingested.

    So it’s about embedding testing as a fundamental and ongoing aspect of every activity through the application life cycle, going all the way from requirements down into production, while facilitating the pre-exact mechanisms what happens in the world of DevOps to where you can actually fix the problem throughout the life cycle.

    Shimel: Let me return to “The Kitty Hawk (Venture),” here again if I can for a moment. You mentioned earlier you took a page out of Gene Kim’s Phoenix Project book in that this isn’t similar to other books you’ve written and that I’ve even reviewed. That are your typical sort of business textbooks, right? You follow an outline and a table of contents and it goes. “Kitty Hawk” is more like you say – a novel, I think is the right word for it.

    How does that make it different for the reader? Or the listener if it’s an audiobook? For someone reading the book.

    Ravichandran: Yup. So for example – this book “[The] Kitty Hawk Venture” is actually based on the main character in the book is Leigh Freemark and she’s a senior director for quality assurance at a company called Runway Air. So the vertical we actually chose was an airline company.

    The way this book is actually written is it talks about the journey of what they actually went through from a transformation journey. So they experienced a major glitch in terms of quality and which caused a substantial amount of negative reputation for Runway Air.

    So this book actually walks through Leigh’s journey, the journey of her own personal mission of making quality first as a big part of her agenda.

    And the way this book is written – we have so many technical books which basically come into the market on DevOps and on testing, so on and so forth. So we wanted to basically – we took a leaf from “The Phoenix Project,” and we also took another leaf from “The DevOps Handbook,” which is the second book which was recently announced by Gene Kim.

    So this is basically written as a novel which tells you the journey which Leigh Freemark went through with Runway Air, but at the end of each chapter we give guidance in technical terms, of what was the actual continuous testing journey Leigh actually went through.

    Right? So that’s why I said, it’s written as a novel but at the end of each chapter we also have like a handbook around the continuous testing discipline on what changes people actually need to make in order to fully embrace continuous testing as a discipline in the book.

    Shimel: And even beyond that, Aruna Ravichandran, from what I understand and correct me if I’m wrong, you guys are planning on coming out with sort of an eBook companion to “Kitty Hawk” on “The Definitive Guide for Continuous Testing.” Is that correct?

    Ravichandran: That is exactly right and so we just actually published it and it will be out very soon. It’s called “The Definitive Guide to Continuous Testing.” And here, we walk our users through 11 different disciplines on continuous testing.

    Ongoing all the way on small teams [sound drops] _____ to how basically they can go through the transformation journey on continuous testing. And at a very high level, I walk you through eleven disciplines and you will see that completely in the novel because that was the journey which Leigh Freeman actually went through in the book, is the first discipline how do you basically and it will – the – you know, all of your testers.

    It could be a developer who is actually doing unit testing or it could be someone who is doing API testing or it could be load testing. Or it could be reproduction testing. All testing in production, you need to be able to have your environment set up. How do you quickly virtualize your environment becomes a very important part of the mix.

    How do you basically break on your environment, how do you actually create your environments very, very quickly is one of the first disciplines. The second discipline talks about testing management right? So regardless of what testing you’re doing having the right data at the right time is very critical. So how quickly can you generate your data?

    And given the world of GDPR right now, you know, which basically went into a test in May, people have to be even more critical about generating test data. You want to make sure that your GDP are compliant. And so having the test data at the right time is critical but also being compliant with a whole bunch of mandates out there is even more critical. The third discipline talks about test automation. How do you basically fully orchestrate the application pipeline.

    So that if the scripts actually fail, you can orchestrate how you can actually achieve continuous testing. The fourth one is around pipeline orchestration. This is the backbone. Everything is tied to it. everything must be integrated with your entire automation stream. You need to understand how it works, how to interpret the results and how do you make quick decisions in order to find out which part of testing is actually a bottleneck?

    And this is what we actually call pipeline authorization. The fifth one focuses on the various different competences, right? If you are testing, the world is going more towards an API economy. So how do you actually bring API testing discipline so that you reduce the reliance on UI testing? Especially for business logic testing.

    The sixth one is around performance and load testing. Right? So you can’t think about performance and load testing toward the end of the testing life cycle. You need to think about shifting left performance and load testing so that you can enable development teams to actually think about this much more earlier on.

    The seventh one is the around the new emerging practice around security testing. So this is where everybody talks about DevSecOps, it’s all about shift left security. How do you enable developers to actually embed static code analysis as a part of their unit testing?

    How do you basically get them to think about security testing by making it easy for them? By having it integrated as a part of their ID environments, whether it’s intelliga or it’s xless or visual studios, so on and so forth. So security testing is the seventh one.

    The eighth one is accidents of test driven development and behavior-driven development. So you take the accidents criteria for each user and create that to ensure that those were actually met. Right? So this keeps testing focused within sprints and ensures developers develop what the business actually expect.

    The ninth one is around automated test generation. And this is the activity of manually designing and writing manual tests of automated tests which is the biggest bottleneck.

    They are the computing magazine data surveyed very recently and they asked, which is the biggest bottleneck across your software development life cycle? 63% of the practitioners actually said that testing was a bottleneck. And why was testing a bottleneck? Because it takes time.

    Think about it, you have actually created 200 test cases for your regression suite for a vertical feature you are going to launch. Let’s assume you’ve caught a major defect and you fix the vertical defect, it means that you have to go back and recreate all of your regression text suites.

    And if there was an automated way that you could take your requirements and as things changed in production you can recreate your test suite, that will be a tremendous amount of savings for anybody to actually not have to create the test cases manually which then eliminates the bottleneck which we actually have.

    The tenth one is around requirement engineering. You must include all of SDLC stakeholders into your continuous testing journey. This means finding a better way to communicate and collaborate right from the requirements phase. The earlier one includes requirements engineering into continuous testing initiatives, the smoother that continuous testing journey will be. Because team members will be working with the same understanding right from the beginning.

    And the last but not least – the eleventh discipline talks about feedback loops. This is the heart and soul of DevOps, it still continues to be the heart and soul of continuous testing. These are critical to ensure that you can have successful continuous testing.

    Shimel: Excellent. You know, Aruna Ravichandran, sitting here looking – I want you to talk about quality, I don’t know if we have time. Maybe we’ll do it on another show. But the 11 disciplines, you did a great job laying them out here. I’m just wondering if someone listening says to themselves, oh my goodness, where do I begin? This is daunting. There is eleven of them. What is your advice to someone just starting out, listening in here – do I do eleven at all at the same time? What do I start with? What – do I take the path of least resistance? How do I get started with this?

    Ravichandran: So I break it up into six different areas, so this is a question you get asked for DevOps and you get asked the same question around continuous testing. So if I have to give guidance on techniques on how to actually adopt – it’s also a cultural transformation too.

    So the first one is, you know, you need to figure out a way to improve the relationship between the tester and each developer. So keeping the team small and creating inter-team collaboration makes it very easy to actually report and actually share the results between the tester and developer.

    So that would be one important tactic which needs to be adopted from a cultural transformation perspective. Number two, is like I said, people actually have automation within testing, which is what we call test automation. But they really haven’t automated the whole thing. So I would say continue to make automation a priority.

    So figure out where people are spending a lot of their time – it could be around building a regression test suite, because they tend to be manual. So how do you automate? So keeping that automation mindset is important. Figuring out where you’re spending cycles of your time in terms of doing manual tasks is important. So making automation a priority is important.

    Map out within your SDLC and identify your automation opportunity. Number three is make it small – right? Like get small. Break it down into smaller increments so that it’s easier to test after every aspect of the SDLC. So break down increments after coding. Break it after design. This makes it easier to automate the test and it also makes it much more easy to deploy and integrate as a part of continuous delivery.

    The fourth one is you want to keep track of everything. Use metrics. Start-up criteria. Right? So your defect density rate is high, figure out how can you reduce the defect density rate. Continuous testing is all about immediately identifying if things are working or not. How do you basically rinse and repeat if it’s working, or how do you actually pivot and change if it’s actually not working.

    The fifth one is getting the right continuous testing tools. Tools play a big role. So we talked about also transformation, we talked about processes and practices, and also having the right tools is important. Figure out the tools that help you develop tests and analyze continuously.

    Pick the best of breed tools that work together in a way that incorporates very easily into your continuous delivery environment. Choose tools which have community based support, that have open source plans that everyone shares the challenges and solutions and have interesting and lead to interesting use cases.

    And last but not least, the number sixth one, is develop a system to display your results. So do deep dives into the results, because that shows you that if you have your code not working, where the gaps are. define your KPI and your acceptance criteria and make them quantifiable. Create dashboards to track those KPIs, including a baseline so that you can actually track with the sequence changes. So these are some of the disciplines I always share with my customers as well as my clients.

    Shimel: Excellent. And now with everyone listening on here. Aruna Ravichandran we’re almost out of time, one more question if you have a second.

    Ravichandran: Absolutely. I do.

    Shimel: So I don’t know if we’re letting the cat out of the bag. If you can’t talk about it, politely say so. But you’re about to roll out something we hear called continuous testing academy? Launching this summer?

    Ravichandran: Yup.

    Shimel: So what’s that about?

    Ravichandran: So the key thing – going back to the question you asked, this continuous testing is like an emerging discipline. People want to know what do I need to do, how do I need to start? How do I get there. And so last year I launched the – I saw that there was a tremendous amount of need in the market around JMeter.

    And so I launched JMeter academy in order to basically to provide input to the community so they could actually train themselves on JMeter. But this year, knowing that continuous testing is gaining tremendous amount of momentum, I’m going to launch a continuous testing academy.

    This is going to have a basic module, it will also have an advanced module. And people will actually have the opportunity to go through the entire module and get themselves certified. We’re also going to launch a certification and you will have the opportunity to become continuous testing certified by DevOps institute. So this is our way to give back to the community in order to basically get people understanding on how they need to evolve their continuous testing practice in order to make a bigger impact in the DevOps world.

    Shimel: Excellent, again, Aruna Ravichandran – great job. You are just, I mean, literally, what a dynamo. All over the place. Doing so many different projects. All with DevOps and continuous testing as a theme there. Congratulations and hats off to you. One of my heroes. Anyway, we’re about out of time. Thank you so much, Aruna Ravichandran, for giving us a preview. Once Kitty Hawk is available to the public, I’d love to have you back on and perhaps we can chat more about it, sound good?

    Ravichandran: Yep. That sounds awesome. As always, Alan, it was excellent talking to you. I love your energy, I love your passion. And looking forward to partnering with you more as we basically enable our customers and prospects to continue on marching further along in the world of DevOps.

    Shimel: Well stay tuned for some announcements, we’re working on it. Aruna Ravichandran, I will be in touch. Aruna Ravichandran Ravichandran, a VP product marketing, marketing DevOps, CA technology, multiple times author, and really DevOps enthusiast. Thank you for being our guest on DevOps chats today. We’ll speak to you soon. This is Alan Shimel for DevOps.com. You’ve just listened to another DevOps chat. Have a great day everyone.

    — Alan Shimel

  • 10 Views on What Microsoft’s GitHub Deal Does for DevOps Users

    10 Views on What Microsoft’s GitHub Deal Does for DevOps Users

    The DevOps and open source communities have been in a tizzy all week over the massive $7.5 billion Microsoft acquisition of GitHub. Even as many developers rage on Twitter about the deal and still others are rushing to migrate their repositories to alternative solutions—#movetogitlab has trended heavy this week—for the most part the DevOps community is taking it in stride. As DevOps.com’s Don MacVittie explained, complaining or planning a move away from GitHub solely due to long-held grudges against Microsoft seems pretty counterproductive at the moment.

    He’s not alone. A lot of developers, evangelists, CTOs and other GitHub users out there doing the work that drives applications into production are looking at this as a potentially great thing. Others are more cautious, but at least believe this won’t set the movement backward. We’ve gathered a few thoughts from these professionals to help balance out the dialogue.

    Ensures GitHub Viability

    “For those developers that may be anxious and thinking about jumping ship, I am sure they also must realize the hard truth that for GitHub to succeed moving forward it needed an influx of cash. Inevitably, there would come a point where GitHub would need to start to actually turn a profit, something it has yet to achieve, before it would have to shut its doors. ”

    —Adam Mansfield, Microsoft practice leader at UpperEdge

    Provides Much-Needed Leadership

    “Satya Nadella has so far done a great job dropping the Windows religion to embrace the reality of the iOS, Android, Linux and multi-cloud world, which he will hopefully continue with the GitHub community. By putting Nat Friedman—former CEO & co-founder of Xamarin—in place as a technical CEO, Microsoft is sending a clear message that they’re committed to GitHub and the larger developer ecosystem.”

    —Jyoti Bansal, former CEO of AppDynamics and current co-founder of DevOps platform Harness

    GitHub Champions in Enterprise Have Easier Sell

    “For one, I wouldn’t be surprised if we start to see corporate firewalls allowing access to GitHub now that it’s a Microsoft owned property, and perhaps considered ‘enterprise-ready.’ Microsoft knows how to make products that make enterprise architects feel confident, so their blessing and ownership of GitHub could really encourage social coding within enterprise organizations.”

    —Matt Stratton, DevOps evangelist at PagerDuty

    Net Neutral Immediate Impact

    “Developers should not be anxious about this acquisition nor should they be excited. I honestly think this is an ‘oh well’ moment. Unless Microsoft has some crazy plan to sunset features or support for one vendor or another, everything should behave as business as usual for the foreseeable future. The only thing developers should watch is license fees and terms and conditions. Expect Microsoft to monetize the solution better in the coming months and potentially tie usage into MSDN.”

    —Morey Haber, CTO of BeyondTrust

    GitHub Already Had Its Own Problems

    “GitHub is not strong in this area (DevOps) and never has been; maybe if Microsoft made it easy to deploy to Azure it could be seen as an improvement. As a tangent, GitLab which is now the attractive alternative, has its own CI/CD tooling and can also be self-hosted for free. This is a major advantage over GitHub, and I’m wondering if corporate America will start looking more closely to the FOSS alternative to GitHub Enterprise.”

    —Mitch Pirtle, longtime developer and consultant at SpaceMonkeyLabs, former Tech Fellow at Capital One

    Opens Eyes for About Dangers of Centralization

    ” My hope is that – one way or another – this leads to greater competition, more innovation, and less reliance on any one single platform. I don’t feel that centralization around any one platform is good for the DevOps and FOSS communities. I also don’t feel consolidation to larger companies is a good thing, as it creates conflicts of interest and generally a lack of innovation. This consolidation could result in a more decentralized approach to both software development and DevOps integration, which will hopefully drive more innovation. I think that could ultimately be a positive outcome of this acquisition.”

    —Jeremy Steinert, CTO of WSM International

    Expect Better Integration for More Seamless CI/CD

    “Longer term, I expect GitHub’s integration with Azure to expand substantially, enabling some truly exciting developments for one-click code deployment to a Cloud infrastructure. DevOps for smaller companies will gain easier access to Azure resources. For DevOps as a whole, we will see acceleration of seamless code management within the context of actual deployment to containers. DevOps for enterprise has the greatest potential for improvement with this deal. There will be massive investment in improving developer interactions between infrastructure and code.”

    —Clint Wilson, VP of product management at DigiCert

    Here Come Better Enterprise DevOps Features

    “While I think the development community will have mixed emotions about the news, ultimately this is a massively positive moment for GitHub. GitHub is at the center of the developer community, but as a business, they have faced challenges in reaching the enterprise buyer—something Microsoft is extremely well-versed in. With Microsoft’s resources and expertise, GitHub no longer has to wrestle with the internal struggle of being open to the community and being open for businesses, ie. selling to the enterprise. Assuming it’s kept a separate entity and is not beholden exclusively to Azure, this acquisition gives GitHub the opportunity to deliver the features enterprise DevOps and development teams need.”

    —Tal Weiss, co-founder and CTO of OverOps

    Accelerates GitHub’s Servicing of DevOps Market

    “The new Microsoft is not the bogey of the past — VS Code is great; TypeScript is terrific; Microsoft has not merely accepted open source, but become an open source leader through its GitHub contributions. From a business perspective, I think the deal will pay off. Unlike competitors such as IBM and Oracle, Microsoft not only understands developers, but has a proven ability to sell to the SMB as well as to the enterprise market. Microsoft can probably grow the GitHub business substantially by executing better on GitHub’s existing strategic objectives, such as GitHub Enterprise, without alienating users. It may also be able to create significant value by applying its AI technology and VS Code innovation to GitHub’s enormous corpus of code.

    —Rod Johnson, co-founder and CEO of Atomist and creator of Spring

    Validates Value of What Open Source and Devs Do

    “I think overall this is good for the DevOps movement, and open source in general. It’s a very strong validation of how important open source is not just to open source developers, but also the business world. Developers have a right to be anxious, but there are many viable options for open source hosting in this day and age, so if Microsoft does not prove to be a good steward of GitHub, they have other options. However, Microsoft could very well keep GitHub going.”

    —Logan Abbott, president of SourceForge.net

    — Ericka Chickowski

  • Microsoft and GitHub: The Sky is Not Falling

    Microsoft and GitHub: The Sky is Not Falling

    The consternation seen in some corners of the internet over Microsoft’s agreement to acquire GitHub is overblown and too early.

    For those who don’t follow me normally, I am a developer for Windows, Android and Linux. I am also a user of both GitHub and BitBucket. While I am an advocate, I am more of an IT productivity/tools advocate than a pro/con MS advocate. So pretty much, I am IT. I’ve worked in pretty much every IT environment from developing embedded devices to cell phones to apps for smartphones to a raft of enterprises from financials to utilities.

    Until we know what Microsoft intends with GitHub, it makes no sense to go crazy with plans to migrate away from the platform.

    Oh, I could draw up plans to move my company’s GitHub repositories to BitBucket (or GitLab, or wherever), but honestly at this point there is no reason to do so. We (all of IT) have a limited amount of time available, and is migration away from GitHub the best use of that time?

    I argue that at this point, it absolutely is not.

    Stop. Breathe.

    There are things Microsoft could do that would make my company want to move away from GitHub. I do not expect that any of those things will happen. Or if they do happen, it is because they were going to happen anyway.

    Remember, early rumors of this merger started with, “They were working on joint marketing, and GitHub let slip they needed a cash infusion …” needed a cash infusion. That means something at GitHub needed to change regardless of ownership. You don’t go as long and get as large as it has and need a cash infusion, if you’re doing things right. So change was likely coming, regardless of ownership.

    But until we see what Microsoft has planned, expending energy either complaining about it or planning to move away seems like a bad use of your time. As long as git pull still works, and the terms of service haven’t changed, it is much ado about nothing.

    Stay focused on your customers, and keep a wary eye on developments with regards to all of your back-end tools, but don’t waste energy in potentially unnecessary or fruitless exercises. Think about it, and if it becomes necessary, we can all make careful, planned moves when it’s clear that is the proper course.

    — Don Macvittie

  • How DevOps Replaces the BYOD Mindset

    How DevOps Replaces the BYOD Mindset

    The impasse is clear: users often have no formal way to effectively communicate to IT departments how certain devices and apps are useful for work and should be allowed to connect to the enterprise’s network. Since the debut of smart phones well over a decade ago, so-called bring-your-own-device (BYOD) policies as a potential solution have served as a solution, but have also fallen short for reasons we’ll discuss below. The idea behind BYOD is to allow users to connect their devices in limited circumstances and often without full access to the network.

    BYOD also predates DevOps and serves as one of many precursors for IT and security working more closely with other teams within the organization. This mindset of collaboration that BYOD fosters, of course, is essential to DevOps, said Holger Mueller, an analyst for Constellation Research.

    “The tension between the business and IT really is about scaling an organization’s operations in a way that is both flexible and business-focused,” Mueller said. “Compromise really matters.”

    However, DevOps, in part, can remove the need for BYOD and even replace it from IT jargon. BYOD first came about when IT, operating in isolated silos, struggled with accommodating users who used their own devices for work and, even more worrisome, often connected their devices to the network without permission. This worry is eliminated with DevOps when business, IT operations, QA, InfoSec and development teams, in the spirit of fostering collaboration across the enterprise, decide together what devices and apps are adopted, and then lay the security groundwork.

    “With the advent of more agile and distributed infrastructures, DevOps teams don’t have a walled-garden assumption anymore, which makes BYOD less of a problem in general,” said Siri Oaklander, advanced technologies principal for CloudPassage. “When BYOD started, the concern was these devices represented an unknown inside the corporate walled garden, and now we are not depending on the walled garden nearly as much for security.”

    New Mindset

    Enabling users to bring new devices and apps into the network certainly falls under the culture part of DevOps. Someone in DevOps who is a business team leader might suggest a very useful app or platform the IT department, the developers, and InfoSec readily review and test because it makes good business sense. Again, this type of interdepartmental collaboration is difficult without DevOps.

    For organizations without DevOps, suggested changes from users requesting the IT department accommodate new devices and apps, even when BYOD policies are in place, are often met with hostility, since it means more work with little perceived direct gain for an isolated IT department. Those working in IT, in this context, thus have little motivation to do the legwork to make room for new devices to manage. DevOps, of course, helps to change this mindset.

    “DevOps-style security  completely changes the boundaries and gateways, eliminating a lot of the concerns associated with BYOD,” Oaklander said. “It’s not so much that DevOps directly addresses BYOD as that the security model used in DevOps is far less vulnerable to having unmanaged devices inside the network.”

    Bring-Your-Own-IaaS

    BYOD came into play before the emergence of massive cloud deployments and the monumental shift many organizations have made to the cloud. Then, operations were often exclusively tied to the data center. Smart phones and other devices, once behind the firewall, were connected to the network that ran on on-premises servers. These servers, as well as virtual machines, were the core parts of the business and often mission-critical, noted Ed Smith, product marketing principal, for CloudPassage.

    “Now DevOps teams no longer have to rely on IT for servers either, they simply go to AWS with their credit card and bring their own infrastructure as a service,” he said. “The similar challenges apply here as they did with BYOD: How does the company control cost and risk without slowing down innovation? And there’s more at stake here because these are back-end servers used by many people as opposed to a device with a single user. BYOD happened because business users demanded it to be agile and competitive, and I think we’re seeing the same thing with what may be called ‘BYOIaaS.’”

    DevOps should thus be ready to take advantage of new cloud solutions, as well as cloud-exclusive applications, in ways BYOD would never have allowed.

    — B. Cameron Gain

  • Microsoft Is Acquiring GitHub for $7.5B, Becomes Steward of Leading Open Source Repository

    Microsoft Is Acquiring GitHub for $7.5B, Becomes Steward of Leading Open Source Repository

    As part of its effort to get even closer to the developer community, Microsoft is acquiring GitHub for $7.5 billion. GitHub controls the open source repository that is at the center of millions of DevOps processes and is home to up to 28 million developers worldwide.

    Microsoft CEO Satya Nadella said GitHub will remain an open platform that developers will be able to employ for any programming language to deploy software anywhere. As part of that commitment, GitHub will continue to operate as a Microsoft business unit led by Microsoft Corporate Vice President Nat Friedman, founder of Xamarin who will assume the role of GitHub CEO. Current GitHub CEO, Chris Wanstrath, will become a Microsoft technical fellow, reporting to Executive Vice President Scott Guthrie. Wanstrath previously announced his intention to step down as the CEO of GitHub. The deal is expected to close before the end of this calendar year.

    Nadella said Microsoft is committed to acting as a steward for GitHub rather than making the open source repository an element of the application development business unit.

    Microsoft recognizes that GitHub is the platform through which millions of developers now collaborate, said Nadella. Acquiring GitHub presents the company with an opportunity to get closer to the developer community by providing both the platform they collaborate on as well as the tools many of them rely on to build applications. That’s critical now because as more organizations transform into software companies, those organizations are pouring more resources into application development and workflows than ever, Nadella said.

    Friedman said GitHub will focus on making it easier for cloud service providers to plug their platforms into GitHub, adding Microsoft is also committing to making all its application development tools available on the GitHub marketplace. The company also will make GitHub services available via its direct sales and reseller channel.

    It’s unclear yet how the open source community that relies on GitHub will react to the stewardship of Microsoft. There are plenty of smaller repository options that might benefit from developers deciding to shift their allegiance. Microsoft clearly is aware of the potential downside, which helps account for why Friedman is stressing that any effort to make it simple to integrate GitHub with cloud services would apply to all services, not just Azure. At the same time, however, given its long history of delivering application development tools, there’s probably a deeper appreciation for how GitHub plays to a Microsoft customer base that counts developers as its largest segment.

    On the plus side, Microsoft will become a much bigger advocate for application development based on open source code. The company steadily has been making large swaths of its application development tools available as open source code. Less clear is to what degree it will be willing to embrace open source across its entire portfolio. With more than 2 million commits made to GitHub a year, Microsoft claims to be the largest contributor to GitHub.

    The challenge from a DevOps perspective, however, is not the repository employed to house code, but rather how well that repository fits into a larger continuous integration/continuous deployment (CI/CD) environment.

    — Mike Vizard

  • Microsoft Snaps Up GitHub for $7.5 Billion

    Microsoft Snaps Up GitHub for $7.5 Billion

    Recognizing the role GitHub plays in the larger developer and DevOps ecosystems, Microsoft is acquiring the software development platform for a cool $7.5 billion, the two companies have announced.

    GitHub, the world’s leading software development platform, has more than 28 million users who “learn, share and collaborate to create the future,” according to the press release announcing the acquisition.

    “Developers are the builders of this new era, writing the world’s code. And GitHub is their home,” wrote Microsoft CEO Satya Nadella in a blog post. He noted Microsoft is the most active organization on GitHub, with more than 2 million commits made to projects.

    “Microsoft has been a developer-focused company from the very first product we created to the platforms and tools we offer today. Building technology so that others can build technology is core to our mission to empower every person and every organization on the planet to achieve more,” he wrote.

    GitHub CEO Chris Wanstrath was quick to point out the irony of Microsoft, once a bastion of proprietary software and apps, purchasing a repository for open source code.

    “When GitHub first launched ten years ago, I could have never imagined this headline,” he wrote in his blog. “Git was a powerful but niche tool, clouds were just things in the sky, and Microsoft was a very different company. Open source and business, people said at the time, mixed as well as oil and water.”

    That said, there is a certain synergy between the two companies, he noted. “We both believe that software development needs to become easier, more accessible, more intelligent, and more open, so more people can become developers and existing developers can spend more time focusing on the unique problems they’re trying to solve.”

    Under the terms of the agreement, Microsoft will acquire GitHub for $7.5 billion in Microsoft stock. The acquisition is expected to close by the end of the calendar year.

    Keep checking DevOps.com for updates on analysis on Microsoft’s purchase of GitHub and its potential impact on the DevOps community at large.

    — Charlene O’Hanlon

  • DevOps Chat: Modern Apps in DevOps w/ Andrea Martinez Crawford, IBM

    DevOps Chat: Modern Apps in DevOps w/ Andrea Martinez Crawford, IBM

    Andrea Martinez, now Andrea Crawford, is the CTO for DevOps for IBM Hybrid Cloud. In this DevOps Chat we had a great discussion on what is “modern apps in DevOps,” how to upgrade your legacy apps, what to do if your legacy apps are not upgradeable and what this all means for DevOps.

    Great discussion and as usual, the streaming media audio of our conversation is immediately below, followed by a transcript of our conversation.

    Alan Shimel: Hey everyone, it’s Alan Shimel and you’re listening to another DevOps Chat. DevOps Chat today is going to be a good one. We have with us Andrea C. Martinez who is the CTO for DevOps for IBM’s hybrid cloud.

    Andrea, welcome to DevOps Chat.

    Andrea Martinez: Hey, thanks for having me, Alan.

    Shimel: Thank you. Did I get that all right?

    Martinez: So, I’m mostly known as Andrea C. Martinez but I’ve recently gotten married so my new last name is Andrea Crawford. Different last name but the same cowboy hat. So I always wear my cowboy hat in my profile pics. If you’ve got the hat you’ve got the right gal.

    Shimel: And it’s the right Andrea. Okay. No hyphen – Martinez-Crawford or something like that?

    Martinez: Nah, I’m not that fancy. It’s just Crawford.

    Shimel: I’ve got to tell you I just got back from China last week and I was with my partner Jayne Groll, one of the co-founders of the DevOps Institute, and one of my co-founders there, Jayne Groll, is actually now Jayne Groll-Ray because she’s also recently married and what a mess on the – hats off to you – getting your passports done and redone and what name to use because you know it has to match exactly and all your other IDs – I didn’t realize what a –

    Martinez: Alan, that’s why we get the diamonds in our ring.

    Shimel: I guess so. Yeah, and well-deserved. Anyway, congratulations on your recent marriage but we’re going to talk DevOps and we’re going to talk a little bit about modern applications here today, okay?

    Martinez: Awesome. Sounds good.

    Shimel: Great. All right. So I should mention that we have a webinar coming up on June 28 at 1 p.m. Eastern time on this topic and really this chat is just sort of a lead-in to the full hour-long webinar and that webinar is on DevOps for application modernization and we’ll put the link to it in our show notes here but if you find what we’re talking about today interesting by all means check out the webinar.

    But let’s dive in. So Andrea, let’s talk a little bit about modern applications versus non-modern applications: Do we have archaic applications, are they obsolete applications? What do we mean when we say a modern application?

    Martinez: Yeah, I think to – and by the way, I like your archaic reference there. I think to really appreciate the modern application we really have to understand how applications use to be designed and built not all that long ago.

    So, if I were to go back to the N-1 generation of applications I could make some pretty broad characterizations of how they were designed, built and delivered. So, if we were to like take it back to around the late-Clinton era of post-dot.com boom, world wide web and the internet, you know, that was really becoming the network platform where enterprises were exposing business function and really more of nascent digital economy.

    So some of the characteristics of what I’ll call “heritage applications” were, No. 1, they were monolithic so the applications lived on these things called “application servers,” typically running on maybe like higher end commodity infrastructure – think like X86, power hardware with large amounts of disk and memory, we had big centralized databases and these memory hog application servers.

    So the applications ran inside these app servers and they were fairly monolithic – that means they basically bundled the presentation or the view, the business logic and the data model components all together.

    The second characterization I would say for heritage applications is that they lived on these app servers that resided on these sort of heavyweight operating systems and although at the time Linux was very much on the scene overall. The trust in Linux was not yet solidified so you had these operating systems that were sort of these enterprise, server, big and bold editions of this OS – and it was pretty prevalent, you know? Windows and proprietary Unix based operating systems pretty much ruled the day.

    And, No. 3, the – in terms of the infrastructure on-premises data centers ruled the roost. I mean virtualization technology’s around, we had this notion of logical partitions, L-pars, VMware, virtualization, but it was mostly a hardware OS story, okay?

    And then we had, in terms of looking at the actual heritage applications themselves, we had the rise and dominance of function-rich languages like Java and dot-net because the application server middleware pretty much dictated the language of what an application was coded in, right? So we still have a lot of these skills around today.

    And I think the last characterization of a heritage app was in the way that they were delivered. So we had the waterfall delivery – very sequential, big-bang releases with siloed organizations, dev teams didn’t really talk to the operations teams and having that kind of silo was pretty much the norm.

    So, that’s how I would sort of characterize the heritage applications.

    Shimel: Yeah, dead on for me Andrea. We didn’t talk about this but in my background I had started a web hosting company in those dot-com days and I sold it to a company and started to work with them and we were one of the first big, what they called ASPs, if you remember those days – application service provider – and so this is – we wound up doing the whole IPO and all of that – this is 1997, ’98, ’99, 2000, into 2001 –

    Martinez: Absolutely. Yep.

    Shimel: Oh, they were glory days. We were probably one of the largest Lotus notes, if you – you know,

    Martinez: Yeah, all right.

    Shimel: So, picture this: We’re hosting – we are offering hosted Lotus notes as a service – it’s not even IBM WebSphere yet, I think it was still notes server –

    Martinez: Domino?

    Shimel: No, it wasn’t even Domino. What came before Domino? I mean this is old. And then Domino came out and it kind of rocked our world because it was really a big thing for us. But there’s no – it was on dedicated hardware, there was no cloud, T1 lines were about $1,200 a month, and so you had to deliver it over a T1 line oftentimes – you know, a dedicated T1 line point to point – and then we expanded to PeopleSoft and Oracle apps and stuff like that, and what a disaster. I’ve got to be honest. I mean we went through about $500 million – a half-a-billion dollars in monies raised between the IPO and so forth – but it was hard. It was really, really hard.

    And then we tried to get into the whole custom app kind of hosting with ISVs and so forth.

    Martinez: Oh boy.

    Shimel: So, what you just described I had a déjà vu to my bones and, yeah, I wouldn’t call those modern applications but I think we’ve done a good job.

    Now contrast that, though, with what modern applications are like today, Andrea.

    Martinez: Yeah. So there’s sort of been an inflection point where some pretty emergent things have happened since those days, right? And you know we dealt with all of those issues around the heritage environments and applications. And now all of the sudden if we take a look at what I call “modern applications” today – Alan, you mentioned the cloud – No. 1, modern applications live in the cloud. So these applications leverage the elastic, infrastructure and platform that comes with it.

    When we develop modern applications – you also may have heard them referred to as “cloud-native applications” or “born-on-the-cloud applications” – and really what has happened here is to leverage that type of virtualized infrastructure we’ve started to breakdown the monolith and the applications that run on them.

    So, now we’re taking our bundled model-view controller applications and frameworks and we’re deploying them separately as components and hopefully we’re using architectural styles like microservices so that the monolith becomes broken down into choreographed microservices that can be managed separately, okay?

    So, we have technologies that actually support this today. And so Docker, Kubernetes are some of the technologies that have come on the scene since that have allowed us to have a control plane and an environment to manage smaller-granularity applications which are hopefully services.

    So, the other thing about modern applications that I think is interesting and has fostered the adoption of these microservices and smaller components is the fact that the solution stack has become more and more commoditized, right? And so, when you think about the solution stack of network hardware, operating system, middleware layer and so on, we’re seeing a commoditization of the solutions stack from the bottom up, okay? And that is – the whole notion of cloud computing, right? – We’re no longer concerned so much about CPUs and CPU architecture, you know, X86 versus Power P Series, this or that – it sort of doesn’t matter as much anymore, right?

    And because of that, I think that has also fostered in some cases where critical proprietary software was not necessarily needed for enterprise applications. And so, when you start to break down the monolith and deploy smaller services, you’re isolating your risk because you’re isolating business functions and smaller chunks that are lighter-weight and it’s really analogous to the difference between deploying a 10-ton gorilla and deploying a colony of ants. If one ant dies it’s not a big deal, right?

    But commoditization has even spread to the way that these little ants or microservices talk to each other with the advent of API interfaces and as long as you use rest APIs over HTTP or a lightweight messaging protocol that’s pretty much the lingua franca of modern applications today.

    So, I think there’s probably this notion of componentization and that is actually fed into the notion of polyglot programming, and so enabling modern apps to be programmed in just about any language. So, you’re no longer bounded to this big, proprietary application server; you can program in just about any language, and as long as you can talk – rest over HTTP or send an A-synch message over a lightweight message hub – it sort of doesn’t matter.

    You know, you can be a Java or a dot-net bigot but, hey, the new guy who knows Python and is really good at it, he can get in on the action, too. It’s all good.

    Shimel: Absolutely. So, Andrea a lot of what you – you know, it was more than a mouthful there – and a lot of what you’re talking about really describes DevOps, right? This idea of chunking down stuff so it’s not the monolith, right, and doing small – you know, lots of smaller, little things rather than one large, bigger thing and learning and feedback looping and all of that – I mean this is – it’s DevOps 101, right?

    And to me – and this is – you know, I speak to a lot of people obviously around the world about this stuff – but to me there’s a chicken-and-egg relationship between DevOps and modern application infrastructure, development and deployment as you’ve described. I don’t know if you could have one without the other. I just don’t know which one comes first. But they’re intrinsically linked, right?

    And this is why, in my mind anyway, we need – you know, there’s a special relationship, if you will, between DevOps and modern application and how we do modern applications today.

    Martinez: Spot on, Alan. I mean, when you think about the gorilla versus colony of ants analogy. Think about having to deploy the 10-ton gorilla – it’s typically pretty complicated but there’s a lot of dependencies and release management is of utmost concern – but deploying the colony of ants you’re deploying a lot of little things at different times – so you’re achieving the multispeed IT – if you don’t have DevOps, if you don’t have that kind of automation to do the build, compile, package, test, deploy and you’re doing it intra daily – if you don’t have that automated then your cost case is going to fly out the window.

    DevOps is essential for modern applications. Period.

    Shimel: Dead on. Dead on. Amen. You know, you’re preaching to the choir here, Andrea – we’re DevOps.com – but it really is essential and there is this sort of hand-in-glove type of relationship.

    We are, as I promised you when we started – the time goes so quickly and there’s more I want to cover. So we talk about how DevOps fits into the story on the how and why of modern applications.

    You know IBM has this history now – and as I mentioned to you four or four-and-a-half years ago when I launched DevOps.com IBM was one of the leading advocates for what was kind of the rise of the DevOps community and culture. And then you guys had the garage method, which was really kind of intrinsically again all about DevOps and DevOps ways, if you will – how does all of that fit in to modernizing applications and the way we’re doing it now?

    Martinez: So the IBM cloud garage method is IBM’s opinionated view on how to deliver especially modern applications: It combines Agile, DevOps, Lean and our enterprise-design thinking and sort of rolls it all up into this wonderful burrito of reference architectures, practices and techniques – you know, it’s lunchtime, so I’ve got food on the mind – but it’s basically a way to help our clients act like a startup so that they can achieve the kind of agility that they need.

    So, DevOps is also about organizational and behavioral changes because that’s really paramount. At the heart of our method is culture – how to organize our teams, the collaborative practices, social coding, pair programming – breaking down the silos, right – that’s what DevOps is all about, having product owners sit with the squads, right? – sit with them. You know, DevOps is a behavior story – a tool automation story – and it’s all in the name of enabling business agility.

    Shimel: Absolutely. Andrea, I’ve got another final area I want to click on if you don’t mind. And that is for our folks listening out here – and it’s a worldwide audience at DevOps.com – and I’ve traveled the world doing this, and though we all want to do DevOps we move at different speeds and we’re at different stages of our journey.

    What advice, if we can kind of give blanket advice – what advice around DevOps would you give to our listeners who – and again, Andrea, this is something you’ve probably learned, right? – I wish we all had a greenfield to play in, but we don’t, right? We have brownfields and there’s heritage apps, as you call them, and there’s modern apps, there’s old and new, fat and skinny, ants and gorillas – even burritos – what advice can you give our listeners on how to deal with all of these things?

    Martinez: I think just recognizing that you may have to approach DevOps a little bit differently depending upon whether you’re modern or heritage or even somewhere in-between. Typically DevOps for heritage applications, you’re retrofitting automation in situ, right? So, you’re sort of bringing the automation to the app. Whereas for modern applications, you definitely want to have a DevOps Day One approach, right?

    Because the ability to create a cloud-native application and have the automation in your mind right on day one is critical. But just know that you may have instances where you may not be able to bring a heritage application all the way to modern – you might be somewhere in between Fred Flintstone and George Jetson, right?

    Shimel: Two of my favorites.

    Martinez: But that’s okay, right? I mean that’s real-world. Because it may not be cost-effective to automate everything but that’s all right, you know?

    So I think we can engineer our way through some of this – and there are products out there – you know, you mentioned before that hybrid cloud was really sort of the area that I was focused in terms of DevOps – and we have proprietary products, open source products, we have our Urban Code Deploy, our IBM Cloud Private – that really sort of helps bridge the gap between applications living in this cloud or that cloud – whether they’re modern or heritage there is an answer.

    It’s not cookie-cutter, but we have the piece parts and the emerging technologies on the scene to help navigate.

    Shimel: Yep. Excellent. So Andrea that is important for people to know but where do we go – where can people go to find out more about this?

    Martinez: So I think the first place I would point them to is the IBM Cloud Garage method website – and I’m sure we’ll be providing links as part of the podcast references – but at that site you can definitely find reference architectures for DevOps, reference architectures for microservices in cloud-native development – and one of my favorites – the practices and techniques that we employ with our garage method for automation, tooling and social collaboration throughout the software delivery life cycle.

    Shimel: Perfect. So, Andrea, as I mentioned, the time here it goes so quick. It was delightful, refreshing and fantastic having you as a guest here. I’d love to have you – you know, where else are we going to learn about gorillas, ants and everything else? I need to have you back on the show. We’ll talk off-mic about it, but if it’s not too much – and we’re Florida neighbors – so I’d love to have you back here. But we’re going to wrap it up for this episode of DevOps Chat.

    Andrea Martinez-Crawford, welcome and thank you for being our guest on DevOps Chat today. We will have links to a lot of what you’re speaking about in our show notes, so folks, please take a look at that. But for now, we’re going to call it a wrap on this episode of DevOps Chat.

    You’ve just listened to another DevOps Chat and hope to see you soon everyone. Have a great day. Bye-bye.

    — Alan Shimel

  • Coming Apart in the Age of Automation

    Coming Apart in the Age of Automation

    One of the fundamental tenets of DevOps is that working in closed, departmental silos is counterproductive for creating quality software. Rather, work is done best when groups are composed of members from across the business working openly and cooperatively. Experience shows time and time again that open, multifaceted teams made up of a variety of viewpoints work better than ones that are closed and monolithic.

    Yet, when we move beyond the landscape of DevOps into American society, things look different. In his book, “Coming Apart,” published in 2012, author and political scientist Charles Murray makes the following point: Sixty-three percent of the population of the United States—white Americans—is separating into a two-class structure in which one class enjoys an increasingly stable, healthy, knowledge-driven prosperity while the other experiences declining wealth, health and educational achievement accompanied by a loosening social cohesion. This loss of social cohesion perpetuates the continuing decline. And, there is no relief in sight.

    Murray points out that while class distinction in the United States is nothing new, what is different now is that these two classes exist in silos that are closed and disconnected. While in the these past classes have intermingled, now each lives apart from one another—so much so that the classes have become almost unidentifiable to each other.

    For example, back around 1960, it was entirely conceivable that a CEO of a manufacturing business shared many of the same experiences as the less-wealthy employees of the company. They might go to the same restaurants, watch the same TV shows and maybe even drive the same make of car. Their children might attend the same schools. Today, however, it’s each to his own; shared experience among classes is becoming more rare.

    There definitely was a class system in force onboard the ocean liner Titanic. The well-to-do traveled first class, while the poor went down to steerage. But everybody boarded together, and Leonardo DiCaprio’s pauper character had a slight chance of interacting with Kate Winslet’s wealthy socialite—maybe even fall in love and get and stay married. And, when the ship went down, all aboard were at risk, rich and poor alike.

    Today, the average Joe flies in a cramped seat in economy. The CEO flies private. The economy flier probably has no idea what it’s like to board a private plane, let alone fly in one. The thought of packing a lunch beforehand to save money while traveling is completely foreign to the CEO. Each lives in a world the other can’t imagine. Again, this trend is not reversing.

    What Does This Have to do with Automation and DevOps?

    Tech culture is a prime example of this exclusive segmentation and clustering according to class. The average salary of a DevOps engineer is ~$138,000 a year, which puts the profession in or around the top 10 percent of wage earners. And, just getting hired at most tech companies requires a college degree. This is a self-selecting dynamic. Birds of a feather fly together: People who make six figures tend to hang out with others who make six figures. Likewise, people with college degrees tend to hang out with others who have college degrees. If you’re in tech, chances are you do not know many people in your day-to-day life who had difficulty in school, have worked on a factory floor or smoke cigarettes. When you and those around you make money by thinking, it’s difficult to have empathy for those whose muscles ache after spending each day stocking shelves at Walmart. You just can’t imagine it.

    Intrinsically, such homogeneity is not bad. The cause for concern is that now, once the boundaries are set, it’s difficult to go beyond them. In the past, the prevalence of shared experiences made moving up into that other, affluent world possible. Today, however, it is becoming nearly impossible. And we in tech are not making it easier. Why? One reason is automation.

    Automation replacing human labor is nothing new. It’s been going on since before Otis figured out how to make elevators go up and down between floors without requiring human intervention. Yet, this is simple stuff by today’s standards. As automation becomes more sophisticated, the degree of smarts required to work in an environment in which automation prevails grows. An engineer capable of refactoring a piece of software that does speech-to-text transformation has had significantly more education than a stenographer—which, by the way, is a profession automation is replacing.

    Automation is making it more difficult for those with only a high school education be employed. Yes, some sources claim that automation will actually create more jobs. But, how many of these new jobs will require nothing more than a high school diploma? And, once hired, how long will these new jobs be available before they are replaced with another piece of automation?

    Now, combine this trend in automation with Murray’s assertions about the growing extreme in class separation. One group is happy, healthy, pretty wealthy and productive. The other group stagnant, poorer, in ill health and continually being replaced by automation. Add in another troubling statistic: The rate of divorce in the happy, healthy, well-educated group is going down. The divorce rate in the other group is going up. (Page 146, Coming Apart, Murray) In addition, the number of single parent households among the less educated group is increasing, while the rate of single parent households for the happy, healthy, wealthy group remains low and substantially less than the other. (Page 159, Coming Apart, Murray). One group has the stability necessary to promote health and wealth in its offspring. The other group is barely keeping its head above water with little hope for better life now, and for generations to come.

    What does this mean? It means that things are coming apart.

    Probably one of the most important lessons we’ve learned in DevOps is that open systems, genuine accountability and blameless reflection combined with a cross fertilization of ideas between different groups makes for a better, more productive work environment. This thinking can and does go well beyond software. Anybody who has experienced the waste and frustration of a closed, siloed organization understands that open is better. We in DevOps understand the the smarter we all are the better off everybody is. Sharing knowledge and expertise is not a zero sum game.

    According to Murray, we are no longer all passengers on a common ocean liner. Today two ships are sailing side by side. One has an able crew with enough supplies and lifeboats for everybody aboard. The other sails along somehow, with dwindling resources and a few lifeboats. We in DevOps are are snug and secure in the first ship. For those in the other ship, the clock is ticketing and the ship is taking on water. Those of us who care about the Big Picture understand that things need to change, that we need to come together rather than come apart. The question, how? This is the question I will leave to you to answer.

    I look forward to reading your ideas about how to bring us together in the comments section below.

    — Bob Reselman