devopsy.kinsta.cloud

Author: Alan Shimel

  • DevZone and Bluemix Garage @ the IBM InterConnect Expo Floor

    DevZone and Bluemix Garage @ the IBM InterConnect Expo Floor

    Things have been so busy here at devopsy.kinsta.cloud, I have not really had a chance to report on what a great event IBM InterConnect 2017 was. Once again this year this year the IBM InterConnect expo floor showcased the latest developments in cognitive, cloud, DevOps, security and more. But this year there was definitely a vibe of DevOps, agile and cognitive are now firmly mainstream and not just the latest shiny objects.

    We have over 40 videos of interviews and updates from this years InterConnect over on our DevOps TV Youtube channel. Included in this playlist are some great interviews with Jeff Sussna, John Comas of NBCUniversal and more.  Check them out if you have some time.

    For this article though I wanted to give you a flavor for what it was like on the expo floor at InterConnect 2017. We took our video team mobile and toured several of the areas that the floor was broken into. Two of the most crowded was the Dev Zone, that featured development trends across many areas and the IBM Bluemix Garage which was expanded this year.

    Over at the Bluemix Garage area we had a special tour guide Bluemix Garage CTO, Rachel Reinitz as well as some of her friends.  This video is pretty long, almost 30 minutes, but it really captures everything that is happening with the Bluemix Garage including some new offerings and some of the design thinking that is shaping a lot of what is happening at the garage.  Have a watch below:

    While the Bluemix Garage was all things Bluemix garage, the DevZone was some of this and some of that. It had some Watson stuff, lots of automation and more. It was broken into two main areas.  One was hands on working on laptops in a lab type of area. The other parts of the zone were more exhibits of some of the cool things being done with IBM dev tools.  Robots, beer, food and lots of other good stuff.

    Again we were lucky to have a VIP tour of the DevZone from Brian Bryson and some special guests. Have a watch of this and get a great sample of what it was like on the DevZone as they served up “steak and sizzle”.

    If you like these looks at the show floor, be sure to check out our tour of the Watson area and the DevOps and ITSM Zone from the expo floor.

    We will be following up with a few more articles highlighting some of the other great videos from InterConnect 2017 in future articles, but you can check them all out now here.

    — Alan Shimel

  • DevOps Chat: Hiscox CTO Jonathan Fletcher

    DevOps Chat: Hiscox CTO Jonathan Fletcher

    Our guest on this DevOps Chat is Jonathan Fletcher, CTO of Hiscox. Jonathan will be quick to tell you that he is actually “interm” CTO. But as I told him in our Chat, if Hiscox is as sharp a company as I think it is, it will make that title permanent soon. I have known Jonathan for about 3 years or so now; I believe it was at a Ranger4 event in London where I met Jonathan. It was readily apparent to me that he was the driving force behind Hiscox’s impressive DevOps transformation.

    Jonathan is on the program committee for this years DevOps Enterprise Summit London. We spoke a bit about what it is like to be on the programing committee for DOES. We also spoke about what he is presenting at DOES. You will have to listen or read along to find out.

    As usual, the streaming audio is directly beneath, with the transcript of our chat below that. Enjoy!

     Audio of our Chat with Jonathan Fletcher

    Transcript of the chat with Jonathan Fletcher

    Alan Shimel: Hey, everyone. This is Alan Shimel, devopsy.kinsta.cloud, here for another DevOps Chat, and I’m very happy to be joined by our guest for this DevOps Chat. It’s Jonathan Fletcher, CTO of Hiscox. Jonathan, welcome to DevOps Chat.

    Jonathan Fletcher: Hi, Alan.

    Shimel: Great to hear from you, Jonathan. I probably haven’t spoken to you since, oh, maybe DOES London of last year, which was also in late June and –

    Fletcher: No, that’s right.

    Shimel: Yep. Since that time, looks like you’ve got a new title over at Hiscox. Is that correct?

    Fletcher: That’s right. Interim at the moment, but, hopefully, that will develop into a permanent role in the not-too-distant future.

    Shimel: Well, if they’re smart, they’ll make you permanent.

    Fletcher: A CTO office.

    Shimel: Yep. Excellent, John.

    Fletcher: Yeah, I think you’re quite right.

    Shimel: And well-deserved.

    Fletcher: Yeah

    Shimel: Well-deserved.

    Fletcher: Thank you.

    Shimel: So, Jonathan – excuse me – Jonathan, I wanted to speak to you today, though, a little bit about the upcoming DevOps Enterprise Summit London 2017, which is June 5th and 6th, at the QEII Conference Center in London. And you’re actually one of the speakers lined up for the event. That’s correct?

    Fletcher: That’s right.

    Shimel: And, Jonathan, can you – I don’t know if it’s too early or not, but can you give our audience maybe a little bit of a preview of what you’ll be talking about?

    Fletcher: That’s a good question [chuckles] and I’m not sure really sure yet. I think what I’m gonna be talking about is a little about a continuation of our journey, particularly about moving to cloud and what that means, the business results that can be found from doing that, along with sort of where we started and how that changes the IT organization. ‘Cause moving to cloud isn’t just a move of technology; it’s change in skills; it’s a cultural change. It changes things that I hadn’t really thought about, a way we budget, I mean, in fact, from a legal compliance teams. It’s a real transformation program for us. I kind of keep (saying) that savings isn’t IT 1.1; this is IT 2.0. This is a new IT department. So I’m really excited to kind of talk about that. We’ve got a long way to go ourselves, but seen some good early signs with cloud adoption, so I think that’s where I’m gonna focus my time.

    Shimel: Fantastic. And, Jonathan, of course, in addition to your speaking role with DOES London, you’re also on the – is it called the “speakers committee”? Is that what it’s called?

    Fletcher: Yes, right, programming committee.

    Shimel: Programming committee. I’m sorry. Jonathan, can you – our audience, the overwhelming majority of them have not served on the program committee. Can you give us a sense of what is involved in that?

    Fletcher: So there are dozens and dozens of people who want to come along and share their story next year, so the program committee really is around trying to filter some of those down – not everyone can come and talk – and trying to make sure they are as much relevant to the audience that’s coming, so I think it was worth reimbursing in last year.  it was real stories from people doing transformations at real enterprises, and not unicorns, not ace, but is this a real bank, real insurance company, real companies with a legacy of acquisitions and different types of IT, different technologies, and hearing about how they’ve got on and what they’ve got to do in the future, so that’s really powerful. So program committee’s trying to turn a number of – dozens and dozens of submissions to the program down into a really good, tight sets to deliver over two days in June.

    Shimel: I got it. And, Jonathan, I don’t know if you even know the answer, but can you give our audience a sense of how many submissions versus how many speakers are actually selected for an event such as DOES London?

    Fletcher: So I’ve seen a bit of pre-filtered list, so I couldn’t speak on Gene’s behalf how many there were, but I’ve seen hundred – in the hundreds, I guess. And I think that’s down to 30-something; again, I don’t wanna get the numbers wrong, get the (incorrect) stats, but it’s significant amounts and significant amounts of people that Gene has conversations with, I guess, _____ _____ _____ _____ get through to a formal submission, so it’s very significant, which I think is a really good thing. Obviously, people are seeing a value in DOES London and wanna come share their stories, so it’s a shame not more people can do it, but it’s only those two days.

    Shimel: Yep. Absolutely. You know, and I have some ideas around that I’m gonna talk to Gene about. But, Jonathan, was there any – obviously, the DOES, the Dev-Ops Enterprise Summits, traditionally focus on large organizations, “horses,” as we call them, telling their transformation story. And some of these stories we’ve now seen and followed over multiple years and we’ve seen that transformation evolve. Were there any particular themes or things that the committee wanted to really bring out for this year’s event?

    Fletcher: I think it’s lot of different things. I think a – in terms of sense of continuity between last year’s and this year’s, so what are the results that we’ve seen, in terms of transformation and – that seems to be a bit of a theme. To share that continuity _____ _____ years is quite an interesting thing to look at. The theme, obviously, is try and – the _____ tend not to be technically focused, so we don’t have too many groups talking about technology, more about the people and process of things. So I think a lot of what you’ve heard last year, the same kind of thing, but, hopefully, just seeing people a bit further along the journey, where they’re going to and the challenges that they’re running into.

    Shimel: So, Jonathan, this – you know, I’m gonna attend this year’s DOES London event, and this will be the, man, the fourth or fifth DOES that I’ll be attending. And, though I think I’ve come to – I think all of us have come to appreciate hearing the transformation stories of these various organizations, bigger picture, in order for DevOps to continue to grow, right, what else needs to come to the forefront at conferences like DOES, other than “Hey, we tried to do this DevOps thing and here’s how we’ve done”? Do you think at some point we need to hear more than that around DevOps?

    Fletcher: Sorry, what do you mean?

    Shimel: So, in other words, at this point in the game, depending on who you believe and who you listen to, a majority of enterprises have at least dipped their toes in the DevOps pool, if you will. Not many of them have undergone an enterprise-wide transformation, but at least they’ve started along their way. What more – so, in other words, what is there beyond the “We’ve tried to transform the company” type of lessons that the DevOps community needs to learn from these events? Or maybe there is nothing more.

    Fletcher: That’s a good question. Well, I don’t know. It’s a difficult question to answer, really, ’cause it depends on the strategic direction for those companies and how far they need to push the barrel. I mean, not everyone needs to release 400 times a day _____ _____. You know, the different companies got different requirements. And I think, really, DevOps is such a all-encompassing term now that it’s kinda lost its meaning. If your company is about improving quality or that’s your strategic goal, rather than the pace of change, there are different things for different people, so dipping your toe in the water is fine. I think DevOps is for everyone, regardless of scale of company, so those focused on enterprise, well, that doesn’t mean that, if you’re a small shop, that’s not relevant to you ’cause it is.

    I think, really, it’s such a wide topic that seems to encompass Agile and Lean and technology and people, and it’s so vast in topic that, actually, the next step for people in the transformation program ought to stop worrying so much around necessarily what other companies are doing. The war stories are good, but it’s focusing more on what that really means to your company. It’s no longer about DevOps transformation; it’s about business success transformation and what you need to get to get you there. So I think a bit of maturing thinking from companies that started on this program is really actually what they tried to achieve and where they need to get to because I think there’s an assumption between certainly some people aspect where it’s all about Puppet and getting 4,000 releases out the door, and that’s not always the case. So _____ _____ big business goals and I think really trying to realize some of the results so that the business benefits ’cause we’re doing this not because it’s cool and it’s _____ cool IT; it’s because there’s tangible business benefits in doing it. And I think that’s really what the community needs to focus on and _____ –

    Shimel: Yep. And I think you’ve — Jonathan, I think you’ve hit that right on the head and that’s just what I was looking for, which is so many people, especially in the IT industry – I don’t know what it is about the IT industry, but we suffer from “shiny trinket” syndrome, right? Where everyone wants to latch onto what the new cool thing is. And the risk you run is that, when the luster is off of the trinket, people tend to start looking for the next trinket, instead of doing what makes sense for the business, what’s best for the business. You know, ’cause to my mind –

    Fletcher: Yeah, exactly.

    Shimel: Right?

    Fletcher: It becomes a – go ahead. Sorry.

    Shimel: No, no, go ahead. I’m listening.

    Fletcher: Yeah, it becomes a little bit of a statistics race, like, “How fast can I get a release out the door? How many servers can one person look after?” And, actually, that’s fairly meaningless, unless there’s a business benefit behind it, so that sort of arms race to be the fastest becomes less and less relevant, so. And, as I said, DevOps is such a wide term now that it kind of – it’s just about doing IT better.

    Shimel: Yeah. And that’s exactly it. I mean, Jonathan, to me, in my many, many years in IT and in business, there’s very few revolutionary things. There’s more evolutionary type of developments, right? And, when we look at DevOps, we look at the Agile that came before, right, and we see kind of where Agile is and its effect, but yet we still see plenty of organizations that are doing waterfall or some may call it “fast at waterfall” or “Agile waterfall” or whatever you wanna call it. But, you know, it’s a very – the inertia in our systems is such and entropy in our systems is such that nothing moves – we don’t move at the same speed across. And even something like DevOps, though you may have organizations that are now presenting for the third or fourth year at a DevOps Enterprise Summit, there’s still plenty of organizations that are still just starting on that journey, and they will be on that journey for many years going forward. And I think we lose perspective of that when we live in this bubble of “Who’s releasing the most often? Who did this first? Who’s on to the next thing?” That’s not who wins the game, necessarily. People who win the game are organizations –

    Fletcher: Well, and –

    Shimel: – and their customers. Go ahead. I’m sorry.

    Fletcher: And some of these things are – all these things are less relevant, so, if you’ve got a system you’re gonna throw away in two years’ time, there’s – ROI to spend tons of time automating it and putting all that engineering in place with, you know, sort of – is kind of mothballed. So, again, it’s picking the right application, the right teams, to get benefit from this. I don’t necessarily see the – you have _____ all of these other _____ everywhere. Waterfall has its place. It’s about picking what is right for the business and getting the business _____ _____ _____. It’s not about a blanket “This is a right way or this is a wrong way of doing IT.” I just don’t believe that.

    Shimel: Mm-hmm. I agree with you. And so, Jonathan, we’ve come full circle in our short little chat, but this is what makes DOES a great conference to attend. Right? Where we are hearing these transformation stories, and some of them may be old hat to some of us, some of it may be a revelation to others. Right? But it’s – the last part of this that I wanted to hit is that it’s, at the end of the day, it’s about the community. We as a collective community learn from each other’s experiences and these shared experiences, and that’s how we evolve and that’s how the whole movement moves forward, not just Hiscox, not just Disney, not just any particular organization, but as an industry, as a movement, that’s how we move forward. And then I think that’s what DOES is about.

    Fletcher: Yeah, and that feels fairly unique. I can’t remember, in my 20-odd years of working IT, a movement with such a community feel, with so many people who want to help other people, and it’s – I think that’s amazing. And I don’t ever get – when I speak to people much further down the line than we are and they do better things then we do, I never get that looking down their noses or “You should be where we are.” It does feel like a real community sense of being, that everyone’s gonna help each other. And I don’t know what it is about DevOps, but I think that’s amazing, and you really see that at DOES.

    Shimel: Yep. Absolutely. Jonathan, we’re about out of time here – probably, we’re over time – but, listen, I wanna thank you for joining us today on DevOps Chat. I look forward to hearing your presentation at DOES London and we’ll check in before then and get more of a final version of what you’re speaking about. And, also, I wanna thank you for being on the program committee. I’ve been on organizing in program committees of events in the past and I know it’s, in a lot of ways, an unsung job – you don’t get paid for it and God knows there’s ton of work that goes into it – so thank you for your service.

    Fletcher: You’re welcome. Thanks very much.

    Shimel: No, my pleasure. And, Jonathan, I’ll get together in London beyond that. Maybe we’ll catch up on a video or something. Hey, but continued success. I hope, by the time I see you in June, the interim title’s gone. They couldn’t find a better man or person for that job. All right?

    Fletcher: Thanks, Alan.

    Shimel: Cheers, Jonathan. Jonathan Fletcher, Hiscox and the program committee at DOES London 2017. This is Alan Shimel for DevOps Chats and devopsy.kinsta.cloud, and we’ll see you on another chat soon.

    — Alan Shimel

  • DevOps Chat: Maslow’s Hierarchy of Needs & DevOps with Omed Habib

    DevOps Chat: Maslow’s Hierarchy of Needs & DevOps with Omed Habib

    OK, I admit it. Thinking of Maslow’s Hierarchy of Needs and DevOps doesn’t seem like an obvious connection. But Omed Habib of AppDynamics gives us the connection of how Maslow’s theory applies to developers and DevOps people. Because after all, they are people too, right? Right?

    Anyway, this is a great conversation that I think you will enjoy. As usual the streaming audio of our conversation is below and the text is below that. Enjoy!

    Alan Shimel: One, two, three. Hey, everyone, this is Alan Shimel, devopsy.kinsta.cloud here for another DevOps Chat. Today’s guest on DevOps Chat is Omed Habib from AppDynamics. Omed, welcome to DevOps Chat.

    Omed Habib: Thank you, Alan. Pleasure to be here.

    Shimel: Thank you. So, Omed, I would imagine most of our audience is already very familiar, at least pretty familiar, with AppDynamics. You guys have sort of become just a huge success in the APM market, though some may call what you guys do not exactly “APM”—I’m not even sure if AppDynamics calls it “APM” anymore—but, nevertheless, company that’s had tremendous amount of success. What’s your role at AppDynamics?

    Habib: Well, I originally joined AppDynamics as a product manager. My first couple of years, very proudly brought our PHP, Node.js, Python APM agents to market. And, as of a couple years ago, I joined the product marketing team, so I’m now helping lead the strategy behind all of the outbound product responsibilities.

    Shimel: Sure. So, Omed, in simpler times, just three, four years ago, it was easy to put AppDynamics into that sort of APM bucket, if you will, but that’s not necessarily the case anymore, is it?

    Habib: You know, the term “APM” itself, like you said, is starting to put into question. What AppDynamics does, at least in my opinion, is very simple. I think what is becoming—the definitions that are changing right now are the processes within the software environments and where AppDynamics plays a role or, rather, where AppDynamics—sorry, APM as a concept plays a role. Historically, we’ve had divided teams, right—operations are responsible for production monitoring, and so they would have the production-monitoring tools; developers had their siloed environments—they would ship their code—and so they had their decouple tools.

    But what we’re starting to see now is a shift in runtimes becoming far more sophisticated, and the barrier to entry to production is so much lower now that developers and operations—I’m gonna introduce a whole new term; we call it—it’s not new, but I’m just gonna call it “engineering teams,” “application teams,” are now responsible for the entire software development life cycle of the product, so developers are now deploying code; operations folks are now responsible for not just the infrastructure and the production monitoring, but also they’re starting to look at everything from an application perspective, versus an infrastructure perspective.

    The other thing that I’m noticing, Alan, is that we’re starting to see far more abstraction here of the infrastructure and the deployment models of applications. In other words, teams are no longer responsible for spinning up servers and configuring hardware and configuring the specs behind the infrastructure. All of that’s becoming abstracted, and so it’s causing—again, I’m not gonna call it “dev teams” or “ops teams” because I see these two teams merging, I’m talking, five years, maybe possibly in 10 years, possibly even sooner than that, down the line. I’m just gonna call it “engineering teams.” Engineering teams responsible for the application, the product itself.

    And I see these roles starting to merge. We’re starting to already see _____ the ops responsibilities. You know, Google’s introduced the SRE role, right? The site reliability engineer. And the nature of that role is someone who comes from a developer background, facing the challenges of operations and the idea behind that is to have a developer mindset of “How much of this can you automate using code?” And so they’re trying to solve—again, it goes back to the abstraction idea, right? Everything becoming abstracted. So what they’re essentially trying to do is automate as much of the infrastructure as possible so that, end of the day, a developer can do what they do best, which is checking code and work on features and work on the backlog.

    What we’re seeing today, right now, is the crossroad of development teams starting to take a step back and realize that, “Hey, what the heck is going on here? We have this giant backlog full of features and we’re doing nothing but putting out fires all day long. We have bugs; we have performance issues; we have database issues; infrastructure issues.” Right? So if you were to look at it—[chuckles] it’s kind of funny. I get very Maslowian here, but if you look at Maslow’s Hierarchy of Needs, right?

    Shimel: Mm-hmm.

    Habib: I’m getting kind of philosophical here, but I got a point. [Chuckles]

    Shimel: No, no, go ahead.

    Habib: Maslow’s Hierarchy of Needs, essentially, states that everybody, every human with a purpose, goes through this journey, but they have to go through levels, and it starts with the foundational layer, right, into the second layer and a third and fourth layer. But the very top of that pyramid is what they call—what he calls “self-actualization.” And self-actualization is when you, as a human being, as a person, you get to actually do what you were on this planet to do, where you solve for everything else—shelter, security, your social needs, your physiological needs. And so you get to a point where you say, “Well, what is it that I was here to do to begin with?” Right? And so you get to actually work on the things that are larger purpose of you as a person.

    Developers, I’ve noticed, are actually going through a Maslowian hierarchy. The very premise, the very foundational premise, of what they do is their toolset—their development environments or sandbox environments, their pre-production environments—and so what we’re noticing here is that developers are starting to go through their own Maslowian-style pyramid, in that the foundation of the pyramid, essentially, is a development team solving for their proper development environments, sandbox environments, embracing a DevOps culture, ensuring a pragmatic, iterative software-dev life cycle, ensuring for proper infrastructure, making sure that they have the proper monitoring tools in place. And so, as they continue to move forward and advance from one layer to the other, they no longer have bugs in production, they’re no longer solving for bad code being shipped, because they’ve already solved for that. Right? The teams that have not are stuck at the bottom of the pyramid, and the teams that have advanced forward are hitting a point of self-actualization.

    And so, if I were to draw a parallel with Maslow, I’d say that developers—development teams, applications teams—today, have hit a point of self-actualization, which essentially says, “Well, what are you actually here to do?” And what you’re actually here to do, as a development team, is to work on moving the business forward—work on the backlog, work on the features. And what are those features? Those features come from a road map and have been prioritized, from business strategy perspective. So you’re essentially getting your development and engineering teams back in line with what they were there to do to begin with, which is “Now let’s start to move the business forward.”

    From a philosophical perspective, that’s what DevOps was to begin with, right? That’s what developers and operations teams are hired to do to begin with. Unfortunately, because of the lack of sophistication in the tools and the processes, what we’ve seen in the last few decades is that, developers and engineering teams and operations teams, they’ve been stuck in this rut on the first foundation of that pyramid or the second level of that pyramid. And it’s change blindness, right, from a psychological perspective. It’s, when something happens, some kind of change happens, so slowly over time, you don’t notice it whatsoever, and so you start—you eventually start seeing these development teams accept. Unfortunately, they’re trying to accept their roles as, “Yeah, I just fix bugs all day long.” Right? “I just put out fires all day long.”

    Shimel: Yeah.

    Habib: [Chuckles]

    Shimel: And you –

    Habib: That’s because you’re stuck at the bottom of that pyramid.

    Shimel: Yeah. And you know what? It’s funny you say that, Omed, because I’ve been in technology, oh, 25 years, and so we used to call it “They’re working in the sausage factory, but they really don’t know how we make sausage.” Right? And this happens. I see it in software’s life cycle and supply chain, where everyone kinda does their job but they don’t realize how their job is part of the larger picture. Right? If someone’s just stuffing meat in the sausage machine, in the back of the sausage machine, but they never see what the sausage looks like when it comes out or what it tastes like, it’s very hard for them to imagine or to empathize with the guy who has to eat the sausage. And, all too often, that happens, especially in software development. I’m sorry to say, but –

    Habib: Yeah, no, you’re absolutely correct.

    Shimel: Yep. So –

    Habib: What’s funny is that not only is the pyramid very similar to how software developers evolve, but Maslow also said that, if you’re stuck at any one of the foundational layers or, for example, if you don’t even have the foundation, that actually goes into the symptoms of what a person experiences. For example, if you don’t have a roof over your head and you’re constantly worried about the elements, right, the symptoms of that is gonna be anxiety and paranoia and discomfort, right? Development teams—I mean, you can draw the exact same parallel and say, “Well, if you don’t have a proper DevOps environment, then the symptoms of that are gonna be X, Y and Z,” right? Anything that is lower than self-actualization is gonna have symptoms, and those symptoms, obviously, are bugs in production, application issues, the backlog growing ever so bigger without you actually even touching it, technical debt increasing, so on and so forth.

    But it kinda reminds me—when you talk about the guy that works in the sausage factory, it reminds me of the famous story of the three—I might butcher the story, but it’s the three workers that were working on a cathedral. A passerby comes by and asks the first person, “What are you working on?” and he says, “Oh, I’m just—I’m working on this stone and I’m just hacking away at the stone.” And then he goes to the next person and says, “What are you working on?” He goes, “Oh, I’m just working on this wall, and it’s something that’s gonna be used on this home.” And he goes to—and, by the way, all three of them are doing the exact same thing.

    Shimel: Mm-hmm.

    Habib: He goes to the third person. He says, “What are you working on?” And he says, “Can’t you see? I’m working on a cathedral.”

    Shimel: Hmm.

    Habib: So, when you’re at the bottom of that pyramid, you lose sight of what you’re doing to begin with.

    Shimel: Got it.

    Habib: When you’re at the top of the pyramid, a point of self-actualization, right, where you’re supposed to be to begin with, where you’re supposed to be doing what you’re actually supposed to be doing, then you begin to realize the big picture. When you realize the big picture, then, as an engineering team, you are realigned back to the strategy of the business. And self-actualized engineering teams understand not just what they’re working on and how they’re working on it but also why they’re working on it. And with that comes the additional responsibility of, “Well, if you know why you’re working on it, then how do you measure success?” ‘Cause you already measured success at the bottom of the pyramid, for your application, but, if you’re now at the top of the pyramid—and, as a self-actualized engineering team, you’re not just measuring the success of the application, right—performance of the application, the technical performance of it—but you’re also measuring the success of the business performance of your application.

    Shimel: Sure.

    Habib: And that is what we’re starting to see today. A lot more engineering teams who are moving to the top of that pyramid are now getting reintroduced to having a seat at that table of “Hey, I’m not just a software developer. I’m not just an IT cost center. But I’m a partner in the business strategy behind this application.”

    Shimel: Yep. “And I deliver customer satisfaction.” Fantastic. This was a great—great conversation, Omed. Very insightful. Unfortunately, well, we’ve gone way over our time, but we’ll deal with it.

    Habib: [Chuckles]

    Shimel: Omed, we’d love to have you back on at some point, though, ’cause our audience is so developer-centric and ops-centric too, but “tech-centric,” I guess, is a better word, that I’m sure they identify with this, and I’d love to continue this conversation. So perhaps we’ll –

    Habib: Yeah, it was a pleasure chatting with you.

    Shimel: Yeah. We’ll find some time and do it—do more of it. Or maybe you wanna write about it on devopsy.kinsta.cloud. We’ll talk about it offline. Anyway, Omed Habib, AppDynamics, thanks for being this episode’s guest on DevOps Chat, and thank you for everyone listening, and we’ll see you again on another DevOps Chat. This is Alan Shimel for devopsy.kinsta.cloud.

    — Alan Shimel

  • DevOps Chat: DOES London 2017 Speaker Jose Quaresma, Accenture

    DevOps Chat: DOES London 2017 Speaker Jose Quaresma, Accenture

    In anticipation of the DevOps Enterprise Summit (DOES) London 2017, we are interviewing a series of the announced speakers who will be appearing there. The first in our DOES London 2017 speaker interviews is with Jose Quaresma of Accenture. Jose is a leader at Accenture and has a lot of knowledge on real DevOps transformations. I think you will find this conversation very enlightening.

    As usual immediately below is the streaming audio of our chat, followed by the transcript of our discussion below.  DOES London 2017 is shaping up to be another great conference. Also as usual, we will be live on-scene with coverage.

    Alan Shimel: Hey, everyone, this is Alan Shimel, Editor in Chief of devopsy.kinsta.cloud, and we’re here for another DevOps Chat. Today’s DevOps Chat guest is Jose Quaresma—and I probably messed that up, but Jose is with Accenture, and he’s based over in Denmark. Welcome, Jose—how are you?

    Jose Quaresma: Thank you, Alan. I’m pretty good. First of all, thanks a lot for having me. I would say it’s quite an honor to participate in this chat with you.

    Shimel: Oh!

    Quaresma: Oh, and yes—and by the way, you got the—

    Shimel: Well, flattery will get you everywhere.

    Quaresma: [Laughter]

    Shimel: But we’re talking a little bit today, and it’s regarding, you know, the second annual DevOps Enterprise Summit London is coming up June 5th and 6th at the QE2 in London, and you will be presenting there, correct?

    Quaresma: Yes, that’s correct—yeah.

    Shimel: And I wanted to—well, before we get into your presentation at DevOps Enterprise Summit, why don’t we give people a little bit of your background?

    Quaresma: Sure. I can give it a quick try. So, as you said, I’m Jose, and Quaresma is the last name, so you actually did pretty well, Alan. And I’m originally from Portugal, but I’ve been living in Denmark for almost eight years now. I kinda moved in here to study, and kinda after university, then I started Accenture here in Denmark as well, which I’ve been for around three and a half years now.

    I am an Application Development Associate Manager in Advanced Technology in a subgroup called Advanced Technology and Architecture, and I am the DevOps lead for Accenture Denmark.

    Shimel: Excellent. And Jose, as part of that, why don’t—any particular engagements of interest that you can talk about right now?

    Quaresma: Yeah. So I had, I can say, so, there were two main engagements that I’ve been involved with, and the first one was actually not so much involved in DevOps. I kinda started more as a middleware developer and kind of then walked towards the kind of web service design and team lead on that middleware area, and there was some DevOps work related there kind of with deploying the web services. But that wasn’t really something that I was driving.

    But then around two, two and a half years, I kind of, it was actually, my manager—and I guess I have to thank him for that; thanks, Jarom—he kind of, he was the one kind of guiding me towards, “Okay, we have this kind of DevOps domain getting a bit more traction, and we would like to, how would you like,” it was actually asking, “How would you like to lead that domain and try to raise a bit more awareness of DevOps here in Denmark?”

    So that was an interesting opportunity that I saw and yeah, from then, I was also then transitioned to a new project, which is actually the project that I’m going to co-present at DevOps Enterprise Summit now in London in June, and I’m co-presenting that with Amin Budali from Nordea, and that is the client that I’m currently working with, and this is a huge project. So Nordea, for the ones who don’t know, it’s a huge Nordic bank, being active in Denmark and Sweden and Norway and Finland. And this is, the project is about replacing their core banking application across the four countries. So it’s a huge project, a five-year project where we are working on replacing the core application with a new T24 application provided by Temenos. And that—

    Shimel: Go ahead. Go ahead, Jose.

    Quaresma: —and then that’s where kind of the more, it was, the DevOps, it has been very relevant now in this project, and the main thing is that, what we are, the part that we are presenting at DOES now, it’s, as I was saying, it’s not really a finished story, I would say it’s a story that has started around one year ago and we already have some interesting successes that I’m happy to talk about, but it’s hopefully a story that will have one, two, three more years until we have this very successful destination that I’m hoping I can come back to, to the DevOps Enterprise Summit and talk about that in one or two years. That would be great.

    Shimel: That would be great.

    Quaresma: Yeah, and that’s something I hope for, and I work for as well.

    Shimel: So I’d like to ask you, Jose, for our listeners out there who maybe are listening and saying to themselves, “Man, I sure would like to present one day at a DOES, you know, a DevOps Enterprise Summit or a similar thing.” Can you give our audience maybe a little bit of background on how it came to be?

    Quaresma: Yeah. I can try. So, it was actually, we have, this all kind of started with, we have a DevOps Week internally in Accenture as well, and in that internal DevOps Week, which was maybe one or two months ago, around there, maybe one month ago, we were actually, I was—I got to present this kind of, a little bit this story as well together with the client at our kind of internal DevOps Week.

    And then the idea came, from that point on, it’s like, “Oh, we actually have, there’s this really amazing conference in London. Why don’t we just try, maybe?” And we did have—I confess, we did have some doubts whether we would get in, and I think the main part is thinking that, okay, we don’t actually have this beautiful, happy ending story yet. We’re still struggling, we’re still halfway through our journey. But then, also, reading through the description, we saw that these kind of ongoing journeys are also welcome at the conference, so we thought, “Well, let’s write down the things that we have learned and what we would like to present, and then let’s see if they think that will be interesting.”

    Shimel: Got it. And sort of, you know, I think that’s a great description of the process and everything. Have you spoken at other events, Jose?

    Quaresma: No, not really. Not at this magnitude. I’ve given kind of more internal presentations and also outside Denmark, but not really, not an event of this magnitude. So yes, I’ll be pretty nervous. [Laughter]

    Shimel: What? There’s nothing to be nervous about. I’ve always found that as long as you are fluent in what you’re going to speak about, as long as you’re comfortable with that, you know, whether it be a big audience, a small audience or have you, it’s all the same, really.

    Quaresma: Yeah. That’s a good point. I’ll take that with me. And not only being fluent, but also that, I think it will help that I will be talking about something that I’m really excited about and that I’ve been working hard for, so I think that will make it a little bit easier.

    Shimel: Got it. You know, one of the things I wanted to talk to you about is, you know, working for Accenture, you—a little different than working for just a single company in that you work with multiple clients, right, and so that gives you a chance to see sort of transformational issues, you know, across multiple organizations.

    Quaresma: Yeah.

    Shimel: Where a lot of people, you know, they work at Disney or they work at NBC Universal or they work at a company and sort of very much—and even at jeans events like the DevOps Enterprise Summit, it’s very much, “Here is my company’s transformation story.”

    Jose, having looked at multiple companies’ transformations, what do you think you can share with our audience that sort of transcends any one organization, right, and go into multiple ones?

    Quaresma: Yeah, there’s—so, one thing is, I won’t lie to you or the audience. I mean, this is the first big DevOps transformation that I’m involved with, so I can’t really kind of pull out of my hat kind of the 10 transformations that I’ve been involved with and share some kind of overall wisdom on that.

    So this is definitely an advantage that I see and that I hope to use more in the future once I kind of, as you say, keep getting the experience of several different transformations in different clients with different scenarios, when you kind of—once you’ve started getting more experience with all those different transformations, there will always be things that are different, then I hope I can kind of learn from that and be able to extract some knowledge from those differences as well.

    Shimel: Sure, sure. Jose, we’re almost out of time. As I promised you, it goes really quick. But let’s talk for a moment about, and this is something—so you did it, when you started your career and, you know, you said you’ve been in Denmark now eight years. Certainly it wasn’t to do DevOps transformations and so forth, but where did you come from to get to here, kind of, if you know what I mean?

    Quaresma: Yeah, and that’s a pretty tough question. So, it’s kind of, my background is mostly on security and also related with—so my Master’s was actually called Security in Mobile Computing, and then I also had a, after that I had a Ph.D. in network security, mostly related with formal methods and how to kind of analyze the security of a communication protocol.

    But I think the, kind of my career evolution, if—[Laughter] I never thought about it like that, but if you can say that, it has been pretty, I would say pretty organic. I mean, I have—it’s not like I’ve been forcing myself or have this five-year plan that I think, “Okay, in five years, I wanna be there.” It has been mostly about doing the things that I kind of enjoy doing and that I can see that I’m providing some good value, and also following the interesting thing.

    So, for DevOps, it was actually that, before it was my work, it was already kind of a hobby in that I was at home outside working hours playing around with some Docker setup and trying out some different technologies there, and then I think that also made it easier to bring that to work, because if it’s something that I’m excited about also outside work, then it was even easier to just bring that excitement and motivation for something that I do in my everyday life.

    Shimel: Excellent. Well, Jose, I’m sure you’re gonna have a great presentation with the bank at DevOps London, DevOps Enterprise Summit London, and we’re looking forward to seeing you there.

    Quaresma: Yeah.

    Shimel: And thanks for being our guest on this episode of DevOps Chat as well.

    Quaresma: Yeah, thanks so much, Alan.

    Shimel: Thank you, and continued success, Jose Quaresma of Accenture, who is a speaker for DevOps Enterprise London 2017 on June 5th and 6th, our guest today on DevOps Chat. This is Alan Shimel for devopsy.kinsta.cloud. Thanks, everyone, and have a great day.

    — Alan Shimel

  • DevOps Chat: Dead-End Computer Languages with Scott Wilson

    DevOps Chat: Dead-End Computer Languages with Scott Wilson

    Scott Wilson from Automic is always a great source of knowledge around DevOps. I have spoken with him several times and he never disappoints. In this DevOps Chat, Scott talks to us about dead-end computer languages. Scott, who is a developer himself, often marvels at the explosion of languages available today and wonders how many will survive beyond the useful life of the applications that they are written in.

    It is a great point. We did a survey a while back that showed the average organization is supporting upwards of 10 + languages concurrently. Talk about tower of Babel. Well, Scott gives us some great background on this.

    Streaming Audio

    Chat Transcript

    Alan Shimel: Hi, everyone—Alan Shimel, devopsy.kinsta.cloud, here for another DevOps Chat. This episode’s guest on DevOps Chat is Scott Wilson of Automic. Scott, welcome to DevOps Chat.

    Wilson: Thank you, Alan. I’m glad to be here.

    Shimel: Yep, and Scott, we’ve spoken before, we’ve done webinars and podcasts in the past, and are fairly familiar, but for our audience who may not know who Scott Wilson is, why don’t you give us a quick background?

    Wilson: Okay, great. Thank you, Alan. I am currently the product marketing director at Automic Software, and basically, I am specializing particularly in DevOps and application release automation.

    I come from a pretty technical background. I started basically in high school writing code. I was a software developer for a long time, and you know, in many evolutions, different vertical markets of writing code, and I’ve evolved ultimately now into marketing, so.

    Shimel: That’s not such a bad thing, Scott. But [Laughter]—there are fates worse than death.

    Wilson: [Laughter]

    Shimel: But anyway, Scott, we were gonna talk a little bit today about, you know, sort of, we can call them dead-end languages—and by that, I mean, you know, it’s a great time to be a developer today. You have so many choices in what you want to develop.

    But, like anything else, you know, there will be winners and losers among development languages that you can choose from. And I know this is a—

    Wilson: Absolutely.

    Shimel: – yeah, this is a topic you’ve spoken and written on. So I wanted to kind of, you know, with that premise, why don’t you explain to our audience a little bit about what you’re talking about?

    Wilson: Okay. Well, you know, as I mentioned in the intro, Alan, I am no stranger to code, and I will admit I still write code on the side for various things here and there. And one of the things that has struck me over my experience, especially with talking with customers and even working for a couple of vendors for application release automation products is that, in DevOps in general, there’s this great level of interest and experimentation going on with languages. A lot of the ARA tooling provides ways for you to build your own plug-ins, for example, so that you can extend these products and extend their reach into building a nice, cohesive tool chain—a DevOps pipeline, if you will.

    And the challenge is, as I started looking at a lot of these products and a lot of the momentum in DevOps is, I started realizing that people are choosing languages that are kind of dead on arrival already. What really sparked my interest in this was not only my observation here, Alan, but I spoke with an executive at a large company, and he was telling me that they were having to rewrite a lot of their DevOps code—their deployment code, if you will—because the folks that had written their pipeline five years ago used a language that they can no longer hire people to write it. And so they’re having to scratch it and rewrite it again, and I have actually heard this theme a few other times as I’ve met with executives across the U.S.

    So that had me really diving in and trying to figure out, well, how big of a problem is this? There is—and I won’t name the company, but there is one area vendor that does offer a PERL toolkit, just for example, to connect to their API and interact with it. The problem is, PERL is a dying language. So, if—now, this vendor also does not exclusively demand you use PERL, but I just found it an odd choice that they would even support that, given its decreasing popularity. Additionally, I was at a Chef conference this last summer, summer of 2016, and they announced their new Habitat write platform, and it was all written in Rust. Again, another odd, obscure language.

    And so, Alan, what I did is, I went around and started looking to find out, well, why are some of these companies choosing a language and then five years later, not able to support the language and the tool that they have built it in? And there are several, it turns out, popularity indexes, Alan, and you can look around for these. There’s one called the Popularity of Programming Language, PYPL, and it’s listed on GitHub, and it lists all the popularity—languages by popularity and share. There’s the TIOBE index as well, and there are several indexes. Some of them compile indexes, I think—what is it? There’s one that is garnered by what’s called Coding Dojo, and several others that go look at job listings to see what are the most popular language requirements in job listings.

    And if you wanna get a good sense of this, actually, you can actually go to ZDNet.com. They wrote a great article that basically took all the different indexes, aggregated them, and put them together. And what’s interesting in their findings is that you don’t see PERL, you don’t see Rust, you don’t see a lot of these, I call them doctorate languages, meaning people going to get their doctorates in computer science wind up creating these languages and they each kinda have their own cult following, Alan. Which is cool in one respect, but in the other respect, it means that if you’re not careful, you can latch on to some programming language for your DevOps practice and wind up choosing a language that is in fact not sustainable. That’s a trend, and you wind up—

    Shimel: Certainly—so Scott, in the case of Rust and maybe some of the other more obscure kinda languages we run into, I get what you’re saying and I don’t disagree, but you know, when you look at PERL, you know, you and I are not 20-somethings, Scott, right? I mean, PERL has been around a long time, and in its day, you know, back in the dot com bubble, you know, PERL was the equivalent of PHP, you know? And recently I saw, I think PHP is out—PHP 5 or whatever is out there now.

    But, you know, PERL—if you would have asked me a language to bet on in 1998, I probably would’ve bet on PERL. You know, I wouldn’t think it would become obscure or obsolete—though, look, ’98, you know, we’re talking 18, 19 years, and certainly nothing lives forever.

    But how are people out there—you know, it’s so hard. We don’t have a crystal ball, right? And we do have these indexes, but how do we know, like, what’s the next hot one and which is the next dud?

    Wilson: That’s an excellent question, and just to provide me the story, Alan, of your, what you’ve pointed out—because there is no crystal ball, and it is tough—I think the whole IT industry right now, including programming languages, it really reminds me a lot of the turn of the 20th century when there was really no clear definition of what an automobile should look like. And there were various versions—Edison had his battery operated vehicle, and there were several steamers, there several combustion engines and there were lots and lots of losers, lots of investments that went bust.

    And it took, you know, basically a couple of decades, but by the time we hit the 1920s, everyone understood and knew what an automobile looked like, and it looked like and operated like a Model T, right?

    And so it’s really kinda tough right now. So what I like to do, or what I recommend in the context of what we’re talking about here with languages is to really look at where it’s trending and what its longevity has been. If you look at that, you know, Java, C++ are popular. That might be, C have had, and even JavaScript have had a great deal of sustained momentum over a couple of decades.

    You were right—PERL, at the time, was great, but according to the popularity index, it is as its lowest popularity point since 2001 and is continually trending down. PHP has been holding its own, and in the composite index, it is still listed as one of the more popular languages.

    And so, you know, I would be—frankly, if I were practicing a language to help extend my DevOps practice, I would definitely look at what things have been sustainable over the last several years—decades, rather—and really look at the trending. And that’s why—and not to sound too critical, but when I look at Chef, placing Habitat on Rust, for example, was probably not a great idea for the future. If you look at what languages have sustained over the last 20 years, it would have been better for them to have chosen Java, because you have a huge base of Java developers and you could have then had a much larger contribution base to the project. So I think there’s just things you can do like that.

    And then, you know, the other thing, Alan, to your point—and it’s very unsexy to say this, but there has been one kind of, I’ll call it quasi-programming interface that has spanned the entire test of time and has remained consistent. And it also, what’s neat about this, is I have observed, it transcends every IT specialist, and then as a command line interface or a CLI. I’ve found, in looking at this, that it was very interesting that one of the challenges of, let’s say, extending some new fad DevOps tool using a programming language is that it requires a programmer, and you have to understand the grammar of the language. And that usually silos the expertise that is capable, or readily capable of picking this up. Where, versus a command line interface, they were designed, frankly, for the use case to be readily understood and easily picked up, and they transcend everybody, whether you’re a software developer, a DBA—everyone kind of gets to very quickly understand how command line interfaces work.

    So I’d be, if I were trying to build my DevOps practice today, I would actually be more keen on looking at using command line interfaces, published ones, to set up a lot of my extensions and automation mechanics, just because they have transcended time and have the longest life span of any language, though I wouldn’t say command line interface is a language, it is an interface, right? But the nice thing is, they are mostly self-documenting, where the programming languages, you have to know the language to understand what it’s doing, and they’re generally not self-documenting.

    Shimel: Got it. Scott, I don’t wanna put you on the spot, but give our listeners, if you can, what you think are your top three choices for the languages to use, let’s say, in the foreseeable future.

    Wilson: Alright. Excellent question. Well, as always, it depends on what you’re looking to do. That’s what’s very interesting when you look at the indexes and the aggregates and the composites of these indexes is, it really depends. I look at languages a lot like tools in a tool shed. They do a specific thing. You wouldn’t want to write a web server, for example, in C. I mean, you could, but you know, it has diminishing returns.

    I would say, in the modern cloud that we’re in, the more popular languages that would support this are certainly Java, you’ve got Python, PHP, JavaScript and C# are amongst the more popular ones. They’ve been around for a while. C#, as you know, is backed by Microsoft, a big company, and is recently going open source, the .net platform is. It works on every platform—Mac, Windows, Linux, what have you. So that could be interesting. JavaScript, I mean, for its ease of use? I mean, goodness, it’s been around for quite a while. You’ve got services like Node.js in which you can run very sophisticated apps on it.

    I’d probably be looking in that tier for the modern, cloud-based apps—Java, Python, PHP, C#, JavaScript would probably be the languages I would be more keen on looking at.

    Shimel: Got it. So, Scott, believe it or not, we’ve kinda used up our 15 minutes of fame, here. But you know, this is an interesting subject matter, Scott, that I think many developers sort of delve in. You know, there’s the, I call it the shiny trinket syndrome where everybody wants to use the latest and greatest cool tool, but sometimes, you know, these fads fade out quickly and you’re left, you know, with a fantastic product that was developed in a dead-end language, or a fantastic app developed in a dead-end language. So definitely something to be wary of.

    Wilson: [Cross talk] Yeah, like I said, the languages that are great for creating a project, if you’re trying to do a lot of those DevOps automation mechanics, I would really, highly recommend looking at command language interfaces to stitch a lot of that together.

    Shimel: Yep. So, Scott, we’re gonna call it a wrap on today’s podcast. Obviously there’s big news going on with Automic and acquisition news and stuff, and maybe once the dust settles on that, we could have you back on and talk about that a bit.

    Wilson: Absolutely. I’d love to.

    Shimel: Until then, though, Scott Wilson, Automic—continued success, keep doing what you’re doing, and thanks for being this episode’s guest on DevOps Chat.

    Wilson: Thank you, Alan. Have a great day.

    Shimel: Alright. This is Alan Shimel for devopsy.kinsta.cloud for DevOps Chat, and thanks for listening and we’ll see you on the next chat. Bye bye, everyone.

    — Alan Shimel

  • DevOps Chat: ‘The DevOps Adoption Playbook’ by Sanjeev Sharma

    DevOps Chat: ‘The DevOps Adoption Playbook’ by Sanjeev Sharma

    Before the recent IBM InterConnect conference I had a chance to sit down and chat with Sanjeev Sharma, CTO of DevOps Adoption at IBM. I have spoken to Sanjeev many times and he is a contributor to devopsy.kinsta.cloud, as well as the author of “DevOps for Dummies.” Sanjeev has a new book out called “The DevOps Adoption Playbook.”

    With no disrespect toward the “DevOps for Dummies” book, the playbook is on a whole different level. This book represents the culmination of years of learning by not only Sanjeev, but by IBM in general, as well as some of the leading names in DevOps that he learned from during this time.

    “The DevOps Adoption Playbook” lays out a clear “how to” for DevOps including topics such as value-stream mapping, how to lead the transformation of culture and scaling DevOps to the enterprise. As Sanjeev himself says, the book started from a power point of best practices that he had started that tried to take in everything he had learned.

    Sanjeev also stays true to the “playbook” paradigm. He makes references to cricket, soccer and other sports throughout. It is a good read and well-organized. As I told Sanjeev, in a field full of “what is,” “The DevOps Adoption Playbook” is a “how to.” I highly recommend it.

    As usual, the streaming audio of our conversation is below, with the transcript of our conversation below it.

    Alan Shimel: Hi, everyone. Alan Shimel, devopsy.kinsta.cloud, here for another DevOps Chat. Today’s guest on DevOps Chat is Sanjeev Sharma, a DevOps author and IBM CTO DevOps. Sanjeev, welcome.

    Sharma: Thanks, Alan. Good to talk to you again and I’m glad to be on this DevOps Chat

    Shimel: Absolutely. Sanjeev, you are of course CTO DevOps Solutions at IBM, correct?

    Sharma: The exact title, not that it matters as much—it’s just nomenclature—is CTO DevOps Adoption. I am client-facing and work with customers around the world, helping them adopt DevOps, primarily focused of course on IBM solutions.

    Shimel: In addition to that, Sanjeev, of course you are the author of both editions of the “DevOps for Dummies” books, which were very successful in introducing DevOps concepts to the world at a time when DevOps wasn’t quite as well-known as it is now. Correct?

    Sharma: Right, yes. It’s hard to believe that that book has been around for multiple years now. We’ve had tremendous success. Bernie Coyne coauthored the second edition with me. We updated it and it’s been very successful. The book came out at a time when people were mostly asking the question, “What is DevOps and what does it mean to me?” That’s what that book is targeted towards. It’s a very short book. You can read it in an hour, an hour and a half. It’s like a dummified version, so pretty short and to the point.

    Shimel: Yes. But really, Sanjeev, I wanted to talk to you about the new book that you just came out with through Wiley and IBM Press and its called “The DevOps Adoption Playbook: A Guide to Adopting DevOps in a Multi-Speed IT Enterprise.” Sanjeev, I’ve read the book and to me this sort of represents the culmination of all of the lessons and the knowledge that you have accumulated over these last few years, in helping organizations around the world with their DevOps. Is that fair to say?

    Sharma: Absolutely, but I would go one step further and say it’s just not my knowledge and my experiences, which are fairly extensive. I’m sure I worked with dozens of customers around the world. I haven’t counted, but some of them very intimately through their multi-year DevOps adoption journey.

    But as you will see in the acknowledgement section of the book, it was also knowledge I gained talking to my colleagues here at IBM, talking to people like you and other business partners, our followers and colleagues in the DevOps industry, and also of course from our customers, because I wasn’t with them 24/7 carrying the tools of the trade and implementing DevOps and fighting the technology and the political and the business battles. They were doing it, and I was learning by observing them succeed or, in some cases, stumble and then figuring out with them how to go around the hurdles they were facing. So I owe a lot to all the people I worked with over these years, including our customers, in putting together what has come in this book.

    Shimel: Absolutely. Sanjeev, you’re being humble. You have worked with dozens of DevOps people. But in that role, as you say, you’ve interacted with many of the thought leaders, if we can call them that, within the DevOps movement.

    More than that though, when you look at the book, what I’ve said about the book and I’m writing a review of it, is that in a world full of books that are “what is” your book is a “how-to.” I think that’s an important reminder. We read too many books around DevOps that are trying to define what DevOps is, trying to put your finger on that slippery fish of, “This is DevOps,” where you spend some time on that right in Chapter 1. We give a little review of DevOps, but you spend a lot more time on good practical how-to DevOps advice.

    Was that your idea with this book? What drove you to write this book?

    Sharma: Absolutely, Alan. If you read this as a “how-to” book and not a “what” book, then I have succeeded in getting my message across. Quite frankly, it’s how this book came together. As I was working with our clients maybe two years, 18 months ago, the questions started changing. People no longer were asking us, “What is DevOps?” They were asking us, “How do I adopt DevOps? What are you seeing other people do? What can I learn from your experiences when you go with that bank over there or that health care company or that telco, that retailer? What are you observing when you’re out there in the trenches?”

    I started actually putting together a PowerPoint deck. This is where this book started, as a PowerPoint deck of best practices as part of the success. In fact, last year at InterConnect, myself and my colleague, Lee Reid, who is actually the technical editor of the book, we did that presentation and we called it “The DevOps Adoption Playbook,” and that’s what I intended this to be, this book to be a playbook which somebody reading it can have or they can learn all about it and then, based on the situation they are facing, pick a play, just like a coach or a captain does or a quarterback does in American football. He can do a read and get an idea of, “Okay. We need to run this play because that’s what’s needed here.”

    So it’s definitely a how-to book. There are certain, of course, strategic areas in the book on how to convince the business that the DevOps is in order to make a business case. Like its name suggests, it’s a playbook on how to go and get in the trenches and adopt DevOps in a large organization.

    Shimel: Sanjeev, first of all, the book is available on Amazon and other sort of traditional bookseller sites. Correct?

    Sharma: Absolutely. This is my first retail book. The first book that you mentioned, “DevOps for Dummies,” was a free book we were giving away, sponsored by IBM. So to me as an author, when the book came out and I knew it would be available, the first thing I did was drive to the nearest Barnes & Noble, which actually is 15 miles from my house, just to go see the book on the shelf. So yes, it is available at all major booksellers, both as a physical book and as an e-book.

    Shimel: Let me ask, and I think I probably know the answer. Did you take a picture, a selfie of yourself with the book on the shelf behind you?

    Sharma: I wanted to do that, but the book was placed at a very awkward angle, so I couldn’t get myself into it. So I just took a picture of the book sitting there with the other books. And, you know, it’s not a selfie if you give the camera to somebody else. This was in the middle of the day. They were letting nobody in the bookstore. It was pretty hilarious. I wish I had videoed the whole thing.

    Shimel: Very cool. Sanjeev, people can get the book. They can see you for themselves. Also, I will mention that it’s the kind of book where if there’s something specific you’re looking to hone in on, a particular issue, problem, topic you’d like to delve into, the table of contents and the way it’s laid out makes it very easy to do so. So you could use it to kind of pinpoint in the kind of thing you’re looking for, or you can take it as an overview around the whole book. Either way it’s pretty good.

    Sharma: Thank you.

    Shimel: But, Sanjeev, there are a couple of terms in the book that I’d like to – one of the things is you talk about this concept of fast waterfall. It was mentioned in there a few times and I’ve seen others mention it.

    Sharma: Sorry. [Audio breaks up]

    Shimel: Did I break up there? I apologize.

    Sharma: Could you repeat that?

    Shimel: Sure.

    Sharma: I’m sorry.

    Shimel: Sanjeev, you talk about this concept of fast waterfall. Did you hear that?

    Sharma: Yes, I did. Thank you for repeating that. We were seeing a very broad spectrum of maturity levels and a spectrum of business needs, and we go with clients and see how they adopt DevOps. So when I go into an organization, no organization is monolithic. No organization is homogenous. You see one part of the organization where nothing is broken, things are going fine, but they’re using a very old-school waterfall approach to delivering systems.                           

    So the question that arises is: What do you do there? Do you disrupt something that is working during maintenance, more to try to introduce agile principles or try to introduce continuous delivery? Or do you just make what they are delivering more efficient?

    My thesis in the book is that you focus on optimization. You look at the delivery pipeline. You do what we call a value-stream mapping, and look at where the waste is, where the bottlenecks are, and look towards eliminating or mitigating those, without necessarily needing an end-to-end sea change to say, “No, you have to stop what’s working for you. Your business doesn’t need you to go any faster. Your business doesn’t need you to be more innovative because this is an application in

    – but you have to disrupt it.”

    That all or nothing approach does not work. It is also very expensive. So how do we make it more efficient? I don’t like the term “fast waterfall.” I would like to call it “optimized waterfall”. You focus on optimization. Yes, eventually your goal should be to move to full Agile. You goal should be to move to continuous delivery, but you cannot do that day one. You cannot do it across every project, every system and every application at the same time, but you can do some things to start everybody on that optimization journey.

    That is to me what I am referring to in the book. Get started. Get started where you are. Understand your end goal. But you don’t have to get there at light speed. You don’t have to get there yesterday and you don’t have to get there all together. You have to make that business decision of how much change to introduce, how much change you can consume, and how much change you can afford at this time. Maybe not today, maybe you can only do it next year. So that’s summarizing some of the thinking behind what you’re really getting ready to do.

    Shimel: Understood. Sanjeev, you mentioned value-stream mapping. That’s a workshop that I’ve seen you perform over the years and it’s great. If anyone ever gets a chance to sit in on one of your value-stream workshops they absolutely should. Can you give us just a little bit of an idea of what’s involved with that?

    Sharma: Sure. Value-stream mapping, I would add, as an exercise is nothing new. It’s been in there in the Lean movement since the last century, probably since the 1950s. It’s a technique by which you look at processes and you try to figure out where there might be some waste, and then do a root cause analysis to determine why the waste is there and make a plan to mitigate it.

    So in DevOps, if you look at your delivery pipeline as a value stream, that requirements are coming in at one end and code running and production being used by a user, getting business value at the other end, we do a value-stream mapping to look at where the waste is. So we look at artifacts going through that delivery pipeline.

    What are those artifacts? Who are the stakeholders who touch those artifacts and perform actions on them, who do processes on them? How does the transition happen from one stakeholder to the other? How does the artifact get transformed as it goes from one stakeholder to the next? What environment or tool or repository does the artifact live in and is it consumable?

    There’s a concept in Lean called percent complete and usable, which tells me: when I get an artifact, can I use it as _____ to consume it? Are the requirements coming from the business usable by developers? Is the code coming from developers usable by the testers or whatever? Are there manual tasks which are causing waste? Are there tasks people are doing which add no value to the product? They don’t add any business value, like status reports. They have some value, but are the status reports really being used to progress the product or are they really being used because some needs a view, and they have to spend time creating those reports rather than having a real-time dashboard somebody can just look at?

    So a value-stream mapping exercise and what you’ve seen is a half-day version of a workshop we do with clients, where we go in and take one project of theirs and do a value-stream mapping to get an idea of where the waste is. Many times, actually more often than not, we do it at a division or a program or a line of business level and look at for that line of business: What does the value stream look like and where are the bottlenecks? Where is the waste?

    Then we spend some time doing root cause analysis on each bottleneck we identify. Then we go away and come back with a recommended adoption plan of what DevOps practices and capabilities and tooling, and organization change also, would we recommend to help mitigate those bottlenecks. So it’s a very powerful exercise we do.

    I have an entire section dedicated to it in my book. And on YouTube, if you Google, search for DevOps Whiteboard, you will find me doing a mock value-stream mapping also. There’s a 30-minute video of me doing it with one of my colleagues. So it’s something we’ve had a lot of success with and I think it’s something every organization should do.

    Shimel: I agree with you and I have seen the video. Sanjeev, we’re almost out of time. I wanted to just pivot from the book for a moment and talk a little bit about InterConnect. IBM’s InterConnect this year is coming up in about two weeks. I know you’ll be appearing there and I would imagine the book is involved in what you’re talking about. Yes?

    Sharma: Absolutely. IBM Press was the publisher of the book along with Wiley. On Wednesday afternoon we will do a book signing. They’ll set one up. So if you have a book, if one of your listeners has the book, they can bring it there. I’ll be more than happy to sign it and have a chat with them. They will also be selling the books there at the IBM Press store.

    And I am told—I don’t know if I’m even supposed to tell this, but if you come to a DevOps session, a track in the DevOps session, in some of the sessions we’ll be doing some surprise giveaways of books also. But don’t tell anybody that.

    Shimel: No, of course I wouldn’t.

    Sharma: It’s one big secret. No, no, no. Personally, I am doing three sessions, one of which is a panel with customers, and there are two other sessions related. Both of them are topics I picked out of the books, individual chapters from the books. One is on building a business case for DevOps, and the other one is a risk-based model to adopting DevOps.

    Then the third is a panel, and the fourth is a workshop I’m doing on driving innovation. So it’s kind of broader than DevOps. That’s going to be an hour-and-a-half workshop. So it’s going to be a fun few days and I look forward to meeting your listeners there.

    Shimel: Absolutely. You know what? We’ll try to get some links to these in the transcript and notes on this podcast.

    But for now, I think we’ll call it a wrap on this DevOps Chat. Sanjeev, congratulations on a great book here. I mean “DevOps for Dummies” was certainly a great read, but this is a book. Kudos to you and the team. You put together a really nice how-to here. I’m looking forward to hearing and seeing you at InterConnect. Of course we run into each other quite a bit during the year and I’m sure we’ll continue to do so.

    Sanjeev Sharma –

    Sharma: Absolutely, Alan. Thanks a lot for having me and I looking forward to chatting again soon.

    Shimel: Absolutely. Sanjeev Sharma, “The DevOps Adoption Playbook,” a new book out, definitely pick it up, by Wiley Press and IBM Press. Sanjeev, thanks for being on DevOps Chat today and we’ll speak to you soon.

    Sharma: Thank you for having me, Alan. I’ll speak to you soon.

    Shimel: Okay. This is Alan Shimel for devopsy.kinsta.cloud and we’ll see you soon on the next DevOps Chat.

    — Alan Shimel

  • DevOps Chat: DevOps and Databases w/ Steve Jones, Redgate

    DevOps Chat: DevOps and Databases w/ Steve Jones, Redgate

    In this DevOps Chat, our guest is Steve Jones of Redgate and SQL Server Central. Steve talks to us about DevOps and databases, as well as the latest from Redgate SQL Clone. More and more we are hearing from DevOps teams that the database is becoming a constraint. We must take DevOps to the database!

    As usual, the streaming audio is directly below, followed by the transcript of our chat. There also is a link to a downloadable white paper from Redgate for your reading enjoyment.

    Streaming Audio

    Chat Transcript

    Alan Shimel: Hey, everyone! Alan Shimel, devopsy.kinsta.cloud, here for another DevOps Chat. This episode of DevOps Chat features Steve Jones of Redgate. Steve, welcome to DevOps Chat.

    Jones: Thank you, Alan. It’s good to be here.

    Shimel: Thank you. So, Steve, you are in—well, you have sort of a dual role in that you’re an evangelist with Redgate, but you’re also the, I don’t know if you wanna call it the curator, the editor, the manager—

    whitepaperJones: The founder. [Laughter]

    Shimel: – founder of—

    Jones: SQL Server Central.

    Shimel: – SQL Server Central, exactly.

    Jones: Yes.

    Shimel: Before we jump into SQL Server Central, though, you know, I’m sure there are people out in our audience who may not be familiar with Redgate, so let’s give them, if you can, just a quick kind of elevator story pitch on who Redgate is and where they fit in in the DevOps world.

    Jones: Okay. Well, Redgate has been around about 17 years, and really, we, our tagline kind of is, “We build ingeniously simple tools that help you build software.” So our goal is to help you build database software or .NET software in a more efficient manner. So that’s kinda the quick pitch on what Redgate does.

    Shimel: Got it. And how—give us a little more background. How long has Redgate been around?

    Jones: So, Redgate started right around 2001, and interestingly enough, SQL Server Central started at the same time. Myself and a couple partners put together this publishing area where we wanted to help people get better at their jobs and grow, and Redgate was actually our first customer and we sold advertising to them back in 2001.

    Shimel: Oh, cool.

    Jones: So I’ve known them almost since the beginning. And over the years, they’ve—Redgate has grown up. We’re now around 300 people or so. We have our main office in Cambridge in the UK, and then we have a sales office in Pasadena (California) as well, and we have a few people, then, like myself scattered around the world that do various jobs.

    And so, across the years, Redgate has tried to help different groups build software better. You know, we sell to a lot of Fortune 100, Fortune 1000 companies all over the world, and over the last probably five or six years, we’ve tried to tackle the DevOps problem in the database world. So we’ve spent a lot of brain power, a lot of effort to build products to try to help people incorporate the database into a DevOps flow.

    Shimel: Mm-hmm. So, you know, that kind of pre-empts my next question, Steve, which was, you know, obviously, when Redgate first started up here, there wasn’t people running around talking about DevOps, though people were still trying to do more faster and automate and all of these things.

    But it’s been about four or five years, you think, where you guys have kinda consciously said, “Oh, we’re gonna, you know, try to hit the DevOps mindset,” if you will, or the DevOps [Cross talk]?

    Jones: We are, yeah. You know, our founder—so, an interesting story. At the beginning, when he was looking for some additional money to get the company going, we had built our first product called SQL Compare, which compares the scheme of two different databases and gives you the differences and generates you a script so that you can do a deployment.

    And, in trying to explain this to the laymen, to the managers, to the people that would be bankers or sign checks, it’s kind of a cumbersome process, right? The idea of a schema and comparing that is a fairly technical area; I think a lot of people don’t intuitively understand that. But he brought in two phone books to the customers and said, “Find me the differences between these two,” you know? And they’re like, “I don’t know how we do that,” right? [Laughter] “Like, we go page by page and we lick this out?” And he said, “This is what our product does—it finds the differences between two things and lets you know.”

    And that’s where we’ve gone over the last 17 years. We’ve matured that product and then, five or six years ago, we decided to find ways to make it even better, and so we spent time looking at how people perform the deployments, some of the shortcomings sometimes of having somebody run a particular product to determine at this point in time what are the differences. And so we’ve built automation, we’ve built some of the other security ideas, some of the things you do in DevOps to produce a flow into various products so that we can ease the pain of deploying database changes.

    Shimel: Makes sense, makes sense. So, Steve, you know, we’ve seen Redgate and a few others really kinda not attack, but really work hard to bring the database and the DBA into the DevOps environment, into the DevOps family, if you will, right? You know, we talk a lot about culture and so forth in DevOps and we try to bring—break down silos, bringing teams together, bringing dev together with ops, bringing QA into it, bringing security into it, and bringing the DBA and the database into it.

    And, you know, I personally have seen this become a bigger and bigger piece of the DevOps puzzle. How—now, Redgate had a lot of success before that, right, and—

    Jones: Yes, yes.

    Shimel: – Yep, so my—I guess my question is, where are you seeing this uptake or, you know, DevOps—so your business was, it sounds like it was good before this. Is it really kinda hitting where—you know, or has it found that sweet spot with DevOps?

    Jones: You know, it’s getting better. I gotta say, five years ago, when I started to try to talk about doing deployment—so, we started a product years ago to do deployments to try to help people do web deployments, and we wanted to include a database in that. And we found it was a much more difficult problem than we expected, and you know, one of the things that we found as we worked on this is that, you know, DBAs, I think—more than ops, more than J, more than security, more than any other group, we fundamentally have a challenge that they don’t have in that we have to maintain state between deployments.

    In the ops world, right, they say that we wanna treat our servers like cattle—if one dies, we just pop another one up in its place and we go. Certainly we do that with containers, we do that with software, we can—you know, the QA people are used to doing that. But, you know, in the database world, we can’t do that, you know? If I could drop tables and recreate them every time I deployed software, my life would be so easy. [Laughter]

    Shimel: [Laughter] [Cross talk]

    Jones: Yeah. [Laughter] But you know, I think over the last decade, we’ve started to see in many industries, many businesses that the data is really, hugely important. You know, and as we see people moving to machine learning and AI and all these different things, the database fundamentally becomes even more important, because that data is required, you know? And whether you’re relational NoSQL or something else, you have to maintain that data as you make changes.

    And so we have this fundamental issue that we have to find ways that we can make changes without disturbing the state of our system too much. And that’s a difficult process, right? If I deploy the wrong .dll or the wrong XT or the wrong .jar file, I drop it and I throw the last one I have up there and we’re good. If I deploy the wrong version of a database, if I make a fundamental change to a table and it’s the wrong change, maybe store, which could be hours, minutes out, you know, who knows—you’d have to substantially try to reverse a change, which means, if any data has been altered, I have to try to undo that, I’m gonna have to capture that statement and then go through some sort of ETL transform to put that data back.

    It’s extremely risky and cumbersome, and you know, as a former DBA as part of my career, you’re risk averse. You don’t want to be in that place where you take the database down for substantial periods of time. So, you know, Redgate really, as we were trying to find new products to build and sell and try to enhance what we had, we realized this was a difficult process.

    Shimel: Mm-hmm.

    Jones: And so, five years ago, I talked to people, they thought it was done, they didn’t think it could be solved, and I’ve had a number of good friends that laughed at me three years ago, four years ago, and you know, in the last year, year and a half, they’ve been coming back to me and saying, “Alright, how do we actually get this database into a DevOps process and deployed?”

    Shimel: Yeah, fair enough. So, Steve—well, first of all, what’s the latest news ? Anything with Redgate?

    Jones: Absolutely. So today, actually—you know, we’re recording this from February 27th—Redgate has released SQL Clone, which is a product similar to some other ones in the marketplace, but it’s designed to provision copies of databases in seconds. So, what we essentially do is, we build an image file of your database, and then we can make real live copies of that in literally seconds.

    So if you’ve got a 1 terabyte database, once I’ve provisioned that image, I can make 1 terabyte copies of a SQL Server database and have it appear on your instants in about 7 to 10 seconds. And every copy is independent, they all look the same, they all look like the original database. You can write to them, you can change things, and you can drop them and recreate them in seconds.

    So, in the Dev/Test world, it’s a fantastic idea that I can provision a developer database in seconds, they can be on their own branch, they can make any changes they want structurally to the data to alter things. And if they decide they’ve made a mistake, as we often do in development where we experiment and we try something and if we want to undo it, they can drop that database, build another 1 terabyte database in seconds and continue with their development.

    Shimel: Got it, got it. Steve, I wanted to spend a little time talking about your role as evangelist with Redgate.

    Jones: Okay.

    Shimel: So, you know, evangelist is not—what’s the word I’m looking for? It’s not an unheard position within the DevOps world, but can you give our audience a little bit of a flavor of what your role entails, especially in dealing with the DevOps marketplace?

    Jones: Sure, sure. So, I—as an evangelist, what I end up doing is a lot of writing and speaking about Redgate and Redgate products, and certainly the DevOps world, but also just in general about good practices of software development and database administration.

    I’ve been working with SQL Server for Microsoft for 25 years, so I’ve been—basically since Microsoft has had the product, I’ve worked with it as part of my career, and you know, the mission of SQL Server Central is really to help you get better at your job every day. And so I do a lot of writing and speaking to that effect, and you know, Redgate is essentially all over the world, so I get the chance to go to different conferences, different events, and provide information about general good database practices or Redgate products in particular.

    Shimel: Excellent. Steve, we’re—as I mentioned here before, we got on, you know, live, the time here goes quickly. But I wanted to know if you can give our audience—well, first of all, where can they go to your SQL World blog? How can they find that?

    Jones: Yeah, so SQLServerCentral.com—all one word, SQLServerCentral—that’s the site where I’m kinda the editor, I was the founder, and I run that right now. So we publish daily information to help you there.

    I maintain my own blog at VoiceoftheDBA.com—so VoiceoftheDBA.com—and that’s where I write about a variety of topics related to data and databases and software in general. So, do that, and then on Voice of the DBA, I keep a speaking schedule, so I’m traveling all over. I head to Colorado Springs in about three weeks, and then SQLBits in England, and various places after that, so. [Laughter]

    Shimel: Got it. What about—and what about Redgate? Any plans for conferences, shows, DevOps events where maybe our audience—you know, our audience is pretty worldwide, Steve, if I didn’t tell you before.

    Jones: Okay.

    Shimel: Places where they might see Redgate?

    Jones: So, we’ll be—we go to a variety of DevOps conferences in the UK and the U.S. and elsewhere, so we will be at SQLBits in Telford in April, and then we’ll be at the Data Platforms Summit in Bangalore, and I’ll be there as well. And I don’t know all of our marketing presence where we’re gonna be beyond that, but you know, we have a good, active Twitter account at Redgate, and we post on there often where we’ll be with different events, so it’s a good place to find us.

    Shimel: Excellent.

    Jones: And of course, Redgate.com. [Laughter]

    Shimel: Yeah, well, that makes sense. So, Steve, we’re almost at the end of our time here. I wanted to ask you one last question, it’s one I ask a lot of our guest, and it’s this—if you had to recommend one must-have book, one must-read book for our audience out there, maybe regarding DevOps and databases or something related, what would it be?

    Jones: So, yeah, we talked about this briefly. I know probably everybody has thought about, talked about “The Phoenix Project,” which is great. If you haven’t read “The Goal,” which is kinda the precursor to “The Phoenix Project,” that’s good.

    But the one I might recommend is “Database Refactorings” by Pramod Sadalage, and it’s interesting because there’s a domain of problems in the database world that are complex and they’re problematic. And so they are the types of problems where you can’t easily make a change and undo it, you know? If I had a column, then I could drop it very quickly—but there are certain problems that are difficult.

    And in the “Database Refactoring” book, they’ve done a good job of laying out these problems and how you solve them across time, because most of these require you to make changes across maybe days, weeks, or months to actually complete them—so that might be the one I’d recommend.

    Shimel: “Database Refactoring”—great. By the way, I loved “The Goal” as well. I read “The Goal” many, many years ago—way before “Phoenix Project.”

    Jones: Yeah. Right—I did, too. That was the first one I read.

    Shimel: Yeah, it was good stuff—but “Database Refactoring” sounds good.

    Steve Jones, it was nice having you here. This is obviously your first time appearing on DevOps Chat, but we’d like to have you back in the future maybe again, and we can talk some more. And you know, I really do like to delve deeper into databases and DBAs and, you know, adopting and being adopted into the DevOps kinda methodology and work routine in many organizations. So maybe next time we could dive a little deeper.

    But for now, I think we’re about out of time.

    Jones: Okay. Thank you very much for having me, Alan.

    Shimel: Steve, thank you for appearing. Steve Jones, evangelist for Redgate, and the founder of SQL Central—is that, did I say that right?

    Jones: SQL Server Central.

    Shimel: Excuse me—SQL Server Central. Steve, I apologize.

    Jones: Yeah. No worries.

    Shimel: Steve, until next time, then, we’ll have you on, and continued success with both SQL Server Central and Redgate.

    Jones: Thank you very much. Great being here.

    Shimel: Thank you. Hey, this is Alan Shimel for DevOps Chat, and we’ll see you on the next DevOps Chat.

    — Alan Shimel

  • Building a Bridge from Agile to DevOps, Scrum.org Partners with the DevOps Institute

    Building a Bridge from Agile to DevOps, Scrum.org Partners with the DevOps Institute

    Scrum.org, which is dedicated to improving the profession of software delivery, and the DevOps Institute, which is dedicated to fostering a community around emerging practices in Continuous Delivery and DevOps, today announced an alliance that seeks to build a bridge from agile to DevOps. It will include scrum teams, agile practices and DevOps. I think this partnership could have huge implications for both the Agile/Scrum and DevOps communities.

    Let me say from the outset that I am a co-founder of the DevOps Institute, so feel free to take what I am saying (or writing) with a grain of salt. I also have been involved in the formation of this partnership since its initiation. From then until now, I remain convinced that this is a critical step in making software development and delivery better for us all.

    My fellow co-founder at the DevOps Institute, Jayne Groll, perhaps says it better: “There is an inherent organic relationship between Scrum and DevOps. By demonstrating how to improve the collaboration, integration and communication between IT’s roles, frameworks, practices and automation, we pave the way for end-to-end organizational agility and a faster flow from idea to value.”

    While formulating this partnership, I have had the chance to meet and work with some incredible people over at Scrum.org. One of them is Dave West, CEO of Scrum.org. When I first met Dave (you can hear a podcast of that here), he was just formulating his ideas around Agile/Scrum and DevOps being intrinsically linked. Since then, Dave has seen a clear path for this linking and has embraced and enunciated it well. “Scrum without DevOps is impossible to scale. Work needs to flow seamlessly from the Scrum team to production and back again,” Dave says. “It is funny that great Scrum teams have to do DevOps to be great and great DevOps teams use an agile approach like Scrum to enable better collaboration.”

    For me, the real value of this partnership is, as Dave so eloquently states: “I am always shocked that the DevOps community are often seen as different from the agile and Scrum communities, when the reality is that agile and DevOps encourage breaking down those barriers to deliver customer value.”

    At the end of the day that is really what this is all about. The partnership is not just about Scrum.org and the DOI as institutions & organizations—the partnership really has to be about the community of IT professionals who adhere to and practice Agile/Scrum and DevOps.

    As I like to tell people, there is only one truth. There is not a separate set of facts that apply to Agile/Scrum and another set that apply to DevOps. There is not a separate truth that applies to enterprises and another truth that applies only to startups. There is only one truth. If it is truth, it is true. I look forward to this partnership illuminating and standardizing on this one truth.

    By the way, this alliance is just the beginning. I believe that this “one truth” philosophy applies beyond Scrum and DevOps. I think it also applies to ITSM, security and other IT disciplines. Bringing together a common set of best practices and way of doing things across these is inevitable.

    We have crossed a boundary in IT. As I write this, I am at the InfoSec World conference in Orlando. My friend Rich Mogull is delivering a keynote where he is talking about how infrastructure as a service, software as a service and the new reality of ubiquitous, safer endpoints and connectivity are changing the mission of the security professional. These same factors are changing the mission of the Agile/Scrum developer and the DevOps team member. It is a great time to be in IT.

    But it also calls for forward-thinking organizations to recognize, adopt, adapt and evolve. I think this is a great opportunity for organizations like Scrum.org and the DevOps Institute to help lay out a path for common learning and uniting communities. That is what really gets me so excited about this partnership.

    So what are ways for you to find out more and be involved in this? Well, it starts  April 26 in Dallas at the DevOps Connect conference. Dave and Jayne will be delivering a joint keynote and a full afternoon workshop. These sessions will be listed under the “ScrumOps” moniker. If you are in Dallas or can get there to attend DevOps Connect, please do so.

    Dave’s blog lists some other ways this partnership will work together:

    • Consistently describe the ideas of each body of knowledge through Scrum.org and DevOps Institute classes and certifications – providing consistent words and concepts to help ensure that both groups can share a common dialogue.
    • Shared events that bring together the two audiences to create an environment that allows ideas to be exchanged and new ones to grow. It has always seemed odd that DevOps and Scrum/Agile events are separate. It is crucial that the two groups work together and that we as one.
    • Invest in a growing body of thought leadership. Scrum has a very precise, documented body of knowledge with the Scrum Guide, but there is much ‘mystic’ in the DevOps and agile community about certain terms and ideas. DevOps Institute is already working with DevOps Express on building standard patterns and terminology. By working with the DevOps Institute, we can start bringing in the concepts of professional Scrum so that the entire software delivery team can work together as one.

    So stay tuned for more info on this partnership in the coming weeks and months. In the meantime, today is the first day of Scrum/DevOps working together in ScrumOps.

    — Alan Shimel

  • DevOps Chat: Purpose Built Appliances for Containerized Applications with Diamanti’s Mark Balch

    DevOps Chat: Purpose Built Appliances for Containerized Applications with Diamanti’s Mark Balch

    Back in my StillSecure days, building purpose-built appliances for security was all the rage. Over time, though, security-as-a-service captured much of the market (although security appliances are still a big seller). For containerized applications, you may think cloud is the way to go. But the folks at Diamanti say that purpose-built appliances for containerized applications are a superior option.

    I spoke with Mark Balch, their VP of product and marketing about this, and he gives us Diamanti’s views here and, frankly, makes a good case. It is early in the containerized application market and the winners are yet to be crowned. Mark tells it better than I can. Have a listen and let us know what you think.

    As usual, the streaming audio of our conversation is below and the transcript of our conversation is below that.

    Streaming Audio

    Written Transcript

    Alan Shimel: Hey, everyone. Alan Shimel, devopsy.kinsta.cloud here for another episode of DevOps Chat. Very happy to be joined today on DevOps Chat with Mark Balch, VP of products and marketing at Diamanti. Mark, welcome to DevOps Chat.

    Balch: Hey, Alan. Thanks for having me. It’s great to talk to you.

    Shimel: Thank you, Mark. So, Mark, let us first start off with Diamanti. I think that’s a fairly new company to our audience or at least to us here at devopsy.kinsta.cloud, although the company itself is not new, but, for those of our listeners who may not be familiar, why don’t you give us a little background?

    Balch: Yeah, definitely. We’ve been around since 2013, and Diamanti spent the first couple of years in stealth mode, as you may say, building our product. And we launched the company last year. We just launched our GA product this past week, in February.

    And just a very quick background or why are we here. Well, we saw the container revolution occurring. We believe that containers are the next mainstream application platform for new cloud-native applications, moving forward. And we’ve seen that users are spending a tremendous amount of time and money trying to custom-engineer their own infrastructure and figure out how to make cloud-native applications operate at scale, with reliability and performance. And we said that, “You know, we wanna make sure that users can do this out of the box, very simply, get control of their costs and be able to focus their time, instead of reinventing the wheel and infrastructure, on building the unique business applications that they’re being measured on.” So that’s why we’re here.

    Shimel: Excellent. And, you know, Mark, what was interesting is, at a time when we’re seeing software-defined everything, right, Diamanti’s out here with a purpose-built appliance for containerized applications. And I would imagine there are many people who say, “Oh, no, we don’t wanna sell hardware.” But, really, if you want control over your environment, you don’t have much of a choice.

    Balch: It’s a real tricky situation for a lot of users, right, because just go out there and spend a little bit of time searching on the web and going to meetups and looking at user testimonials about the challenge of being able to get reliable performance at a reasonable cost point in the traditional model. It’s really very difficult. People spend a lot of time custom-engineering, and that’s time that they can’t spend building their unique services. So, for us, really, it’s a very simple value proposition.

    We’re not saying that you have to customize your application or do anything proprietary; what we’re saying is that, “Continue to go with your open-source approach—standard Docker images, standard Kubernetes orchestration, standard Linux—but operate on a platform that is going to give you the automation of getting that entire application deployed properly, that’s gonna give you predictable performance and outcomes and that’s gonna let you run at a reasonable cost point.” I mean, people have massive bills, whether it’s public cloud, whether it’s looking at virtualized traditional infrastructure that was built for a different type of application. People spend a tremendous amount of time and money trying to get cloud-native applications working, and our goal is to make sure that people can get those applications working within minutes, not within weeks or months.

    Shimel: Sure. And that is the advantage of having that sort of purpose-built platform. Mark, I wanted to, first of all—you know what? Shame on me. I didn’t even ask. Can you give our audience a little bit of the background of who you are, though? And I’ve said your title, but who’s Mark Balch and how did you come to Diamanti?

    Balch: Yeah. That’s a good question. So I’ve been in the IT and application industry for 20 years. I started off my career as an engineer. I love doing development work. I love to build things. I love to deliver great products that have an impact. And then, somewhere along the way, I got into product management because I wanted to figure out whose job was it to make sure that we’re building the right products at the right time, that it could solve real needs. And so, for the last more than 10 years, I’ve been focused on product management and product marketing, doing everything from data center automation and application provisioning software to cloud automation software, and, now here at Diamanti, focused on the open-source side of application development and, again, focusing more on the outcome. Whether we’re talking about an appliance, whether we’re talking about software you can deploy, at the end of the day what I care about, as a product manager, is making sure that there’s a value at the end that’s gonna make someone’s life better, that’s going to give them a greater experience in being able to be personally successful in getting their applications into people’s hands. So that’s what motivates me.

    Shimel: Great. Appreciate that. Mark, if I may, I wanted to take a moment and talk a little bit about Kubernetes. There are obviously choices for container orchestration and container management out there, and it seems like Diamanti has clearly put their chips in the Kubernetes market. As I said, there are other choices. Can you give us a little bit of the background on why Kubernetes and—or maybe I’m wrong. Can Diamanti customers choose other container orchestration options as well?

    Balch: Yeah, you know, I think, when it comes to talking about container formats and orchestration, I think we all have to be a little humble, in that the market is still very early and very dynamic. There’ve been so many changes. Kubernetes is doing a great job. Mesos is doing a great job. Docker’s doing a great job. You’ve got now standardization happening in the Cloud Native Computing Foundation for the Open Container Initiative. So I think, honestly, it is too early to call a winner, and I think all of us have to make sure that we’re giving users choice in working with an open ecosystem. It’s not about forcing people down a particular path; it’s about giving people options. Right? So we can work with a variety of different options, but let me tell you why we have been doing a lot of work with Kubernetes. And we’ve been doing this work with Kubernetes for the last couple of years.

    Kubernetes, from a governance perspective, has been a great ecosystem to work with. Obviously, Google contributed that code to The Linux Foundation last year, and you’ve got large and small contributors from all over the ecosystem, including Diamanti, contributing to make Kubernetes bigger and better and more extensible. So what attracted us to work with Kubernetes early on was that governance, where, really, anyone could come to the table. Everyone has been welcome to pitch in and to take leadership roles, frankly. For example, Diamanti contributed something called “FlexVolume” into Kubernetes. It was upstream; it was a year ago. And we were welcomed with open arms, and now there are, literally, more than two dozen members in the storage SIG who we work with. Same thing around scheduling for Kubernetes—we upstream contributions there. Working with CNI, container network interfaces, is another example.

    So we’ve just seen a lot of great governance and a lot of extensibility, where the Kubernetes community seems very focused on this concept of extensibility, where it’s not that my solution is better than yours; it’s that we have APIs that we can use to extend different options and then users can pick and choose what’s gonna work for them, but it’s supported with a common framework. So that’s what we love about Kubernetes.

    Shimel: Got it. Interestingly, Mark, in our several studies, surveys on this with our audience, overwhelmingly—well, not overwhelmingly ’cause, actually, Mesio was pretty close, but Kubernetes clearly was the choice among our audience for container management and orchestration, so probably not a bad move there. Mark, what about people who have invested in public cloud infrastructure for containers? What’s the Diamanti value proposition to them?

    Balch: That’s a really good question, Alan, and people ask us that a lot. And, by the way, I’ll say that Diamanti is gonna be at the Google Cloud Next Conference next week, so we—

    Shimel: Really?

    Balch: Yeah, so we actually do a lot in terms of public cloud, okay? So I think the first thing is that it’s back to that concept of choice and no vendor lock-in. We need to make sure that we’re all offering users capability—we’re not trying to force them down a path with something that is proprietary—so everything we do at Diamanti is standard Docker runtime, and, as that evolves and maybe we have more standardization around runtime, that’s gonna evolve into making sure that everyone participates in the standard format. So, if you develop an application and you’re using Google Cloud or using Amazon or Azure or someone else, one of your goals, probably, should be to do it in a way where you can be portable, where you’re not locked in, where you can bring it to another provider if that provider offers you better economics, better performance, better reliability, data governance, things like that.

    And that’s where we come in. You could think of Diamanti as a provider, but we are an on-premises provider. We allow users, like MEMSQL or NBCUniversal, to be able to build an on-premises private cloud that is fully open source and you can take your existing containers, you can move them onto Diamanti, you can get all the great performance and automation benefits that we talk about. If, for some reason, you wanna go elsewhere, you wanna go to Google, to Amazon, somewhere else, we don’t stop you. You can do that. You can go back and forth, right? So we wanna make sure it’s very easy to go back and forth so that the user is in control of deciding what’s more important to them, in terms of all those things like governance, data sovereignty, performance, and economics.

    Shimel: Sure. Do you envision a time when people sort of have hybrid Diamanti-public-cloud containerized applications?

    Balch: Yeah, that’s a good question and actually brings up a really—another good wrinkle around Kubernetes. Kubernetes has an emerging project called “Ubernetes,” or its formal name, “cross-cluster federated services.” Now one thing I will say—I love the Kubernetes community, but sometimes, from a marketing perspective, we could do a little better. “Cross-cluster federated services” doesn’t really roll off the tongue very quickly, but what it means is, essentially, it can mean hybrid cloud or multiple availability zones.

    And so, just like Diamanti has made upstream contributions to the community around scheduling, we can now extend those scheduling capabilities, using Ubernetes, so we can move that across the availability zones and into hybrid cloud scenario. Right? So I definitely envision a scenario like you’re talking about, where you can have multiple Diamanti clusters in different data centers, you can have availability zones up in Google or Amazon or Azure, and you can, basically, allow the cross-cluster federated services to figure out where to deploy that application based on your performance requirements, on your sovereignty requirements, on your compliance requirements, or you can say, “Hey, I wanna make sure this thing goes into public cloud,” or, “I wanna make sure it goes into my Los Angeles data center with Diamanti.” You’re in control of that, from a policy perspective, and that’s, I think, what’s really interesting about the cross-cluster federated services road map, moving forward.

    Shimel: Absolutely. And you’re right; that does just roll right off the tongue. But, look, they’re engineers; they’re not marketing people. Mark, let me ask another question, and, not to hold your feet to the fire, but, for people who may be interested at home, can you give us sort of a ballpark pricing on Diamanti?

    Balch: Yeah, absolutely. So we’ve announced our pricing. Each Diamanti appliance has a list price of about $40,000, slightly under that, in fact. Obviously, discounts apply. So we are highly competitive with all alternatives, whether you look at commodity, whether you look at converged infrastructure, hyper-converged infrastructure. We are highly competitive from a price perspective. And then, when you look at the consolidation and the time savings, frankly, there is no competition there. So, certainly, love to chat with any of your listeners who are interested, and I pretty much guarantee, from an economic perspective, it’s gonna work out great.

    Shimel: So that brings up—you opened that box, Mark. For any of our listeners who may be interested in finding out more about Diamanti or speaking to someone, is there an e-mail address or a web address where they can check it out or contact someone?

    Balch: Yeah, definitely. So please check out our website, it’s www.diamanti.com, or just send us an e-mail, info@diamanti.com. We can get you set up really quickly.

    Shimel: Okay. Mark, we’re running low on time, but I did want to just mention that Diamanti is sort of riding the wave, if you will, of this tremendous momentum building up behind containers and micro-services and Docker, Kubernetes, etc. Where in the adoption cycle do you think all of this is? Has it really gone mainstream yet or are we still at the early-adopter stage?

    Balch: That’s the multibillion-dollar question, so we are seeing adoption all over in different kinda fits and starts, to be honest with you. So the industries we see the most adoption, Alan—we see media moving quickly. We actually do see financial services moving quickly. We see web infrastructure. We even see service methods moving ahead, wanting to offer containerized services and competing with the large public-cloud vendors. So where we see containers happening is developers are downloading Docker on their laptop; they’re able to accelerate their application lifecycle and development processes. Operations is a little slower. To be honest with you, it is lagging a little bit behind. That’s where we come in—we’re working with ops teams to help them get off the ground—and, just like always, developers ultimately have the influence where they’re defining application architecture, and then they work with their ops teams to figure out how to get those architectures deployed successfully into production.

    So there are lots of different numbers out there—451 Group had some good numbers; I’ve seen numbers from Forrester and from Gartner. The industry’s still early, maybe at only about 10 percent of adoption, and that’s a very anecdotal number, but it’s growing really quickly and we’re seeing a lot more inbound requests now because everyone’s trying to learn about it. The cat’s out of the bag; it’s not a secret anymore. And I think either people are doing it today or they see it coming quickly and they wanna figure out, when it comes down the pipe from their development team, how do they be successful with containers and actually make it work for their business.

    Shimel: Got it. Got it. Sounds great. Mark, we’re actually way over time. I apologize to our listeners and to you, but I thought we had some good information here and I didn’t wanna cut it off, but we need to wrap up. Mark Balch, thanks so much for being our guest today. Continued success with Diamanti. It sounds great. And, obviously, through Container Journal and devopsy.kinsta.cloud, this is a space we watch pretty closely, and I’m sure we’ll be hearing more from Diamanti soon.

    Balch: Thank you so much, Alan. This has been a great conversation. I appreciate it.

    Shimel: You know, one last thing. Mark, I forgot to mention. You mentioned you were going to be at the Google Cloud conference, which is the week of March 9th, something like that, right?

    Balch: Yep.

    Shimel: In March 8th and 9th?

    Balch: Yeah.

    Shimel: And then –

    Balch: March 8th through 9th.

    Shimel: – DockerCon is next month in August – in Austin.

    Balch: April.

    Shimel: In April.

    Balch: Yes. We will _____.

    Shimel: You’ll be there as well.

    Balch: Yep. Definitely gonna be there, yep, and we’ll also see you at OpenStack Summit, so we’ll be at Google Cloud Next in March, DockerCon in April, and Open Stack Summit in May.

    Shimel: And I think that one was in Boston?

    Balch: It is in Boston this year. That’s right.

    Shimel: Yes. Okay. Hey, we actually have some DevOps Connect events going on in Boston, Austin, and Chicago, but for another day. Mark Balch, Diamanti, thanks for being this episode’s guest on DevOps Chat and we’ll speak to you soon.

    Balch: Thanks a lot, Alan.

    Shimel: Thank you. This is Alan Shimel for devopsy.kinsta.cloud and we hope to see you soon on another DevOps Chats.

    — Alan Shimel

  • DevOps Chat: The Evolution of APM with Jonah Kowall, AppDynamics

    DevOps Chat: The Evolution of APM with Jonah Kowall, AppDynamics

    In this DevOps Chat we speak with Jonah Kowall, VP of Market Developments and Insights at AppDynamics. Of course prior to that Jonah was a VP of Research IT Operations at Gartner. Jonah actually gave us a great overview of the evolution of APM  and how the market has evolved. He also tells where we might be heading now.

    It is not often you can get the lay of the land from an expert like Kowall, so I highly recommend you give this a listen.

    As usual, immediately below is the streaming audio of our discussion and below that is the transcript of our conversation.

    Streaming Audio

    Transcript of the Conversation

    Alan Shimel:                Hi, everyone. Alan Shimel, devopsy.kinsta.cloud here for another DevOps Chat. Our guest on this episode of DevOps Chat is Jonah Kowall of App Dynamics. Jonah, welcome to DevOps Chat.

    Jonah Kowall:             Thanks, Alan. Happy to be here—great to speak with you and everyone else listening.

    Alan Shimel:                Thank you. So Jonah, before we jump into App Dynamics, you have a—you’ve had a bit of a career already. Why don’t you share with our audience a little bit about kinda your journey to how you got here today?

    Jonah Kowall:             Yeah, definitely. Well, I always knew I wanted to be a technologist and, for many years, I worked at about six or seven different startups. I co-founded one of the first content filtering companies back in the early 2000s and, you know, got acquired a couple of times.

    And I kinda shifted careers a few years ago, about seven years ago, and moved into the analyst world and kinda moved away from running ops and security and infrastructure and application performance and decided to take the analyst path, and did that for about four years, which was very interesting and different, learned a lot of new skills, a lot of new muscles were built.

    And I joined App Dynamics a little bit over two years ago, and I work with our       co-founder and CTO running product strategy. I do a little bit of marketing, but quite a bit of product management and kind of looking into where we’re going as a company to solve the next generation of problems that we’re starting to see in our customer base.

    So that’s a little summary of where I came from and however you’d like to take it is great.

    Alan Shimel:                Sure. I guess the real question is, do you know where you’re going, but we’ll come back to that in a second.

    Jonah, as I spoke to you offline about, I wanted to talk to you a little bit about what I have seen, you know, as an observer of the market at devopsy.kinsta.cloud. In terms of the evolution of what used to be just a few years ago, a very kinda stable space called APM, right? We had, the APM space had a handful of players—App Dynamics was certainly one of them—who were, by the way, all doing pretty well, it seemed.

    And what we’ve seen in the last few years is, you know, in the—first of all, more people joining the fray, but more than that, in the race to distinguish one from the other, many players within this space are kinda rephrasing their mission, their—not running away from APM, but their APM plus, maybe. And so we’ve seen, you know, alphabet soups of ARAs and a whole bunch of different combinations.

    What’s your take on that, Jonah?

    Jonah Kowall:             So, when you look back—and, you know, when I started at Gartner, there was a lot of confusion around application performance and application monitoring. And there was like a general belief that anything that monitored some kind of application or even monitored the network and tried to extract application information was, in fact, APM.

    And what I kind of tried to do in my time at Gartner, and I think it sort of changed some things, was really focus APM on instrumentation of applications. So, how do we see the code, how do we get inside the application, how do we trace from end to end and really provide that visibility and the diagnostic capabilities that are really gonna be needed in today’s applications, which are incredibly complex and diverse, and consist of a lot of new technologies?

    So, building that kind of visibility is really hard to do. I mean, if an APM company—and there are plenty of them that have started over the last couple years—they have many, many years before their instrumentation becomes decent, if they’re even going down that path. And the ability to extract information from a running application, without breaking it, is very, very difficult to solve. It takes a lot of time, a lot of experimentation, a lot of work with customers.

    And so this market is very hard to enter into and compete with the three leaders in the space. It’s just a big challenge, and you’re looking at five to six years before these things mature, if they continue to pursue them. So what you’re kind of seeing, and what you alluded to, is that companies are trying to take a different angle and avoiding the deep instrumentation and just trying to provide SVKs and tools for developers to build those, you know, that visibility. But it’s a big challenge, because in enterprise and packaged applications, those products don’t work, and that’s really the challenge that I continually see out there when I observe the industry.

    Alan Shimel:                Got it. So, you know, certain—I’m sorry, Jonah, I have a little tickle. App Dynamics, you know, in, let’s call it an immature industry, rapidly become an 800 pound gorilla, and I think we’ve all seen the proof of that in recent news around acquisitions and so forth. But I’m not gonna go there, Jonah—suffice to say, App Dynamics is a market leader in its space.

    How does this evolution, if you will, changing dynamics, you know, you said you’re working on future problems—how do you think this plays into the future of App Dynamics?

    Jonah Kowall:             Yeah. Well, I think that applications and technologies will continue to evolve, and you know, we’re already starting to see a lot of new application paradigms that we’re gonna have to shift a lot of our core technology to support and to essentially leapfrog what the rest of the market is able to do, and we’re hard at work doing that.

    But aside from the deep, you know, introspection of software, there is also a big push for us to really understand the business, because today’s enterprises, regardless of what they do, whether it’s extracting natural resources from the earth or building cars or providing mortgages—these companies are all software companies, and their businesses depend and are driven by their software. And our goal is really to understand the business execution and the user experience of those transactions that are critical. And, in kind of taking that to the next level is really, how do we look at the outcome of software and of these business transactions as they come together.

    So, our vision is not only to increase our capabilities of the core of what we do in APM, but also to really provide a lens into the business that really provides that IT business alignment that everyone talks about and everyone struggles with today. So we really see that as the differentiator in these large enterprises that are really challenged with a lot of legacy and a huge amount of demand to change their businesses.

    Alan Shimel:                Got it. Got it, got it. So, Jonah, let me pivot a little bit to, there was another area I wanted to touch on with you, and that is this whole area of containers, micro-services—but containerization. Virtually every call, every briefing that I’m on, somehow or another containers make their way into the conversation. How big a focus is it over in the, in terms of product and in terms of the strategy at App Dynamics?

    Jonah Kowall:             Yeah, I mean, micro-services and containers are definitely the peak hype, let’s say, of the day—there’s no question about that. And they provide a lot of benefit, but a lot of people really feel that containers and micro-services are the answer to every problem. And this is something that we’ve seen over and over in our industry where, you know, there’s a new kind of angle to an existing set of technologies that we feel is really gonna make the biggest difference. And although containers and micro-services are both important paradigms, they’re not the answer to everything.

    Our customers are clearly retooling some of their applications around a micro-services architecture, and they’re definitely running workloads on containers, and these things are important for us to support, but are they more important than, you know, building core functionality to support new languages and new frameworks and really helping our customers with their more core business problems. It’s hard to say. I mean, both are clearly critical, but a lot of it is hype, and you know, the hype obviously fades as people become disillusioned with the fact that containers and micro-services don’t solve all your problems. They create a lot of new problems, and that’s just the reality of technology.

    So, as an industry, we’re very over rotated to containers, micro-services, and public cloud, and you know, we’ll soon realize those aren’t the answer to all of our problems—and oftentimes, they create new problems, as well. So, you know, I think it continues to be a cycle and, you know, I really think the evolution of cloud into a decentralized model will be a pretty interesting trend over the next, you know, 5 to 10 years as well.

    Alan Shimel:                Got it. I think we’ve barely scratched the surface. You know, Jonah, I was on a call previous to this and it was around software defined storage and networking and stuff, and it just—listening to it, I had such a déjà vu of sitting back in on the VMware stuff, you know, back in, I guess mid-2005, around then.

    Jonah Kowall:             Yep.

    Alan Shimel:                It just seems to promise so much change for us here; it’s crazy.

    Jonah Kowall:             [Laughter] It always does, and you know, it comes with challenges, always, and people become kind of disillusioned, but there are benefits to those that embrace it, do it well, and you know, have the types of problems that those technologies can solve.

    Alan Shimel:                Yep. Excellent. Well, Jonah, we’re just about up on our time. I’m gonna give you a surprise question here, if you don’t mind—if you can’t answer, that’s okay.

    Jonah Kowall:             Sure.

    Alan Shimel:                But I usually ask, the last question I always ask my guest is—recommend one book to our audience that you really think they should read to help them with their careers.

    Jonah Kowall:             That is an interesting one. I actually tend to, I do a lot of traveling. I actually flew over 200,000 miles in 2016.

    Alan Shimel:                Wow.

    Jonah Kowall:             So, when I actually get to read, I tend to read lighter materials, or I read very deep, technical materials that kind of help with some of the product work that I’m doing. So a lot of the books I read tend to not be too inspirational, but I do really enjoy participating in some of the open Slack communities. I enjoy reading a lot of blogs and other content that tends to be fresher.

    Alan Shimel:                Mm-hmm.

    Jonah Kowall:             You know, I read probably about 500 blogs in my RSS feed regularly, so that tends to really be how I get information, and I do really enjoy reading some of the Google Scholar, if you set some interesting alerts up, you can get some great research papers coming out from universities that are very interesting and forthcoming, just kind of highlighting some of the next generation thinking from the educational institutions all over the world.

    So that really tends to be more what I tend to read versus, you know, something that’s more career focused, I would say, or inspirational in that manner. So sorry I don’t have the best answer, but that’s what I tend to do.

    Alan Shimel:                No, no—that’s fine, and that works for us. Well, Jonah, I think we—well, we are out of time, but I want to thank you for joining us today on DevOps Chat, and I look forward to perhaps having you on again in the future.

    Jonah Kowall:             Sounds great. Thanks for your time, Alan, and thanks, everyone, for tuning in

    Alan Shimel:                Thank you. Jonah Kowall, App Dynamics, our guest today on DevOps Chat. 

                                        This is Alan Shimel for devopsy.kinsta.cloud, and we hope to see you soon on another DevOps Chat.

    — Alan Shimel