devopsy.kinsta.cloud

Tag: devops

  • Making DevOps a Reality – Bringing in Security: Top 4 Topics

    Making DevOps a Reality – Bringing in Security: Top 4 Topics

    I caught up with Maria Loughlin, vice president of engineering at CA Veracode; Chris Eng, vice president of research at CA Veracode;  and Alan Shimel, CEO of DevOps.com, to talk more about their recent panel webinar on bringing in security to make DevOps a reality. It was enlightening to hear their perspectives on how companies can build security into its culture so that it permeates the development process. Many enterprises have realized that with the continuing popularity of DevOps comes the possibility of creating an environment that allows software vulnerabilities. In truth, more teams are integrating security testing into their development processes.

    This informative session is available here on demand and worth a listen. But I’d like to share the top four topics from their discussion:

    New Mindset and New Speed

    As dev moves to DevOps, traditional approaches to security aren’t fast enough. Both the challenges of scale and the lack of expertise on the teams need to be addressed.

    Faster, Cheaper, Better

    DevOps makes integrating security easier in a few ways. First, engineers understand they need to take more operational responsibility, and that includes security; and secondly, DevOps emphasizes the investment in automation and continuous delivery of small batch sizes. As much as we automate security, it becomes less costly, transparent and readily adopted.

    People Aspect in DevOps: Just as Important as the Technology

    Teams do need to interact differently in a DevOps environment. The partnership must be real and show empathy, respect and flexibility. Expect the security teams to be reasonable and take a risk-based contextual approach; not everything is critical.

    Most importantly, that interaction must start at the top, just as it does with Maria and Chris, with a shared goal of success and accountability.

    Their Parting Advice

    Make the secure way the easy way. Implementing secure building blocks not only saves time but reduces your risk. Look for opportunities to simplify and automate to optimize your investments.

    Sometimes, it is best to start small. Your investments will grow over time with nurturing.

    Your people are your most valuable assets. Be sure to monitor and mentor the skills gap on your team because if team members aren’t knowledgeable they can’t be held accountable. Make sure that executive sponsorship is involved and visible.

    There was so much more. Luckily, you can still watch the entire webinar. It’s available here.

    — BeckyArenson

  • Puppet Report Sees Long DevOps Journey Ahead

    Puppet Report Sees Long DevOps Journey Ahead

    A recent report published by Puppet suggests the level of DevOps maturity within most organizations is still relatively slight. In fact, most of the respondents reported high levels of manual work still occurring across configuration management, deployment, testing and change approval processes.

    Alanna Brown, director of product marketing for Puppet, said the “State of DevOps: Market Segmentation Report” makes it clear that DevOps is being embraced to solve specific pain points with specific IT departments. As a result, silos of DevOps processes are springing up across the enterprise. That next challenge IT organizations will face is trying to unify all the DevOps processes, she said.

    The survey finds deployment automation, version control, continuous integration and infrastructure automation were the most common starting points for DevOps. Less-common starting points were lean practices, visualization of key quality and productivity metrics and setting limits on work in progress.

    Brown said the one surprising thing that study found is there is little correlation between the size of the companies surveyed and their relative DevOps maturity. Reliance on DevOps process may have more to do with needs arising from satisfying customer demand than anything else, noted Brown. The survey finds that media and entertainment and retail industry have the lowest percentage of low IT performers, while financial services, insurance and manufacturing companies had the highest proportion of low performers.

    Not surprisingly, given the relative amount of DevOps immaturity, the survey also finds that reliance on IT automation frameworks is not yet especially widespread.

    The Markets Segmentation report is based on the 2017 “State of DevOps” survey of 3,200 IT professionals that Puppet previously published. While it’s possible many companies may have advanced further down the DevOps journey since then, the report makes it clear that for both technical and cultural reasons fully embracing DevOps is an extended process. In fact, Brown said the report shows DevOps is still mainly being driven by the bottom of the organization up rather than by senior IT leaders. It’s only when DevOps success becomes visibly demonstrated that organizations attempt to replicate that success elsewhere in the organization. At the same time, widespread usage of DevOps processes suggests that DevOps itself is now much more than a grassroots movement, she said.

    Change obviously comes hard to enterprise IT organizations. Many DevOps concepts were initially pioneered by web-scale companies that have the luxury of not having to support legacy applications and processes. Traditional enterprise IT organizations now typically are trying to support DevOps processes alongside process based on Waterfall and ITIL methodologies. Not every application being supported requires that number of release updates that many modern applications require.

    Nevertheless, it’s also clear that as the number of applications being built, tested, deployed and supported continues to grow, the average IT organization is increasingly short-handed. Finding IT professionals with DevOps skill sets is a major challenge. But as more companies come to realize they are really a software company that happens to be selling a specific thing, the higher priority DevOps becomes.

    — Mike Vizard

  • DevOps Chat: Trends in Cloud Service Management – ML/AI, ITSM, DevOps, ITIL & SRE w/ Sinead Glynn

    DevOps Chat: Trends in Cloud Service Management – ML/AI, ITSM, DevOps, ITIL & SRE w/ Sinead Glynn

    In this DevOps Chat, we speak with Sinead Glynn of IBM about some coming trends in Cloud Service Management, ML/AI, ITSM, DevOps, ITIL and SRE. A lot of buzzwords in there, but there is also some good information here. Sinead is a great interview.

    As usual, the streaming audio of our conversation is directly below, followed by the transcript of our conversation below that.

    Audio

    Transcript

    Alan Shimel: Hey, everyone. It’s Alan Shimel and you’re listening to another DevOps chat, and – here on DevOps dot com. Our guest for today’s chat is Sinead Glynn, Offering Manager, IBM Operations Analytics, IBM Hybrid Cloud. Sinead, did I – did I get that right? 

    Glynn: Yes, you did, Alan. Thank you. And thank you for having me.  

    Shimel: Thank you. It’s our pleasure to have you. So Sinead, you know, IBM titles are always kind of very descriptive but why don’t you give our audience a little bit more here. What exactly is your role with IBM? What do you work on? What do you do?

    Glynn: Sure, yes. Yes, so I’m an offering manager here with IBM. Offering managers would be known as product managers in other companies. We focus on offering because it’s more – it’s more than just a technology discussion. We kind of go broader and look at the full solution.

    In terms of my own area of specialty, it’s around the operations management and the broader management capabilities from an IT perspective, so it’s your centralized IT operations teams, your DevOps teams, and the management capabilities that they need.

    In terms of the offerings I specialize in and the area I specialize in, I have a background myself in development and, in particular, the development of machine learning and cognitive technologies. So my own focus is in terms of bringing those capabilities to market and, you know, explaining how that – they benefit the IT operations teams and the DevOps teams. 

    Shimel: Great. So Sinead, you know, machine learning and its, you know, its Siamese twin, AI, seem to be on everyone’s lips these days whether we’re talking about Dev, DevOps, Ops, security, testing, or big data, or hybrid cloud, or cloud private or whatever, everyone has a story around ML, machine learning. 

    Glynn: Yep. 

    Shimel: But we’re really here today to really focus in on machine learning as it relates to cloud service management. Right? You know, I – my personal belief is that over the next five, ten years, machine learning and artificial intelligence, AI, is going to have a profound input – impact on a lot of different things that we do. But at a high level, Sinead, talk to us about, you know, what kind of impact machine learning is having on cloud service management specifically, and why it’s sort of become an essential piece of your cloud service management.  

    Glynn: Sure, yeah. So I suppose, you know, there’s two dimensions or two primary dimensions to cloud service management. There is the complexity of what you’re managing, you know, hybrid cloud was something we all talked about, you know, 12, 18 months ago that has morphed into multi-cloud. So, you know, management organizations, they’re handling their kind of traditional systems of record and they might have a number of public clouds and a number of private clouds that they’re using.

    So there’s the – there’s the complexity dimension and certainly machine learning provides the ability to manage that complexity when you don’t have the ability to suddenly grow your teams. So you can’t add people.

    But the other – the other dimension is how you manage. So it is that change in the process and the change in the culture that is required to be successful when you’re doing cloud service management. So, you know, it’s that move from, you know, months or even a year of preparation for a new application to be rolled out, it’s very much that agile versus traditional model and that, you know, DevOps stroke Lean versus your ITIL view of the world.

    So it’s enabling at the roles and it’s enabling those roles to be successful in cloud service management in terms of how you manage, not just what you manage. 

    Shimel: Fair enough. So, you know, Sinead, I – I’ve – we both have been in this – in this business for more – a couple of years. Me longer than you, probably – you’re much younger. But, you know, we’ve seen sort of the rise of – of IT service management and things like ITIL, and, you know, traditional ITSM, and they’ve kind of ruled the roost here 15 years or more, 20 years or more. Right?

    And now all of a sudden we’re seeing, you know, things like DevOps and Lean IT, and even sort of some of what we take from Agile. Right? From the Dev side of the house. You know, almost Agile for Ops if you will. And they – you know, and they’ve all been kind of chipping away at that ITSM model.

    And then most recently, of course, we’ve introduced this term of SRE, site reliability engineering. And now this, along with things like machine learning, really seem to be changing, you know, traditional ITSM at – at its core. I mean, it’s really kind of rewriting the book or – I mean, really forcing us to reexamine some of our ITSM, you know, core values and principles, ways of doing it. What do you think about that? 

    Glynn: Oh, absolutely. You know, ITSM was very much focused on – or is, it’s not a was thing. Is very much focused on operational excellence about, you know, being that gatekeeper to ensure that only high quality applications are deployed and very, very process-centric and control-centric, typical kind of waterfall type methodologies, and that was very effective before the real transition in terms of how business is running.

    So business – business must have digital engagement. Business must have agility in order to innovate, in order to keep your clients and grow your client base. And that, you know, operational excellence stroke, you know, very process-centric risk adverse way of managing just – just doesn’t work. So that’s where, in line with – in line with that digital transformation, the DevOps practices and the Agile Ops has to emerge with it.

    And, you know, from an Agile Ops perspective, that’s much more about how can technology help me be agile while still managing the risk and delivering exemplary service? How can technology help me rather than how can I be very process-centric.

    Shimel: Yep, and Sinead, though, I – you know, I almost feel compelled to caution the audience that I don’t think your saying, IBM’s saying it, I’m certainly not saying that ITSM is dead. You know, it’s more like ITSM is dead, long live ITSM. Right? And, you know, it’s just – it’s changing, it’s morphing, it’s evolving with – with, you know, new things like AI machine learning, but also with new frameworks like DevOps and Agile for Ops and Lean and so forth.

    And this kind of gets at the heart or _____ of SRE. But another fundamental, I think anyway, another fundamental shift in this is – and I’ve heard you talk about it – we – we had the pleasure of doing a video at – I think it was IBM Think a couple months ago – is the kind of the – not the changing customer but the changing kind of world view that – that we need to have over in Ops, and that is the – the, you know, the changing into a skilled service organization rather than the center of the universe. 

    Glynn: Absolutely. So, you know, it’s – it’s moving the mindset from, I’m the center of the universe, I control everything, you know, with process and controls, et cetera, to, I have to support the required agility in the business. And in order to support the required agility in the business, I need to be much more about being a skilled services organization.

    And just on the topic of, you know, is ITIL dead or, you know, it’s usually a coexistence. So, you know, we frequently see, particularly in larger organizations, you know, your traditional IT Ops remains and they need to have a – you know, they may need to have visibility and control across both the traditional and the cloud environments, whereas the software reliability engineer, they tend to service maybe a number of DevOps teams, supporting them in their agile work practices and they’re very much focused on automating rather than throwing people at it.

    So it’s very much – maybe 50 percent of the time is worked on – or spent on kind of traditional operations and 50 percent is really looking at, you know, how I can scale this better. How can I automate this better and how can I support? So it’s really that services view.

    And there is a transition, you know, there isn’t really clear lines. They might emerge over time but there is – there’s really kind of two types of organizations frequently emerging in the larger organizations and – and it’s because the larger organizations typically have been around for some time. So there’s already a tradition of that – that centralized IT operations.

    From a technology provider perspective, there’s a challenge because everyone is trying to do the same job ultimately, you know, deliver exemplary service, but because of the cultural differences and because of the skill differences, they have slightly different views in the world.

    So it’s the same thing – they’re managing but they need different views in the world. And I guess our challenge is to ensure that they – the right experience and the right insights are made available to the right types of users to do their job most effectively. But definitely there is that transition towards the site reliability engineer and their needs. 

    Shimel: Yeah, I’ve heard – I’ve heard people say that, you know, this whole SRE kind of role becomes the Ops in DevOps but, you know, in listening to the way you talk about it, Sinead, again it – it reinforces a continuing maturity sort of view of the world. You know, as a dad or as a parent, you know, every child is the center of the universe. Right? The child believes that they’re the center of the universe. And I think part of the maturation process and growing up is realizing perhaps you’re not the center of the universe. Right? But you are, you know, there’s a big world out there that you’re part of.

    And I think that kind of really – when you think about it that way, that’s – that’s the journey for Ops. Understanding they’re not the center of the universe and they’re a part of this bigger world. And – and – but they still have a – a vital role to play, a very important role to play and – and I think that SRE role is in there. 

    Glynn: Absolutely, absolutely. 

    Shimel: So, you know, we have this webinar coming up on June 21, 2018, and it – it is, you know, along the lines of cloud service management and – but it really comes from, you know, I’ve seen anyway, a – a changing view of cloud from IBM itself. And, you know, IBM’s not a small company so when their – when their world view shifts, there’s usually good reason for it. Right? And it tends – and it tends to change a lot of others’ world view as well.

    And you mentioned it rather casually earlier. You said something like, “Well, we’ve gone from an emphasis on hybrid cloud to a multi-cloud.” You know, dropped that in there. But, you know, that’s – that’s a profound – you know, that – there’s really something here. 

    Glynn: Absolutely. 

    Shimel: Talk with our audience a little bit. What do you mean by that? 

    Glynn: Absolutely. I suppose in the – in the early days, you know, there was a focus on, we have cloud. It’s fantastic. Come buy our cloud. Let me show you what our cloud can do. And I guess through many interactions and learning process, it’s obvious that, you know, no one cloud does all jobs. So it’s about picking the right tool for the right job.

    So what we see is that the complexity in the environments that are actually being chosen. So it’s a multi-cloud strategy. It’s not a, I’m going to put everything into one particular vendor, or, you know, I’m going to move all of my workloads exclusively to cloud. You know, they – it’s much more granular decision. Certain parts of the business, you know, usually the systems of record, they may be kept on existing infrastructure and continue to be managed there, whereas the systems of engagement may go to public clouds, they may go to private clouds, depending on your security and data requirements.

    What businesses are doing and what smart businesses are doing is, depending on the type of application modernization they’re driving, they’re selecting the right strategy. Which is great for business, it’s a heck of a challenge for your centralized IT operations because of that complexity. So they need machine learning and adaptive automation to help them manage that complexity, to do their more traditional roles in a much better way, particularly when there isn’t that long handover.

    You know, apps are pushed out, particularly in cloud, the scaling out of those apps on the infrastructure is, you know, highly dynamic and, you know, when you’re trying to troubleshoot things, you need to get insight. So you need to have insight and analytics and machine learning to help you understand because there hasn’t been – you know, there hasn’t been a communication that this has happened. So all of those technologies are required.

    So that’s the – the multi-clouds _____ traditional IT Ops, they, you know, the infrastructure is – is agile, there are multiple clouds that they need to be able to see, and then you have some parts of the organization, maybe growing parts doing your DevOps type practices. And they have slightly different needs. You know, the – the DevOps persona just need to see their own project or the – the applications. The SRE engineer probably services more than one DevOps team.

    So they – they have different views and we’re very much focused on ensuring that the management capabilities that we have, particularly around the machine learning and the analytics, that, you know, it’s providing those insights to help those groups do their jobs effectively. So it’s definitely multi-cloud, Alan. It’s not – it’s not hybrid. Not just hybrid. Yeah. 

    Shimel: I – I agree with you. I think that was a good explanation. While we’re doing definitions and glossary terms, let me break – throw another one at you and that’s IBM’s what you’re calling adaptive automation.

    We’ve touched on it, we spoke a little bit about it, but let’s make sure we’re clear for our audience. What do you – what do you mean by that?

    Glynn: Okay, well, I suppose traditional automation and, you know, obviously something that’s been around for 40 years, I don’t know, I think we need to go back – that’s about, you know, I know something, there’s a condition, I kick it off on and that condition happens again. Whatever you’re doing. So it’s very much a rule-based or a condition-based automation, absolutely very effective and very valuable.

    But in – in the cloud world where things are dynamic, we need to think much more about adaptive automation and there are, I suppose, different types of adaptive automation. Does the type of adaptive automation, you know, if we think about, just as an example, the types of machine learning and analytics that would do things like event grouping. So that’s, you know, looking at real-time – real-time machine learning to reduce the number of events in your environment through machine learning, et cetera, et cetera. So that’s kind of a real-time adaptive automation.

    You take it further and you can look at things like maybe proactive automation where you’re using, you know, machine learning to actually learn what is normal and – in your environment and proactively tell you when things have gone abnormal. So that’s more about being able to predict that things are going to happen rather than react elegantly to things that are happening in real time.

    And then taking it further, Alan, I mean, there’s a big push – and obviously IBM is leading this in terms of cognitive capabilities, so not just looking at machine learning on the machine data in your environment, but going beyond that and using machine learning perhaps on your human data, your knowledge corpus, and really imbuing those workflows – workflows with, you know, cognitive – to help humans make those decisions even faster.

    So there’s different levels of it. Practically, you know, folks tend to start off in that reactive way, using kind of, I suppose, automation in real time to reduce the number of events and to trigger maybe standard automations. And then it’s about moving beyond that to really start gaining the value from the machine learning. 

    Shimel: Got it. It’s a great time to be alive in Ops, isn’t it Sinead? Right? Think about – you know – 

    Glynn: I – I think so, yeah. I think so. And I know we – you know, I know some might fear things like automation and machine learning and analytics but I’m fully confident that the complexity of the environments we’re managing is rising much faster – you know, it’s getting so complicated you do need automation and machine learning to manage it. 

    Shimel: You need it. Right.

    Glynn: Yeah, so, you know, I think it is. It’s an exciting time. Yeah, skill set changes, most definitely, but, like, if you – if you look at even, say, something simple like microservices, so, you know, everything is moving to microservice architectures, as far as can tell at least, and yes, that makes the job of development much easier and much more reuse, et cetera. But the – you know, the job of Ops gets a lot harder because it’s a lot less predictable, there’s a lot more data, you know, there’s – how do you see the wood for the trees? How do you pinpoint the, you know, there’s these obscure names on things, et cetera.

    So you need insights, you need help to do the job you did, to do it much better. So, and again, it’s always about supporting that digital transformation.  

    Shimel: Sure. I mean, and it’s really necessity is the mother of invention. Right?  

    Glynn: Absolutely. 

    Shimel: No one – no one does things as much as we’d like to think, you know, no-one does things because they’re cool or, you know, just – you don’t do new for new’s sake. You do new because there’s an advantage to it and so much of what we’re seeing around machine learning and automation and these new frameworks and so forth is a response to the complexity, to the changing nature of the way we’re doing business in IT. 

    Glynn: I wholeheartedly agree. And I have personal experience of this because I’ve been doing this particular role for some time, particularly on the development side, and you know, I would say hand-on-heart, we were probably to market too early with some of this. 

    Shimel: Yeah. 

    Glynn: You know, and – you know, a few years ago it used to be an experience of, wow, that’s really cool, but I don’t need it. It really was, you know. 

    Shimel: Exactly. Right. 

    Glynn: And it was, you know, quite surprising, particularly because I – myself, at the time, I was in development so I was very, why – why do you not see this? It’s like, what’s wrong – but you’re right. 

    [Crosstalk] 

    Shimel: Well, and it is so cool. Right? 

    Glynn: Exactly. It’s very cool, but not needed. 

    Shimel: So that was, like, you know, that was something else that – Sinead, I learned early on, I – you know, my history is I’ve done a number of venture-backed startups in technology over the last 25 plus years and, you know, a hard lesson that I think every entrepreneur learns is you are never going to be successful selling something that’s nice to have. Like, no-one buys things that are nice to have. They look at things and say, wow, that is cool. It’s nice to have. 

    Glynn: Yep. 

    Shimel: But they don’t write checks until it’s a must-have. 

    Glynn: Exactly. 

    Shimel: And – and that’s really the key. Sinead, we’re almost out of time, here. We’re probably over time already, but before we go, I want you to just give our listeners a place to go. They’ve heard – they’ve heard kind of a little bit about what you’re doing and what IBM is doing around this. Where can they find out more? Where can they engage with your team and – and, you know, start living this and doing – you know, they’re probably all – many of our listeners are faced with this very reality. How can they engage with IBM on this stuff? 

    Glynn: Absolutely. Well, just from a – I suppose from a Google-search perspective, there’s an IT Operations Analytics page. So if folks do a search on that, you’ll be brought in, and folks can reach out to me, of course, as well. We’ve an IT operations management page as well. For me, I – you know, it’s very hard to separate one from the other because we’re moving more and more towards that, you know, that AI-driven operations. That’s becoming essential – not a nice bolt-on to have and – on your operations management.

    So certainly that’s the place. Again, if you go to IBM Marketplace and you look for IBM Operations Analytics you’ll find the details of the machine learning technologies around the, you know, the events and the performance that I’ve mentioned, and indeed, you know, the cognitive stuff.

    But probably just to reach out to me, Alan, is a good start. And I can certainly point them in the right direction. 

    Shimel: Great. Okay, so let me ask the magic question. How do they reach out to you? 

    Sineed:Certainly. Well, my e-mail address is Sinead.Glynn@ie.IBM.com. 

    Shimel: And that is S-I-N-E-A-D dot Glynn G-L-Y-N-N at IE dot IBM dot com. 

    Glynn: That’s me.

    Shimel: Got it. Sinead – Sinead, thank you so much for – for being our guest here today. I know I told you it was just 15 minutes and we – we’re probably double that. But I think it was a worthwhile conversation and I’m sure our audience will find it very interesting. 

    Glynn: Okay. 

    Shimel: Our webinar on this, by the way, DevOps.com webinar sponsored by IBM is on June 21, 2018, at 1 p.m. Eastern – it’s actually Eastern Daylight Time, not Eastern Standard Time. Right? Because we’re in daylight saving time. And 1 p.m. East Coast time.

    So you can log on from wherever. If you go to DevOps dot com and under webinars, you could register for the webinar there. We’ll – we’ll have a link for it in our notes.

    Sinead, thanks for appearing. Hope to have you – you know, the webinar I’m sure is going to be great but maybe we can continue this chat another time on another DevOps Chat. 

    Glynn: Certainly, certainly, Alan. And thank you. It’s always a pleasure. 

    Shimel: Thank you. All right, this is Alan Shimel for DevOps dot com, DevOps Chat. You’ve just listened to another chat. Have a great day everyone.

    — Alan Shimel

  • DevOps Chat: DevOps for Databases, a DBmaestro Update

    DevOps Chat: DevOps for Databases, a DBmaestro Update

    DevOps is coming to databases. While there are several companies who have been dedicated to this over the last few year, by all accounts DevOps for databases has been catching stride as more DBAs and organizations realize the benefits of DevOps for databases.

    In this DevOps Chat we sit down with Yaniv Yehuda, co-founder, CTO of DBmaestro, to discuss what is driving the increased awareness and what is coming to the market. Yaniv is always a great interview with lots of good insight. Enjoy.

    As usual, the audio of our discussion is immediately below, followed by the transcript of our conversation.

    Audio


    Transcript

    Alan Shimel: Hey, everyone. It’s Alan Shimel, DevOps dot com, and you’re listening to another DevOps Chat. Welcome to DevOps Chat today to our – a repeat guest. We’ve – he’s been a guest on DevOps Chat several times. Yaniv Yehuda, co-founder, CTO at DBmaestro. Yaniv, welcome to DevOps Chat.

    Yaniv Yehuda: Hey, Alan. A pleasure being here again – pleasure being here today.

    Shimel: Yes, thank you. Always a pleasure to have you, my friend. Yaniv, what we’re going to spend a little time talking about today is, you know, as DevOps continues to mature and we see it moving beyond, you know, the orthodox Dev and Ops only to encompass, you know, more pieces of the IT stack, it’s becoming, you know, increasingly obvious to people that having the database and the DBA as part of the DevOps team, as part of the – you know, under the DevOps umbrella – is a must have.

    And I guess this is something that is kind of elemental, if you will, to the DBmaestro folks. It’s what you’ve been preaching now for, how long?

    Yehuda: For several years. Several years already, yes. Absolutely. Absolutely. No, so I’m in perfect agreement here, you know. It – if you’re trying to start and practice the new or modern process as – may that be DevOps, variations of agility, trying to practice CI/CD – at the end of the day, you need to take care of everything. You can’t just do two thirds or half of the equation. You – it’s like having a car that, you know, you have three wheels spinning at one speed and one spinning slower. So it doesn’t make sense. You really need to cater for everything in order to be efficient, in order to be repeatable.

    And recently, you know, talking about DevOps, it’s really expanding. People now really want to cater for security at the same – at the same rate. Because you’re trying to – to shorten feedback loops, you don’t want to deal with stuff too late, so it’s – it’s mainly DevSecOps and this is what we’re seeing from our customers, the need to take care of security, they need to take care of the database, they need to take care of – of agility and productivity together. So with security.

    Shimel: Yes. Yep. Now, but Yaniv, when we start talking about, you know, DevOps for the databases, DBAs, and so forth, one of the things – right, the database market is a fairly mature market with more than several players in it. Right? You have your  Oracle, DB2, Microsoft SQL, then you have sort of the open source crowd, like the MySQL and the MariaDB, you know, and so forth, and then of course you have the NoSQL group or the so-called NoSQL group which have come on, let’s say, in the last six, seven years.

    I would – is there – from DBmaestro’s point of view, let’s say, is there a difference which database you’re using or they – they’re relatively the same across the board?

    Yehuda: So discussing, like, from a customer challenge point of view, it’s all of the same. It’s all variations of the same challenges. For Oracle you might be pushing, I don’t know, structural changes and – and index creation or even DMLs just to tune the data and for NoSQL you might be deploying an update or a patch that needs to be implemented in each one of the databases but you have a thread of them. It’s – it’s like shards and – and, you know, replications that – and you actually need to take care of a lot of instances.

    So in all cases, you need to have a process to implement changes whether, you know, it’s one type of a database or another. And, you know, it’s just the same problem from different angles.

    Shimel: Yep. Is there anything – let’s say NoSQL. Right? Is there anything specific to NoSQL from a DBmaestro point of view?

    Yehuda: So first of all, we’re about to ship a MongoDB edition for our software.

    Shimel: Okay.

    Yehuda: And I think, talking about specific databases, you tend to see different aspects of – as I said, different aspects of the same thing. I’ll give you an example, a quick one. So many times, when you talk to DBAs and database developers and DevOps people, they want to move fast. And, you know, people say, move fast, break things, and be effective, be productive, but at the same time you need to be careful what you break because some things are just harder to fix.

    So, you know, if you drop a table from production then all break – all hell breaks loose but if you do things that would just take too much time to fix, even if it’s reversible, it’s not a good thing. So you need to come up with a way to move fast, break whatever is breakable, but not break Humpty Dumpty because it’s going to be hard to fix.

    And this is where we introduce a lot of safety nets into the process. So these safety nets might be more database flavored and – and I’ll give you an example. So let’s say you have a team of developers who wants to be agile and they want to run quick, they have their datalines, they have their tasks that they need to provide, and they need to go to the DBA and ask him to do stuff. If he actually has to go to the database and log in and run strips and do stuff, it’s – it takes time.

    You know, I’ve talked to DBAs who had – you know, a few days of tickets to go through and execute what people want to do. And it’s nothing that really benefits anyone because it’s all about just having the right credentials to the correct place and knowing who asked for what and should he be able to run that.

    So we’re automating all of these things in order to make sure that you can run fast, but about the breaking stuff, you break what should be broken. And I’ll give now the example about, like, Mongo versus Oracle.

    So for instance, we have what we call organizational policies and this is really the – helps balance the amount of work with the need to control what goes forward and not destroy things. So for instance, you have policies for Oracle or SQL or DB2 that says you cannot drop a table. Why? Because, you know, you might lose the data. Or you cannot rebuild an index on production in the middle of the day. Obviously why.

    But when you go to something like Mongo, then it’s all about fine tuning these policies. So if you’re trying to, like, create an index with background faults, that means that when you’re going to try and rebuild it, it will be a nightmare. So it’s all about stopping it at the first time when they – when the person puts in the command and saying, “Listen, you have an attribute missing from what you’re trying to do,” in order to live with that safely later on.

    So it’s all about catering for the, like, problem areas of each database and providing the benefit so people can run and if there’s something that they’re doing wrong, they will get very quick feedback, so that’s, you know, all about trolling the feedback loop just like DevOps and Agile are trying to achieve, and this is very much database-specific – so to your question.

    Shimel: Excellent, excellent. Yaniv, let me – let me turn a little – well, before we do, I wanted to just get maybe a – give our audience a quick update on DBmaestro. You mentioned a new MongoDB version coming out, but what else do we have?

    Yehuda: So actually we’ve – we’ve released a DB2 edition – I’m saying edition, it’s actually everything within the same product. It’s DB2 Sport, so DB2 for the mainframe z/OS and for the open systems – Linux, UNIX, Windows – we’re about to ship Postgre support and MariaDB so this is on top of Oracle and – and Microsoft SQLs that are already out there in the market for quite some time. And, you know, Mongo, as we’ve mentioned before.

    So what we’re doing is we’re not, like, sitting in a lab and dreaming, you know, we should do this at – we’re actually, in daily conversations with our customers, getting a lot of feedback, you know, working with the people who need to crack their own tests and trying to make sure that DBmaestro actually helps them in the most efficient way.

    So, you know, I’m proud to say that – you know, we have quite a big vision of where we’re going but a lot of it is fine-tuned with what’s happening in the market so it’s not just lab dreaming and wishful thinking.

    Shimel: Absolutely. So I – I don’t know if your being here told us everything though. I think I heard somewhere about an award or something.

    Yehuda: Oh yes. That is – this is quite, quite new. It’s actually today. We’ve just been announced that we won the Stevie Award for – we won a Bronze award for the best new product. So of course we’re very proud of this and probably will be boasting about this for quite some time now.

    But actually, with – you know, it’s – it’s very encouraging because we’re getting a lot of great feedback. The feedback that I like the most actually, more than awards and, you know, the stuff that you put on the website, is just customer feedback. You know, when you – when you see a person telling you, you know, “I used to wait three days for the tickets to go forward and now the developer is pushing changes five times a day, 10 times a day.”

    This is all I need. This is, like, what we dreamt when we wanted to – to do what we’re doing, to make sure that the database can play the modern processes, that people can practice, you know, the database stuff safely because, you know, if you’ve been talking to, like, DBAs two, three years ago. I think talking to them about automation would be a big, scary thing because, you know – you need to know what you’re doing, you need to make sure that you don’t introduce any risks. And at the end of the day, this is something that you just can’t do manually. You need to be repeatable and the only way to be truly repeatable is to automate stuff and to keep improving it.

    If you do something manually, at the end of the day you’ll make mistakes and, you know, as – as a certain big bird once says, you know, everybody makes mistakes. Oh yes they do. And this is it. You need to make sure that DevOps plays to the values of what you’re doing and – and this is what we’re putting for ourselves as targets. You know? Help people be more agile, be more productive, but not at the expense of safety. So more safe at the same time.

    And that, you know, if it can give you the ability to be also compliance-worthy at the same breath, yeah. Sure, why not?

    Shimel: I agree – you’re preaching to the choir over here, Yaniv. So let me – I wanted to bring up another topic, Yaniv, and this may be a little close to home for you, a little too sensitive, but, you know what, obviously I follow the DevOps market very closely now for a number of years and, you know, I think back to three or four years ago when, you know, the biggest question we got on DevOps dot com was always, “What’s the definition of DevOps? What exactly is DevOps? Is it just a marketing word?”

    And then when we – you know, when it was just Dev and Ops and the idea, when you would talk to someone about, you know, database for DevOps or DevOps for database, excuse me, DevOps for databases, there were a lot of – I don’t know what you want to call them, cynics or just – they were a little bit – a little stiff, who said, “Oh, that has nothing to do with DevOps.” Where do – within the DevOps community itself, how much – how has the attitude changed where DBmaestro and the whole, hey, DevOps is for databases too, has become more accepted within the DevOps community?

    Yehuda: That’s actually – you’re just describing my history here. So for a long time I have been trying to educate and tell the story as I think it should be told and, at the beginning, you know, when we were just bootstrapping and didn’t have the product that we’re so proud of today, cynics were even more extreme and it was, like, DBAs on one side, developers on the other side, a big wall in between, people tossing things over that wall.

    And actually, if you go back two years, two years back I think, this is no longer the case. People are implementing DevOps not just to be modern. They don’t have a choice. Gene Kim once said, you know, it’s DevOps or die. You don’t have to do it but you don’t also have to survive.

    So today – in today’s business, everybody’s trying to run fast. If you’re not running fast, that means that you’re running slower than your competition and nobody wants to afford that.

    You know, you had a webinar, I think, with ABN AMRO a couple of months ago. I was just delighted to sit there and listen to how they described what they built. It’s just – it’s just amazing. So – so – you know, it’s a carefully thought out process that takes out all of the junk time out of the process and makes everything efficient, whatever can be automated is automated, and, you know, it saves a lot of time. It makes the whole company more efficient.

    And then you reached a point where, you know, you’re looking at what you’re doing and that is working – I’m not talking about specifically them, but in general – everything is working but you’re not as efficient as – as you could be because every time that you go to the database side, you go back – you fall back to the manual processes – the single steps, God forbid, the DBA that goes – and side commands in production to make the change go forward.

    You know, the funny thing is when I’m recruiting people to the company, I’m telling them what we’re doing and they said, “This is amazing. This is what we’ve been doing all our lives wrong and this has always been a headache and you’re just solving it.” So that’s – that is certainly something that has drastically changed and I think the last two years has been an accelerated – I would say, accelerated approach to the whole thing that – it cannot be left aside. You cannot just do application, you cannot just do database, by the way, as well.

    You have to introduce a testing automation. You have to build with your infrastructure automation. So may that be containers or virtualization depending on what – where you’re coming from. It all has to be combined in order to reach that Holy Grail of efficient automation.

    Shimel: Got it. Excellent. You know, it – I think it’s a good thing for the DevOps community as a whole but it’s interesting, Yaniv, you almost have to be an evangelist to the DevOps community at the same time you’re evangelizing to the database community because I don’t know if they raise their hand and say, I want to be part of that DevOps thing too. Right? They – they need to be shown the way and evangelized and converted, if you will.

    Yehuda: So on this we do see a changing approach. It used to be, like, trying to convince why they should care. Today it’s not – I’m happy to say, it’s no longer the case. Some customers we have, you know, DevOps champions that push us forward. In other organizations, it’s the DBA or the DBA manager because they see what’s happening. They see the projects around them in the company.

    They don’t want to be left out and there’s – you know, there’s really no gain in – in doing a mundane job. Let’s do the fun stuff. Let’s – let’s improve logic, let’s fine-tune the database. Let’s do the stuff where, you know, computers can’t – can’t still, at the moment, solve the problems for us and leave that, you know, the mundane – mundane back-work or whatever to automated process.

    Shimel: Yep.

    Yehuda: And it’s not just DBA. You know, today you talk to – to, you know, all of our European or the ones who – who need to cater for GDPR. They have a set of new problems they need to cater for. It’s not just, you know, automation. It’s not just DevOps, they need to now make sure that they manage their roles and responsibilities and auditing and obfuscation of data, if you’re taking, like, data from production, now there’s no private data inside and how you do that process. So you want to have holes.

    You have automation for many reasons now. It’s not just efficiency. It’s creating the good process and sticking to it because if you have a great process but it’s just a manual process, each time you do it, you’re doing it slightly different. And this is exactly where I think the whole ARA market is spot on. This is why we’ve – I think we’re seeing the changes we’re seeing in the market in the  last couple of years.

    Shimel: Agreed. Excellent. Yaniv, you know what, I apologize, we’re way over our time here. So we’ll wrap it up. Before we wrap up, any last thoughts – anything you want to share with the audience?

    Yehuda: No, I think – I think, as you said, we did – took a bit more time so I think we can wrap it up.

    Shimel: Okay. Well, look, I wanted to mention that DBmaestro will be at Gene Kim’s DevOps Enterprise Summit in London, I think June 22nd to the 24th, maybe it’s the 23rd to the 25th. Something like that, towards the end of June. So if you were planning on attending DevOps Enterprise Summit, London, please stop by and say hello to the DBmaestro folks. And then Yaniv, you’ll also be at Cloud and DevOps World in London in June as well. Correct?

    Yehuda: Correct, correct. Yep.

    Shimel: Excellent.

    Yehuda: So, as I said, going – meeting our peers, meeting our partners, meeting our customers – just talking.

    Shimel: Excellent. All right, Yaniv Yehuda, CTO, co-founder, DBmaestro, frequent DevOps Chat guest, thanks for being here today with us and continued success.

    Yehuda: A pleasure being here again. Thank you. Bye-bye.

    Shimel: All right. This is Alan Shimel for DevOps dot com and you’ve just listened to another DevOps Chat. Have a great day, everyone.

    — Alan Shimel

  • Spring Cleaning 101: Polishing Up Your DevOps Processes

    Spring Cleaning 101: Polishing Up Your DevOps Processes

    Dev teams should take time to tune up agile processes and continue advancing their shift toward DevOps

    Release cycles are accelerating, but not as fast as development teams want. Customers’ desired release rates are moving at an unimpressive pace; those looking to push out new updates on a weekly basis often find it looks more like a monthly basis—and that just isn’t going to cut it.

    As the frequency of execution increases, dev teams find themselves between a rock and a hard place. While the growing demand for faster turnarounds isn’t poised to slow down anytime soon, teams struggle to integrate a set of tools into an efficient pipeline to get the job done within the time allotted. With demand on the rise, how can teams work together to fast-track their release cycles?

    It’s time for dev teams to apply a little more elbow grease.

    With spring cleaning season upon us, dev teams across industries should take time this season to tune up agile processes and continue the work of advancing their shift toward DevOps.

    Dust Off Roles and Responsibilities

    A once very siloed practice, software development has since taken on a much more agile approach across teams as the need for faster release cycles rapidly grows. According to a recent VersionOne report, nearly 75 percent of respondents attribute the need to accelerate software delivery to their adoption of agile practices. While DevOps is meant to help dev teams deliver applications at a high velocity, managers encouraging the implementation of these processes often overlook the true meaning of DevOps and the effects these transformations will have on its current employees and their roles.

    At its very core, DevOps is the combination of development and operations, which covers a wide range of tasks once performed by developers, testers and operations at different stages throughout the software development life cycle (SDLC). However, a more agile approach means these different processes (building, testing, etc.) are in a more tightly coordinated execution, requiring each of the different silos to have a better understanding—and knowledge—of each process.

    Before jumping in to update any processes or technologies, it’s important to ensure all teams are aligned on their evolving roles and responsibilities. Sit down with individuals, teams and their managers to get everyone on the same page and provide guidance on best steps for moving forward this year.

    Shrink the Skills Gap

    Despite developers’ growing list of responsibilities, a 2018 report from LinkedIn found that there is a significant skills shortage when it comes to software engineers and other similar career trajectories. That gap shrinks even further when you consider the different roles within software engineering itself. For example, developers have recently taken on more responsibility as “full stack developers,” assuring high-quality outputs and confirming there are no bugs in their code, yet have very little knowledge of how to implement continuous testing.

    This spring, spend time with employees to brush up on their skills, refine their job responsibilities and uplevel their expertise. While this isn’t a task that can be performed and executed on overnight, some recommendations to kick start the process include:

    • Get leadership on board: To fund any of this, teams will need leadership buy-in. Be sure to sit down with those in senior positions to explain the benefits to teamwide training from both an organizational and economic perspective.
    • Try the buddy system: Pair up programmers of different skills and levels to mentor one another. Consider it as a coaching system in which team members can provide feedback and training in real time with real-world projects.
    • Consider augmenting software delivery practices to improve quality: acceptance test driven development (ATDD) is a proven accelerator and behavior-driven development (BDD) helps bridge varying skills and blind spots between the different personas across the SDLC.

    Pick up New and Improved Processes for Increased Productivity

    As release cycles accelerate, team leads need to take a close look at each of the stages throughout the SDLC to determine where the roadblocks occur and what exactly is holding employees back. Analyzing not only the quality of outputs, but also how quality assurance is embedded throughout continuous integration (CI) process is a good start.

    Throughout the DevOps journey, there are a number of developers across different feature teams adding to, editing, updating and continuously testing code at any given time. Establishing best practices and some basic ground rules can be a simple way to ensure visibility into each of the teams’ productivity. Everyone must constantly be aware of which teams are moving along and which are struggling a bit to make sure code is well-maintained (e.g. determining if your testing code blocking your CI integration) and that there are no memory leaks or poor code development practices throwing the process off. Continuous testing across different feature teams will also assure that every code component for different functionalities is working once they all finally merge.

    Getting everyone on the same page will also make it easier to simplify real-time decision making. Be sure to work with teams to define their dashboards, ensuring everyone is seeing the same actionable results at any given time.

    Revamp Your Tech

    While people and processes should be a main focus for spring cleaning, don’t forget about the tech. The different types of technologies utilized throughout the DevOps pipeline must integrate seamlessly with everything mentioned above.

    First, consider your lab environments. The lab is the glue that keeps the entire CI process together, supporting all platforms (whether mobile, desktop, web, etc.). If unstable or unavailable at any given moment, the entire process breaks.

    As more organizations begin to adopt these agile approaches to software development, it’s also important to remember that it’s nearly impossible to build a “one-size-fits-all” solution; every new process, tool or technology should integrate well within the existing toolchain, which will vary from business to business. For the most success, don’t jump to conclusions and totally overhaul your current stack. Today, there are very few vendors that offer solutions that address every step throughout the development process. Instead, develop new APIs or integration points that make it easier to diversify the set of tools you already have.

    Finally, consider your frameworks. When it comes down to it, there are material differences between the developer’s objectives around tests and the test engineers. Make sure the entire team has tools and access to different frameworks based on their needs. A developer, for example, would use a tool such as Espresso or XCUItest to run a small number of unit tests, whereas test engineers require end-to-end functional test frameworks, such as Appium or Selenium.

    Conclusion

    While it won’t always be easy, it’s important to take some time this spring to get your DevOps teams looking squeaky clean. Don’t forget to focus on polishing up your processes, training team members and sprucing up your stack to ensure release cycles are on time—and spotless—by the time the summer rolls around.

    — Eran Kinsbruner

  • There’s No Such Thing as DevSecOps

    There’s No Such Thing as DevSecOps

    Should DevSecOps be categorized separate from DevOps?

    After years of debate, few doubts remain about the viability of the public cloud for enterprise workloads. Enterprises are shifting to cloud-first and cloud-only strategies, looking to take advantage of all the good the public cloud has to offer. For applications built and deployed in the public cloud, it is all about automation. The cloud enables you to be elastic, reduce costs and deliver products faster. To achieve these goals, you need to automate your processes—building, testing and deployment.

    Security Challenges of DevOps

    This need for faster innovation led to the rise of DevOps, a set of practices and tools that result in tighter collaboration between development and operations. In the past, controlling the deployment processes was the responsibility of dedicated teams that wrote scripts. However, with DevOps, development and deployment merge. Software engineers must do more than write their infrastructure and business logic code; they also need to write the automation that surrounds it and take responsible for deploying it through the different stages until production.

    However, even as development and operations come closer together, security has remained a function apart. While DevOps workflows are heavily automated, security checks for application and infrastructure code often are manual. DevOps and security teams are measured differently—delivery versus protection—and often are at odds with each other. The siloed approaches to security hardening that worked in the past are incompatible with the holistic, iterative software development and deployment model of DevOps.

    For a developer, adding the responsibilities associated with DevOps is not complicated, but securing the environment is a different level of challenge that requires mindset shifts in multiple areas:

    1. Knowledge: Software engineers are great at writing business logic. They write efficient code and develop highly available environments that can handle millions of concurrent users. However, the vast majority of developers don’t know about the latest CVEs or the proper configurations of SSL/TLS in the load balancer.
    2. Pace: Successful development organizations move fast, frequently adopting new development trends and frameworks. Public cloud vendors release new features every week, and it can be difficult to follow and keep up, as engineering is usually measured by the ability to deliver and the quality of output. DevOps enables rapid release cycles, and the security must not hold them back.
    3. Scale: Modern applications make the transition to work with microservices. When each development team owns its cloud environment (and sometimes multiple environments), the security teams suddenly find themselves dealing with huge distributed deployments. They can’t manually configure security when new features are released a few times a day in different environments.
    4. Heterogeneity: Multi-cloud deployments are another emerging trend. New product teams are often given a free hand choosing their tools and infrastructure, and they may pick a new cloud vendor. While security teams have a voice in this decision, they do not have the last word. It may have taken the security team years to learn to deal with the existing cloud solution, and suddenly the organizational policy needs to be applied across different infrastructures.
    5. Consistency: Enforcing organizational policy across different development teams is challenging. Each team has its own style, environment and development frameworks, meaning it’s never easy to ensure the security is applied uniformly.

    However you choose to address all these challenges, one thing must be clear: Your DevOps cycle is not complete without handling the security.

    Choosing a Security Solution

    Clearly, you can’t deploy services without properly securing them—you don’t want anyone to hack into your systems and steal your (and your customers’) information. Since cloud environments are dynamic and deployments tend to span across dozens of accounts, manual steps are not an option. Automation is necessary. Whether you acquire an enterprise security solution, adopt an open source security project or write your own tools, you need to make sure that they are:

    1. CI/CD ready: The solution can easily integrate into the continuous integration/continuous compliance pipeline. User-friendly APIs are required.
    2. Scalable: Assessing hundreds of cloud environments requires the solution to be scalable and robust. When covering more cloud vendor capabilities, performance becomes critical and increasingly challenging.
    3. Flexible: Each organization is different, and security needs can vary with each deployment. The baseline configuration of your security solution will never meet your requirements by 100 percent, so it’s important that you be able to adapt it to your needs.
    4. Continuously updated: Cloud vendors add new features at a rapid pace, which also means new potential misconfigurations are generated all the time. Whatever solution you choose, it needs to match the cloud vendors’ speed and agility. Security solutions that are not being updated soon become useless.
    5. Conveniently Reportable: Aggregated reporting is critical. Consuming the security findings in a convenient manner can assure that issues are properly mitigated.
    6. Automatic remediation-capable: Many of the findings are easy to remediate automatically. Applying automatic remediation would enable the security team to focus on complicated tasks and reduce alert fatigue.

    DevOps and DevSecOps Are (or Should Be) the Same Thing

    Security is clearly an integral part of DevOps. DevSecOps is emerging to bring security and compliance management practices in line with the rest of DevOps. DevSecOps serves to call out the temporary chasm that exists between security and DevOps.

    As security checks and controls get automated and integrated, DevOps and DevSecOps are converging to the same thing. Just like adjusting the mirrors and putting on the seat belt are part of standard procedure before pulling your car out of the driveway, assessing your security posture before releasing a new version of your product must become habit. To remain relevant, your security team must integrate into the CI/CD and make sure the newly created environments meet organizational policies.

    — Offir Zigelman

  • For DevOps, (Organizational) Size Matters

    For DevOps, (Organizational) Size Matters

    When it comes to DevOps, size matters. The number of people in your organization, as well as the size of its infrastructure, play a huge role in shaping how and why you adopt DevOps.

    The importance of company size may come as a surprise. Few conversations about DevOps mention the role of organizational size in building a strategy.

    That may be in due, in part, to the fact that DevOps engineers tend to be obsessed with the idea of scalability. A healthy DevOps process is one that can support an application with a million users just as effectively as it supports an application with a hundred users.

    In theory, your strategy should be similarly scalable. But in reality, this is unlikely to be the case. The way that a company with a dozen employees does DevOps is going to look quite different from the way a Fortune 500 company does.

    Small Companies

    In a sense, DevOps is easiest to achieve at very small organizations. In fact, it is almost inevitable in companies of this size.

    That’s because, when you have a very small IT staff, your engineers will end up playing multiple roles because that is the only way that all IT tasks can be completed successfully. People you hire as developers will have to help support and test the apps they write because otherwise, those processes might not happen.

    What this means is that at small companies, it tends to be something that happens organically, not deliberately. IT teams at such organizations don’t need to plan a DevOps strategy; they just need to let it come into being of its own accord.

    Large Organizations

    You might expect the opposite to be true within large organizations. But in many cases, it’s not. Large companies may also find themselves building their strategies organically.

    The reason is that, at large enterprises, the IT organization tends to be broken down into many small teams, each working on different apps and processes. Because these individual teams are small, their members also tend to embrace DevOps practices by performing multiple IT roles, whether deliberately or not.

    True, large companies often benefit from planning and implementing a companywide strategy. Encouraging DevOps best practices companywide can help to improve collaboration between different teams within the organization. It can also improve the ability of security or QA teams, which may otherwise operate in silos, to interact with other groups.

    But by and large, if you are an enterprise whose IT staff are broken into a number of small teams, you will likely find that DevOps happens more or less on its own.

    Medium-Sized Organizations

    It’s medium-sized organizations that tend to have the hardest time doing DevOps effectively. That’s because these organizations are large enough to have a sizeable IT organization, but too small to break that organization down into multiple project teams.

    As a result, medium-sized organizations erect the most rigid silos around their IT teams. They might have a single team of developers who focus on building a few applications, and a single IT Ops team whose job is to support those applications. But these two teams may not interact much.

    For this reason, a deliberate DevOps strategy is most important for organizations that are of a medium size. Their silos need to be broken down actively.

    Conclusion

    The bottom line: When it comes to adopting and improving DevOps, take some time to evaluate how the size of your organization impacts it. Is your company sized and organized in such a way that it will more or less happen on its own, or do you need to take deliberate steps to implement it? Answering this question is crucial for achieving DevOps in the most seamless way possible.

    — Chris Tozzi

  • DevOps Chat: DOES London Session, ‘Compliance and Audit Readiness: The DevOps Killer?’

    DevOps Chat: DOES London Session, ‘Compliance and Audit Readiness: The DevOps Killer?’

    The DevOps Enterprise Summit (DOES) is coming to London at the end of June. DOES London boasts an incredible lineup of speakers and presenters. One DOES London speaker is Ann Marie Fred, who will be presenting, “Compliance and Audit Readiness: The DevOps Killer?” In this DevOps Chat we caught up with Ann Marie to find out more about her presentation.

    As usual, the streaming audio of our conversation is immediately below, followed by the transcript of our conversation:

    Alan Shimel: Hey everyone, it’s Alan Shimel, DevOps.com and we’re here for another DevOps Chat. Today’s DevOps Chat is one of a few we’re doing as a run up into the DevOps Enterprise Summit in London coming up later in June.

    Our guest today is a featured speaker at the DevOps Enterprise Summit (DOES London). It’s Ann Marie Fred of IBM, and Ann Marie, of course, I’ve forgotten your title because it happens but would you mind sharing with our audience?

    Ann Marie Fred: Sure. I’m a Senior Engineering Manager and I work in the commerce platform so that’s IBM’s commerce engine for selling things online.

    Shimel: Fantastic. And Ann Marie this is not your first time speaking at a DOES event, correct?

    Fred: That’s right. I spoke in 2016 in San Francisco and I really loved the conference: I had a great time and I learned quite a lot there so I’m definitely looking forward to London.

    Shimel: Fantastic. So Ann Marie you know I always ask this of people who if you haven’t been to a DOES event and you’re into DevOps or you want to be into DevOps or so forth it really is such a great camaraderie – it’s a great place to be. And for me it’s really about two reasons. Number one, I think the presenters or the speakers at DOES are second to none. You get really, you know, really great insight into real DevOps transformations at organizations throughout the world and whether it be a so-called vendor like IBM or even Electric Cloud or Tasktop or one of these or a practitioner in a large – as Gene calls them – horse – you know a large enterprise, not a unicorn – it’s fascinating to see.

    Because even organizations like IBM so much of their own DevOps offerings are based on eating their own dog food – on their own DevOps transformation, if you will. You know what I’m saying?

    Fred: Absolutely. So yeah, we teach other people how to adapt DevOps but we’re also constantly learning ourselves and it’s great to sort of be together at a conference with people from other large companies who are running into similar problems.

    Shimel: Yep. And you just hit the second thing. Beyond the great speakers the camaraderie of being able to network with people who have similar problems to you. And I think that goes right to the nitty-gritty of human nature, right? You know, not misery loves company but we like to understand we’re not the only one who are facing these challenges or thinking about these particular ways of doing it and it’s great to hear from other people who in similar situations are doing really interesting things.

    And I think that’s really – that really is what I think makes DOES I think a special conference.

    Shimel: Yep. That being said though Ann Marie your talk in London this year is entitled “Compliance and Audit Readiness the DevOps Killer.”

    Fred: That’s right. It does have a question mark after that but –

    Shimel: You know, I’m sorry. The DevOps Killer? I’m giving my inflection. But tell us what exactly do you mean with this one?

    Fred: Yeah, well, you know we always had compliance and audit readiness as a thing that we care about but with the run up to GDPR we had to put a lot of focus on it. And in addition to GDPR we sort of took that as an opportunity to make sure that we had our ducks in order with other things like accessibility, IT security, open-source checks.

    You know, the thing that we always tell people they should do – they wanted us to get to the point where we’d actually documented in a consistent way how we were doing them. And so it was a lot of work.

    Shimel: Well, I mean just – we have some folks on listening who are not up on GDPR but obviously GDPR is the privacy and personally identifiable information rule that is EUI but really when we say EUI because the world is so interconnected it’s going to affect almost everyone. And it goes into affect May 25, so by the time you present at DOES London we’ll already be one month into the official rollout of GDPR.

    So to be fair Ann Marie people have known about GDPR and when it was going to go into affect and what was in it for going on two-plus years now, correct?

    Fred: Mm-hmm. Yep. Yeah, I was going to say I think it took a good year for us to start to figure out what the implications of the thing were.

    Shimel: And you’re not alone – you know, a good year. I think, believe it or not – you know we cover a lot of DevSecOps whether it be on DevOps.com or on our Security Boulevard site and I think there are a lot of people who even right now are a month out and are saying, “Gee, we better get serious about this,” you know? So a year isn’t so bad.

    But let’s talk about – first of all – let me back up a second. You know what? Some people still view compliance and readiness almost as separate and apart from traditional security, let’s call it, and as we were talking about it off mic in my mind I’d love for us as a whole – as a world – to move to the point where compliance readiness, cybersecurity are really intertwined with quality, right? If you’re releasing quality software, quality applications, quality services it’s compliant by design and compliant by practice. It’s secure by design and secure in fact. And until we get to the point when this stuff is part of our quality I don’t know if we’ll ever be successful. What do you think about that statement?

    Fred: For us? Yeah, exactly. For us part of this whole initiative was – I mean we use exactly those terms, right – secure by design – and what does it mean to be secure by design and what is an example of what you would do to be secure by design and are you doing that and would you sign a document stating that you feel like you’ve done what you need to do to be secure by design?

    So we’ve done a lot of prep work, I would say, and like best practices sharing to make sure that we’re not all inventing the wheel here, you know?

    Shimel: Well, let’s be fair. I don’t want to take credit for the term “Secure by Design” either. I think that comes right out of the GDPR and your reference to people having to sign off that it is secure by design that’s also in the GDPR, correct?

    Fred: Yep. Yep. And you know you have to have it documented somewhere so we all have these compliance folders. Yeah, so a lot of my talk is about how do we get from knowing nothing about GDPR and having pretty poor documentation in some cases to a state where we’re confident as a company signing legal agreements with other companies saying that we’re GDPR compliant ourselves, right?

    Shimel: Yep. So Ann Marie we’re talking about ten minutes and its time to really now – let’s zero in on this talk you’re giving. The DevOps Killer. Why is it the DevOps Killer?

    Fred: Well, it takes time to document all of these things and it takes a lot of manual effort the first time you do it. And one of the challenges that’s unique to DevOps and continuous delivery is that unless you make a special effort you might not even know what all the services are in your organization, right?

    Shimel: Mm-hmm.

    Fred: If people can just spin up a service in the cloud without a second thought have they told anybody that that service exists so that you can ensure it’s compliant, right? So that’s kind of step one. And then it’s almost inevitable that it’s going to be manual the first time but how do we make sure that we don’t have to rerun the entire manual check every single time we deploy the software? You know, how much of this can we actually automate?

    In some cases we can actually write tests for these things, so – because nobody really wants to keep paying that manual price.

    Shimel: No, for sure not. For sure not. So one of the things – I was talking to someone yesterday or the day before and I mentioned that one of the things we seemed to have moved away from in DevOps – and I’m glad we did – was the frequency of release and the speed, right?

    So, “I release 12 times a day,” “Oh, I’ve got you beat. I release 25 times a day,” “I release 100 times a day. And somehow the more releases I did a day the better at DevOps I was.” Right? And always said speed kills, you know? And what’s the right speed or the right release rate for your organization – whatever it is, right? And that is very different than the next organization.

    So in my mind it – yes, not just compliance but security in general can be a drag on release velocity, if you will. But there are good drags and bad drags, right, and it’s interesting, we did a survey a while back Ann Marie and you know developers – when we filtered it by developers – developers said, “What’s the biggest drag on getting your releases out faster?” They said, “Security,” overwhelmingly.

    And then the next question was, “Do you want that drag? Or in essence is that drag the right thing to do or what do you count on to ensure the quality?” And they said, “Security.” So sometimes being the drag but making sure things are done right and compliant and no one’s going to wind up – you know, the fines on GDPR are pretty stiff – is just part of the business cycle that we need to figure into things.

    Fred: Yeah. I mean we compared – internally we compared GDPR to __2K problem – the Y2K problem – that’s what I mean.

    Shimel: Yeah, __2K is another one.

    Fred: Yeah. But the Y2K problem. And we had to investigate every single service that we have and figure out which ones process personal data – and it’s a pretty broad definition of personal data – and then for each one of them make sure we’re compliant. And then now that we’ve done that once how can we still continue to deliver changes to production? I mean, yeah, some services are managed to deploy several times a day and some are every other week but nobody wants to redo the entire audit every time, so what processes can we put into place to make sure that we just don’t break things?

    You know, usually it’s a combination of every time you have a new feature here are the questions you have to ask yourself. And every time you do a code review here are the questions you have to consider, right? And then that combined with some regular reviews – maybe annually, for example – is I think the most pragmatic way to ensure that you’re actually doing what you need to do.

    Shimel: Absolutely. And you know that’s a good word to use when we think about compliance and audit and time drag – it’s about being pragmatic. Another concept Ann Marie that I heard – where the heck was I? – I think it might have been – I was out at the RSA conference about two weeks ago and we were doing a panel on Dev Sec Ops and stuff and the concept was sort of minimal MVP, right – Minimally Viable Product – Minimally Viable Security – so, look, there’s a pragmatic balance to be struck in terms of how much testing, how much security we do prior to release but we’ve got to at least define what’s the minimum that is going to keep us above water and understanding that in a DevOps way even after we release we can iterate feedback loop and iterate and continue to improve our security and compliance and audit readiness, you know, and that’s part of DevOps too, right? It’s never fully baked: you’re always continuously improving.

    And so the concept of a minimal viable compliance and audit readiness posture that would allow you to green light something being deployed versus 100 percent is something to consider. What do you think about that?

    Fred: Right, exactly. I mean you could take this to the extreme and you could say, “Every single place where an IP address – which is by the way personal data – shows up in my system it has to be encrypted in a way that the data can never be decrypted again.” You could say that but then you wouldn’t be able to maintain your system, right?

    Shimel: Yeah. It would be a monster.

    Fred: Right. So, okay, that’s not the right answer. So now it’s about, “Okay, what controls do we need to put in place to make sure that a random person off the street can’t get our logs?” and that that information is protected enough that we don’t think we’re going to get hacked and if there was an attack on our system that the scope of it would be very limited and they wouldn’t be able to do much with the data that they got, right?

    So yeah, it’s all very – there’s a lot of judgment involved in this and what’s your risk tolerance?

    Shimel: Agreed. So Ann Marie believe it or not – I told you the time goes really quickly – we’re coming up on – well, we’re probably past our 15 minutes – so we’re going to need to kind of start tying a bow on this.

    For people listening – and they’re listening to this before GDPR is in affect – it’s not too late. But for those who have just procrastinated too long what’s the best advice you can give them right now?

    Fred: Whoa. Well, I guess I would say don’t be afraid to start, right?

    Shimel: Right.

    Fred: It’s better to do the best you can –

    Shimel: Than do nothing at all.

    Fred: – than to be completely overwhelmed and say, “I can’t even think about how to start on it.”

    Shimel: And you know what? That is excellent advice though because that is the problem. So many people get paralysis by analysis, right, or they’re just so – you know, they look at this monolithic GDPR and all the articles and everything and they’re like, “Oh my goodness, we’ve got so much to do.” But it all starts with the first step. And from what I’ve been told Ann Marie no one – the E_U is not levying any fines or anything any time soon but you’ve got to start somewhere.

    Fred: Yeah. If I were to say, you know, two things that we expect quickly – I think just basic IT security – like having basic IT security processes will cover you for quite a lot of it. And the other thing we expect to be hit with very quickly is the data subject access request –

    Shimel: Yep.

    Fred: and deciding how you’re going to handle those requests because they’re going to come in fast and furious I think.

    Shimel: Yeah, I agree with you. And, you know, I think you’ve just got to get started with it.

    Anyway, so we’ve got that Ann Marie. You are speaking – in case anyone going to DOES is interested they can find it – I think DOES has published the entire schedule now – but you’re speaking on Tuesday, June 26?

    Fred: Yep. That’s right.

    Shimel: And I think it’s out in – at 2:35 PM which is 14:35 over in the UK and in Breakout Room B as in boy. So anyone listening who’s going to DOES come check out Ann Marie’s talk at DOES London and maybe say hello afterwards or before.

    Ann Marie I’m sure it’s going to be a great talk. We’ve heard you speak before. And thanks for joining us today on DevOps Chat.

    Fred: Yeah, thank you Alan, it’s been fun talking to you.

    Shimel: Absolutely. Ann Marie Fred, IBM and a DOES London speaker here on DevOps Chat. You’ve just listened to another chat. We’ll see you soon. Until then, have a great day everyone.

    — Alan Shimel

  • How DevOps Replaces the BYOD Mindset

    How DevOps Replaces the BYOD Mindset

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

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

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

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

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

    New Mindset

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

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

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

    Bring-Your-Own-IaaS

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

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

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

    — B. Cameron Gain

  • Living in a DevOps World (Part 1)

    Living in a DevOps World (Part 1)

    The concept of DevOps has grown and evolved into a conceptual and working model for more effective and efficient software development and implementation. That said, there are some differences of opinion on the real-world value of any DevOps approach to date, and on the best way to create and implement a real-world DevOps environment. This two-part article will focus on what an agile DevOps approach is meant to address, and what it is not meant to address.

    DevOps sits at the nexus of three essential business technology functions: software development, quality assurance and operations. A short and concise definition of DevOps proposed in 2015 seems as appropriate as any:

    DevOps is a set of practices intended to reduce the time between committing a change to a system and the change being placed into regular production while ensuring high quality.

    The definition was suggested in the book, “DevOps: A Software Architect’s Perspective,” and the authors have hit upon the essence of the practice. The key, of course, is how to put that concept into practice.

    Perhaps the first step on the journey to effective DevOps is the recognition that the concept is the result of the rise of the Lean and Agile software development methodologies. Those methodologies, among other things, emphasize the following:

    • A focus on customer value.
    • The elimination of waste.
    • Reduced cycle time (accomplishing work faster, releasing faster).
    • Shared learning.
    • Avoiding batching (don’t do things until required).
    • Theory of constraints (break things up, focus on individual issues).
    • Continuous integration, testing and delivery.
    • Faster time to market.

    DevOps in Practice

    Adherence to the principles above meant that something had to be invented to accomplish them and that something was DevOps. Over time, an effective DevOps practice should address any number of business technology pain points. The following short list of those pain points and the DevOps response should prove instructive.

    System Downtime

    The developers’ curse since systems were developed, system outages are inevitable as long as systems are designed, tested and implemented—even with increased automation—by imperfect beings. DevOps acknowledges that by changing the focus from trying to create applications that never fail to designing systems that can recover quickly, thus decreasing aggregate systems outage time over the life cycle of any application or system.

    Stagnation

    This was a staple of traditional systems development and is most closely associated with the waterfall methodology for systems development. After requirements were created, the development team would be locked away for weeks, months or, in some cases, years before emerging with “fully” working software that inevitably no longer satisfied rapidly evolving business requirements. DevOps is designed to fit hand-in-glove with the Agile practice of short windows of incremental changes instead of long release cycles, putting working software in the hands of customers as quickly as possible.

    Team Conflict

    Having been borne from the cultural combination of Agile and Lean, DevOps has taken on the problem of functional silos that are often erected between development, operations and the business customers. It follows the methodological approaches of collaboration and teamwork first to understand what others know and to leverage the best of it to solve business problems more rapidly. There is also a cultural bent toward experimentation, continual learning and constant improvement. This leads to blameless post-mortems, where instead of finger pointing when something goes wrong there is collaborative discussion and learning to correct and prevent the problem from occurring again.

    Knowledge Silos

    Functional silos have led to compartmentalized knowledge. If the old game was that knowledge is power, the new game in the DevOps world is that knowledge is freely exchanged as an enabler to solving business problems. DevOps addresses the problem of information being lost in translation between the development and operations functions by eliminating the functional barricades and making knowledge sharing the highest form of collaboration.

    Inefficiency

    Waiting for things to happen used to be a standard operating procedure in the pre-DevOps world. Project plans were created and managed to account for the time it might take for new code to be moved into a testing, quality or even production environment. This was a momentum killer for projects and at times a morale killer for developers waiting to see what changes they might need to make to their code set. The combined Agile and DevOps approach has rewritten the traditional approach to code migration, smoothing and eliminating wait times so that projects flow more seamlessly from start to finish. It also has the benefit of keeping business resources—testers, approvers, etc.—more engaged as a result of a constant flow of new functions and features to test and use. And lest this be viewed as simply a way to keep the technical stuff moving along, it’s important to remember that there is a financial aspect to this as well. Reducing speed to market with new functionality, reducing or eliminating idle hands—be they technical or business—and delighting customers with a steady stream of enhancements and features all go directly to an organization’s top and bottom lines.

    That, after all, is in many ways what the DevOps approach is all about. All of these critical areas become the means to accomplish it. Part two of this article will focus on some more of the benefits of a DevOps approach, and how to achieve them.

    — Dave Farinelli