devopsy.kinsta.cloud

Tag: transformation

  • Piecing Together the Elements of DevOps Transformation

    Piecing Together the Elements of DevOps Transformation

    Sometimes when a concept as transformative as DevOps comes along, it’s easy to forget that subsequent adoption represents a highly complex and iterative process.

    While it’s clear that some organizations are already deeply leveraging DevOps to embrace the Applications Economy and Digital Transformation, it’s no surprise that for many organizations this process has only just begun.

    So where have today’s organizations made the most progress, and what are the most significant challenges that practitioners continue to face?

    To get a better fix on the current state of DevOps maturity and isolate the specific areas where most organizations must continue to focus their attention, researchers at Freeform Dynamics have created a matrix of practices key to measuring progress, dubbed the “DevOps Jigsaw”.

    Drawn from the same survey data recently surfaced to profile leading-edge “Digital Disruptors” that have already wrapped their arms around DevOps advancements, this latest report, sponsored by CA Technologies, offers a crucial view into the current environment.

    It’s worth noting that of the 1000-plus respondents included in this particular data slice, the vast majority, or 80%, are categorized as “Early or Limited” adopters, with only 20% recognized as “Advanced”.

    Of the nine individual DevOps “puzzle pieces” examined in the report, experts grouped these efforts under three umbrella categories: “Key Enablers and Controls”, “Skilled and Collaborative IT”, and “A Business Led Approach”.

    Business Led Approach – This subset encompasses strategy and objectives required to tie DevOps adoption to larger business goals, including:

    • Well-defined strategy and objectives – In this key planning stage of DevOps transformation, 55% of respondents said that much of their work is “already done”, while another 36% charted it as “a work in progress”.
    • Business stakeholder education – Roughly 33% of respondents said that this informative step in DevOps adoption is complete, with a larger majority of 43% noting that they are still working to advance this process.
    • IT-business alignment of priorities – In getting stakeholders on the same page around business and DevOps direction, some 37% indicated that they are nearly done, with 43% of still attempting to embrace these efforts.

    Skilled and Collaborative IT – This genre of requirements covers the cultural and automation capabilities necessary to foster DevOps success, including:

    • Relevant IT knowledge and skills – Related to the development of DevOps expertise, 39% of respondents feel that they’ve already made the grade, with 40% conceding that they have more homework to complete.
    • Cross-functional IT processes – As much as any related initiative, DevOps mandates tighter internal collaboration, with only 35% of respondents having achieved this goal, and 45% citing the need to keep pushing.
    • Cultural harmony within IT – On a related note, DevOps teams must work together smoothly to succeed, with a mere 29% of respondents claiming such parity, offset by 46% that acknowledge a teamwork deficit. 

    Key Enablers and Controls – This category of DevOps maturity addresses key issues of technology, solutions acquisition and IT security, including:

    • Right infrastructure and tooling – Efficient tooling and infrastructure are another key DevOps enabler, with some 37% of respondents feeling good about their current solutions, and 42% still looking for answers.
    • Right suppliers and support – In sourcing the products and services required to advance DevOps process, only 33% of respondents said that they’ve found the right providers, with 46% still seeking additional help.
    • Security and compliance measures – No area of IT can be addressed without consideration of security and audit issues, with 35% of respondents comfortable with their controls, and 46% in need of added defenses.

    Given these overwhelming results, it’s clear that most organizations still have a long way to go in achieving greater DevOps maturity; at the same time, there’s also plenty of evidence that today’s practitioners have already made a good deal of progress.

    Comparing your efforts to these established “DevOps jigsaw” puzzle metrics should help inform future strategy in creating a more cohesive framework of people, process and technologies, and deliver DevOps success.

  • DevOps Chat: Gary Gruver, Leading the Transformation

    DevOps Chat: Gary Gruver, Leading the Transformation

    I recently had a chance to sit down with Gary Gruver, well known DevOps leader and author. Gary’s new book, Leading the Transformation, Applying DevOps and Agile Principles at Scale is a great how to for managers looking to lead the transformation at their respective teams.  Gary put on a very informative webinar which you can listen and watch that goes into much greater depth than this short conversation.

    I have posted both the audio file to listen to and a transcript of our conversation below.  Enjoy!

    [soundcloud url=”https://api.soundcloud.com/tracks/224098337″ params=”auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false&visual=true” width=”100%” height=”450″ iframe=”true” /]

    Here is the transcript of the conversation with Gary Gruver. You can follow along with the audio file or just read if you like:

    Alan Shimel:         Hi. This is Alan Shimel, Editor in Chief of DevOps dot com, and welcome to another DevOps chat in our leadership suite. Today’s guest is DevOps thought leader, and well-known author, Gary Gruver, who has just published his book, Leading the Transformation, Applying Agile and DevOps’ Principles at Scale.

    Gary, welcome to DevOps Chats.

     

    Gary Gruver:                Hi Alan. Good to be here.

     

    Alan Shimel:                Thank you. Gary, first of all, let me just commend you. The new book is great. I think I mentioned to you offline, I read it on the way out to California, and back. I went back and actually highlighted a bunch of stuff, which I don’t often do with books anymore, but it was that good and that important to me.

    So great job on the book. For those of our readers who may not be familiar with both yourself and the book – why don’t you give us just a quick background and synopsis of Gary and the book?

     

    Gary Gruver:                Well I’ve been in high tech for a long period of time and the last, probably eight years, leading large scale transformations of software development projects in different organizations, first at HP as the Director of the Imbedded Firmware Organization, over about – we started with 800 developers.

    And I wrote my first book because the results and benefits that we saw with that were so dramatic, and I learned so much from the organization and the transformation that I just felt that I had to share it with everybody else, do that’s a practical approach to large-scale actual development. It’s kind of a case study at HP.

    And that kind of gives you a feel, a short, quick, easy to read, not very technical book for executives that just – here’s what a transformation looks and feels like. I’ve gotten more actively involved in the Agile and the DevOps community and learned a lot by going to a large retailer, and was head of QA Release and Operations at that retailer, and led a large transformation towards continuous delivery there.

    And what I found through the process is, it’s easy for engineers to go to different conferences and understand how to develop differently, but if the executives don’t engage in leading the transformation, they’re going to come back, and the organization is going to throw a wet blanket on it. So what I tried to do with the second book, which Leading the Transformation is, is write down and capture in a book that was short enough – 100 pages – so that executives would read it, but had everything I wished I knew before I started on my transformation. So look, there’s going to be uniqueness and differences with different organizations.

    But the more they can avoid the bumps on the heads and the learnings that I’ve already gotten to on my own, and moved forward, and kind of moved the process and the technology forward, I think the more effective they’re going to be. So I created a lot of passion around trying to get some great business benefits.

    And I really wanted to share with others and try to figure out how I could help others to be more successful too.
    Alan Shimel:                Absolutely. So, Gary, one of the interesting things I got out of your book was – you know, many executives, they hear of the benefits of Agile and DevOps, and where do they sign up, right? Sign me up for that. I’d love to see those kinds of exponential improvements in all of these metrics.

    But one of the things you say is – executives who are just looking to do sort of Agile in and of itself aren’t going to see that sort of success, correct? It’s not just doing Agile, if you will. As a matter of fact, if you say that you do just Agile, you’re probably not going to be very successful. Do you want to expand on that?

     

    Gary Gruver:                Yeah. I would say it’s too large of a transformation and too large of a turmoil. If your current development processes are meeting all the needs of your business, you really shouldn’t go through this much effort and turmoil in your organization and cultural change.

    But I think what most organizations are seeing is – they’ve got larger, and software has become more and more important to how they compete in the marketplace, that their current software development processes just aren’t able to react and respond to where they need to add value as a business.

    And so, start with what is not being delivered to your business from your software development processes and your business objectives. You know at HP, it had been two decades that firmware had been the bottleneck for the business, and so we really started by saying – we want to be able to add a new product anytime we want without firmware being the bottleneck, and we wanted to free up capacity for innovation.

    And it was with those business objectives that we were able to prioritize the things we went after, and I think if you start with your business objectives and fundamentally looked at the rest of your toolbox, whether it’s to add to laying DevOps, sort of combined automated – just any of those things are just tools in your toolbox that are there to solve a problem.

    And then you go on a journey of continuous improving. That’s where you get the business results. It’s not going after one of those principles and hoping that you’ll get business results. It’s driving for business results and using the tools as appropriate.

     

    Alan Shimel:                Got it. And Gary, you use the term a lot, continuous improvement. In a world where continuous is the new black, and we hear about continuous delivery, and continuous integration, and continuous testing, and continuous security – briefly, what is continuous improvement?

     

    Gary Gruver:                Well it’s really wanting to go out and learn what’s between you and your organization delivering software better and more effectively. And then it’s constantly just chipping away at those barriers and learning and getting better involved. You’re not going to know everything.

    You know, at HP, we got two to three X improvements in productivity, but we didn’t go off on a three year plan to make that work. We took it month by month, and assessed some objectives, and tried to get better. And you’re going to learn so much as you really start getting out there in trying to figure it out that, what you’re going to find is, if you create a three year plan, or even if your could, it’s going to inhibit you from getting better because you’re going to learn something new that was getting in the way.

    And so, don’t try to lock in too much. Software developed and improved effectively can be very flexible and responsive. Learn and adjust, and learn and response, and just take on the biggest barriers to your productivity one at a time. And when you improve that, you’re going to learn what’s next and continue to improve that.

    But it’s getting the executives to come together once a month to review what they said they were going to get done, what got done, and what didn’t get done, and what you’ve learned in the process, to set the objectives for the next month. You know, at HP, we went off trying to get 10X better, and we did it a month at a time.

    And when we looked back three years later, we had gotten, you know – my co-author would say, 10X better in terms of frequency, and builds, and those things, but business results – easily 2 to 3X better, but it wasn’t by executing a four year plan, it was by getting up after continuous improvement, and learning and adjusting along the way.

     

    Alan Shimel:                Sure. You know Gary, in the book, one of the things I got out of it is, you sort of refer to CD, continuous delivery, as a lot of the tools and maybe processes that we follow along this Agile and DevOps journey, if you will, or process. But DevOps specifically is largely cultural in the book anyway. Is that correct?

     

    Gary Gruver:                Yeah. It depends on whether you’re talking to Gene or Jez. Jez will focus more on the technologies, and Gene will rely on the culture. I can’t really separate the two. You can’t get the cultural changes without the tools, and you can’t implement the tools and get the benefits without the cultural changes.

    I like the definition where you just lump them together and say – it’s the cultural and technological changes that enable us to release code on a more frequent basis, in a more stable way, and get feedback from our customers on an ongoing process. And so that’s the definition that kind of resonates with me, and I have a hard time getting between the two.

    But you know, in a large organization where you’ve got tightly coupled code that requires people to develop, qualify, and deploy in unison, the technologies of continuous delivery, whether you deploy everyday or not, is the forcing function that ensures all your code is going together and stays aligned.

    And so the first order of effect in a large organization is to help it come together to deliver code, or deliver value to their customers, on an ongoing basis. And the second order of effect is how the individual teams work, continuous delivery, and some of those principles are the forcing function that allows working code to provide that alignment across a larger organization, and not develop code that either won’t work together or won’t work in a production like environment.

     

    Alan Shimel:                So Gary, another sort of debate – and I don’t know if it’s a Gene and Jez debate, but it’s certainly within the community – is, do you do DevOps from top down, bottom up? Do you do it from both and meet in the middle? You have a very unique perspective in having led several transformations now and, obviously, you come at it from a top up perspective. What should leaders, listening to you here today, what should they take out of that?

     

    Gary Gruver:                I think if they’re going to be successful, the leaders need to lead it because you can’t have some groups decide to do it, or some groups decide not or do it in a different way, if their code has to come together and be delivered as a unit. But, at the same time, it’s not management.

    It’s more lead it. Set the direction. Set the priorities, and engage with the organization to learn what’s working and what’s not working. And so, you know, the continuous improvement, executive-led continuous improvement process I describe in my book really shows how the executives engage in the organization to lead that because you need all the learnings in everything that’s getting in the way from the bottom.

    And you need kind of the set of priorities from the top, so it’s that constant interaction between the leaders and the organization that gets all the best ideas and all the learnings out on the table, that gets you to prioritize the right things and go after the right improvements.

     

    Alan Shimel:                Yeah. Gary, the last chapter in the book is entitled, Getting Started, and it kind of represents, okay – after you’ve learned what you can from this book, here’s how you can get started in your organization. Of course, people should read it for themselves and learn from it, but what can you take out of that last chapter to give people a jump start on that?

     

    Gary Gruver:                You know, you really need to start where the most pain is. And one of the things that DevOps causes you to do is do things more frequently. And what you’ll find is your organization has been brute forcing its way through the same issues for years. And as you start to increase the frequency, you’ll have to start fixing that.

    And it’s hard to tell. For different organizations, it’s different places, which is why I put that piece at the back end because it depends on what you already have in place. If you’ve got a web micro services architecture that enables teams to work independently, it may be as easy as a cultural shift, and putting an operations person on that team, and letting him own things end to end.

    If you’ve got a more tightly couples system, you’ve got to think about how do you coordinate the work across them? And the first step may be, can you do continuous integration of as much of the enterprise system as you can, with a few simple tests? And make sure you’re automated correctly. So it’s that step of learning and evolving. And then as you try to do it and increase your frequency, you’re going to find different pain points.

    And that’s why I’d say it’s the continuous improvement stuff. And you know I do work shops with different executive teams to really try to bring out, and try to understand their development processes to the point that we can figure out where to start the continuous improvement process.

    We hold a work shop with their technical and manager leaders and everybody in the organization, and try to really nail – what’s that first month’s objectives? And then we do ongoing mentoring calls for the first six months to make sure they’re off on the right path.

    But you know, as opposed to spending forever trying to figure out where to start, if you can think about starting your continuous improvement process, even if you pick the wrong things first, you’re only going to go down that path for a month before you have a chance to learn, and adjust, and go after the things that are really in the way between you and your organization being productive.

     

    Alan Shimel:                Great. Hey, Gary, we’re about out of time.

     

    Gary Gruver:                Okay.

     

    Alan Shimel:                Thank you very much for appearing on today’s DevOps chat and, again folks, the book is, Leading the Transformation, Applying Agile and DevOps’ Principles at Scale. And for any executive or manager out there who is contemplating or perhaps is already engaged in leading a transformation around Agile and DevOps around software development, I highly, highly recommend it.

    You can get the book on Amazon. It is from IT Revolution Press, and just Google it. I think we also have a two chapter download, which we’ll put a link to up on the webinar page for this. Gary Gruver, thank you very much. This is Alan Shimel, of DevOps dot com. Have a great day.

  • Five things to understand about Enterprise DevOps Solutions

    Five things to understand about Enterprise DevOps Solutions

    There is a lot of buzz in the industry around selling and consuming DevOps. Unfortunately there isn’t the same level of understanding or even a common definition about DevOps between consumers and service providers. In my experience the past couple of years of evangelizing DevOps, the following 5 aspects come to my mind as critical factors while considering and implementing enterprise DevOps solutions:

    1. Evolving Architectural models

    If you are a geek like me, and if you haven’t heard any of the following terms, you’ll probably google them immediately – Container technology, Microservices architecture, single page web apps (SPA), Node.js, mobile web apps, The Internet of things (Mobile awareness, sensors & wearables etc.), web APIs – these are the current trends in the application development space. Almost all of them disrupt traditional architectural models. And the reason I point this out is because they’ll also disrupt your traditional software development lifecycle (SDLC). The number of code & deployable units is only going in one direction, and that’s up. Very rapidly actually! That means source code management, build management, deployment & release management, dependency management, all become so much more relevant and cumbersome. The ONLY meaningful way to make these kinds of disruption manageable is through a mature DevOps approach, and a robust platform to enable DevOps. Developers always want to do the new and coolest thing. Enterprises will be well served to adopt a DevOps strategy NOW, before their own developers will cause so much disruption, that their IT strategy may fall flat.

    1. Integration with existing security and governance models

    More and more enterprises are headed towards a hybrid model of IT which involves traditional on-premise data centers, public cloud, private cloud and consumption of domain specific Software as a Service & Platform as a Service capabilities. Hybrid model also poses the same kinds of challenges discussed with some of the new architectural trends. How do you manage releases across so many disparate entities and providers? A centralized DevOps strategy can help mitigate issues posed in a hybrid model to a large extent. But the question is – what about the corporate policies around security and governance? Do we throw away existing tools & capabilities around change management, ticketing etc.? Disruption is a good thing for innovation, but too much disruption can also lead to disastrous outcomes. One of the key challenges that I’ve encountered while implementing an enterprise DevOps solution is to integrate the platform with existing security models and tools. Not all of them work together seamlessly all the time. But the key to success is to evaluate where the gaps are, and only bringing in new tools or capabilities where necessary, and not just for the sake of it (sell a solution, not a bunch of products).

    1. DevOps enablement

    One of my mentors in IBM used to say, that “a fool with a tool, is still a fool”. How true that is in the world of DevOps! Tooling is a key ingredient towards automation. In fact the concept of DevOps is not new at all, but the kinds of tools available today make automation possible in so many levels that was unthinkable a decade ago. But just providing a platform of seamlessly integrated tools for SDLC isn’t going to work. A level of “design thinking” is absolutely necessary towards DevOps enablement. A DevOps engineer should always be slotted in as a key member of this enablement team. Someone that can coach teams while starting new projects on – What elements of the tooling would apply for them? How to on-board the DevOps platform? What elements of automation are already available vs ones that’ll need to be newly created? What will be the roles and responsibilities of current team members in a DevOps world? – These are the elements that enterprises struggle with. Without a credible enablement program, a DevOps strategy is bound to be very slow in adoption, or just simply fail.

    1. Transformation Investment

    An enterprise DevOps platform and enablement program doesn’t come for free. I’ve constantly been challenged with questions like – what Line of business (LOB) is going to pay for it? Can’t we just use “open source” and make this all free? Can we only pay for what & when we use? All these are fair questions. And the debate about centralized IT expenditure vs LOB expenditure isn’t a new one, and will not go away either. But DevOps is disruptive enough and WILL challenge some of these old ideas and habits. “Automation as a Service” is certainly a viable option that can be availed on a consumption model. Open source tools are available by the dozen. And what comes for free with open source tools is just the usage license, and nothing else. You’ll still have to integrate them with your platform, still write automation scripts and manage them, and enterprise grade tools are usually not totally free and there is some cost involved in acquiring and managing them. All that being said, DevOps IS very much an investment. It is an investment for speed of delivery, higher quality of deliverables through automation and perhaps some cost take out in the form of reduced or re-assigned resources that were performing traditional activities in SDLC. There are several models to ascertain return on investment (ROI) on such investments, but I’ll refrain from getting into that discussion in this article. I’ll just leave this with the infamous cliché – there is no free lunch!

    1. Top Down vs Bottoms up buy-in

    Typically I’ve been involved in DevOps strategy conversations for enterprises at the executive levels, and they seem to be all over it. They love some of the cost take out numbers when they see it, deployment cycle time reduction and aggressive time to market fascinates them. And legitimately so. Getting executive level buy-in and support is absolutely key for any transformation to be successful, DevOps included. But just a top down approach isn’t going to make DevOps successful. It is imperative to reach out to developers and architects under each tower or LOB and get their buy-in as well. Developers and testers love their tools and methods, and are very unwilling to give them up if the strategy calls for standardization of tools (which, by the way has to happen to some degree to gain efficiencies). DevOps also redefines roles in development and testing teams through the level of automation it brings in. This causes a lot of grief amongst the staff, and as a service provider and enabler, I’m sometimes perceived as the ‘enemy’, which is never a good sign for a successful transformation. Developers and testers also have the domain knowledge around how builds are done today, what the application component dependencies are, what test scenarios are more relevant and so on and so forth, information that is so critical to understand for automation. Make friends with the developers and testers to be successful.

    About the Author/ Sunil Joshi

    Sunil JoshiSunil is an Executive Architect with IBM. He is currently the Application Development & Innovation (AD&I) DevOps offering owner for Global Business Services. He is IBM Senior Certified and Open group certified Distinguished Architect. His specialization are in the areas of hybrid cloud solutions, platform as a service and DevOps strategy. He’s created complex hybrid solutions on cloud and DevOps for large enterprises. Sunil has authored several IBM Redbooks, blogs and also a co-author of the IBM Cloud Computing Reference Architecture (CCRA).

    Sunil is passionate about international music, multi-cultural cuisine, active sports and mentoring school & college students on career path and technology.

    Contact Sunil on  linkedin twitter

  • Netuitive’s Transformation to SaaS Delivery, Powered by Its New DevOps Shop, Part Two

    Netuitive’s Transformation to SaaS Delivery, Powered by Its New DevOps Shop, Part Two

    In part one, devopsy.kinsta.cloud presented Netuitive’s DevOps transformation, which helped the company to automate its product development processes. Now in part two, we take a look at that development process as it stands today.

    Netuitive Development & Technical Debt Initiatives

    “We are using a Feature Branch Workflow model with Git to isolate our work while we develop and test it,” says Brian Spindler, VP of Engineering, Netuitive. As soon as all teams and team members are in agreement, Netuitive merges the feature with the master branch and deploys it to the internal pre-release staging environment for further testing and verification.

    “In the old world, we released software twice a year,” says Spindler. After using the Scrum development process religiously and exclusively to take the software to beta, Netuitive drove the pre-release software through the testing ringer prior to releasing the packaged final product.

    “Now we release on a weekly basis,” says Spindler. The development team shoulders the unit, integration, and acceptance testing while Netuitive reaches forward to increasingly add features and polish its architecture.

    Netuitive is continually bringing the increasing technical debt into the black side of the development ledger, so to speak. Netuitive offers two examples of being technically in the red. The first is in the area of unfinished business. Incomplete or hacked up implementations typically happen when the team is developing outside the core technology stack, is cutting corners for speed, has a poor understanding of the software requirements in a given area, has to rush testing, or does not create complete and appropriate documentation, according to Spindler.

    The second example circles library / dependency updates, where falling behind can lead to numerous interrupts and blocks for features / bugs / requests that are at the top of the queue, Spindler explains. “Often times in either of these two sample areas, a theme will emerge and that can be a good indicator that it is time to start paying down the technical debt in that area,” says Spindler.

    Netuitive puts that debt under a microscope where through transparency and visibility, it can review the bugs on a regular recurring basis and, as soon as an engineer catches something that is offensive to the software, he can create a ticket in JIRA to put it on the backlog to address, according to Spindler.

    “However, it doesn’t always make sense to ticket something if it is not actionable,” says Spindler. In such cases, Netuitive will catch those instances of technical debt in the Technical Roadmap Idea Board that it maintains, which captures three verticals: the development environment, the technical debt, and the architectural / structural vision, according to Spindler. “Any team member can contribute to this Board. To keep everything on it in perspective, we hold retrospectives regularly,” says Spindler.

    Changes, Experiences

    “It was a positive experience seeing how we handle bug fixes differently after switching to a SaaS model,” says Spindler. Now we understand bugs that we fix very well and we easily duplicate them for isolation and to excise them from the software. That’s because the developer has full access and freedom to debug the same system that he reports on. This eliminates the tedium of setting up systems and testing and repairing for edge case scenarios, according to Spindler.

    “We were also positively surprised at how quickly something can go from concept to production,” says Spindler. To make that possible, there is an opportunity cost in that development has to be willing to sacrifice, to try something while risking having to toss something aside. “In the SaaS world, it’s all about trade-offs, fast vs. refactoring, pay off that technical debt or put out feature XYZ. When you have a team like ours, everyone’s time is critical, and we work hard at prioritizing and balancing that,” Spindler says.

    To maintain the balance and improve the team’s precision and good judgement over time, Netuitive follows Kaizen, which is a continuous improvement methodology. “As the team grows and changes, so will our priorities and the way we work and build the system. We’ve got to be open to that and willing to embrace it,” says Spindler. Regular retrospectives and transparency help to make that possible.

  • Netuitive’s Transformation to SaaS Delivery, Powered by DevOps, Part 1

    Netuitive’s Transformation to SaaS Delivery, Powered by DevOps, Part 1

    “Netuitive offers an adaptive monitoring solution for cloud infrastructure, applications, and services, powered by a patented self-learning correlation engine,” says Brian Spindler, VP of Engineering, Netuitive. The engine uses multivariate regression analysis to calculate correlation coefficients between metrics based on time-series data collected, leveraging the significance of certain relationships between metrics variables across the data.

    The Netuitive technology establishes a baseline of what metrics and their relationships have been historically. Netuitive policies enable development and operations teams to see anomalies that present with significance above the historical baseline and related to AWS EC2, Linux OS, MySQL, and other systems and technologies.

    “We have launched a SaaS version of our product wherein we now deliver code to production on a weekly basis,” says Spindler. This increase in deployment speed is thanks to the company’s new DevOps processes. Here is the first part of Netuitive’s two-part story.

    Before Moving to a DevOps Shop

    Before moving to a DevOps software development approach including continuous delivery, Netuitive used a Scrum framework together with Jenkins and Ant products and scripts the company developed in-house to develop Netuitive software and the patented self-learning correlation engine within. “We recognized the value of automation early on—using simple shell scripts and our own Web API we were able to orchestrate quite a lot,” says Spindler.

    Still, these methods presented challenges. The extensive planning process, including conjuring up development time estimates that Scrum requires for Sprints were challenging. In addition to and despite all that planning, numerous interrupts occurred surrounding testing and deployment issues that stemmed from software complexity and integration management. “These interrupts slowed us down and impacted our burn rate,” says Spindler. (The burn rate calculates the speed of the business spend above and beyond income.)

    Mountains of bug fixes were also a concern. With an exorbitant amount of time spent fixing bugs that would only present themselves in rare edge cases, Netuitive was putting too much effort into builds while getting too little in improvement or new features out of the process. “While we sought a solution for feedback loop issues, it became clear that this would require a more agile approach. We looked to DevOps for inspiration, which led us to migrate from Scrum to Kanban,” says Spindler. Kanban is an illustrative process for managing targeted production goals, including what to develop when and how far to extend that development.

    As enterprises adopting DevOps often mention, the cultural change necessary to move to DevOps approaches was the most challenging. In particular, getting everyone on board with automated testing as a proof of software validity was tricky. Internal teams such as QA and developers had to transform their existing relationship. “For years, these groups were adversaries; now I am asking them to be allies. This required the developers to take on the responsibility of writing tests while QA validates and ensures the tests are sufficiently broad,” says Spindler.

    Goals, Results, & Hazards: Method to Madness?

    Netuitive had specific outcomes in mind from switching to a more complete DevOps shop. Quality and productivity improvements were high on the list. In fact, the two would have to be mutually inclusive and close knit to ensure both. To accomplish this, Netuitive deploys on a weekly basis, using the full Atlassian suite for collaborations and issue tracking along with a combination of Bamboo, Gradle, and Salt Stack to automate the configuration, manage the infrastructure, and manage deployment operations. This orchestration helps quality and productivity to dance in harmony.

    The results are more than aesthetically pleasing. “We are increasing the velocity of deployments through continuous process improvements,” says Spindler. By deconstructing the Netuitive product and dividing it up into independent service modules and components, the company can move overall progress along more quickly by improving each individual component separately and simultaneously, making faster progress gradually than they would by waiting to finalize a single, complete product update.

    Netuitive experienced three fully distinct bumps in the road or ‘hazards’ on the way to morphing itself into a DevOps shop. “There were issues related to automating testing, changing the organizational workflows to accommodate automation, and deconstructing the product into granular enough services that we could deploy independently,” says Spindler. These were all related to the desire to automate the product production as a whole. Netuitive works continually to refine the necessary balance between layering on additional tests across those granular services to raise the bar on quality and excising some of those testing layers in order to increase deployment velocity.

    Tune next time when devopsy.kinsta.cloud reproduces the relative chronological Netuitive DevOps development process from release to release along with differentiations, benefits, and the payoffs that the company did not expect.