Category: Doin’ DevOps

  • Unlocking the Power of AIOps

    Unlocking the Power of AIOps

    AIOps is becoming quite the hot topic lately. It seems as though everyone is realizing that Ops is difficult. As we have to deal with more big data at greater velocity with more automation and complexity, there is no way humans alone can tame the beast. AIOps seems to be the answer.

    I recently sat down with Dave Link, CEO and founder of ScienceLogic to discuss how to unlock the power of AIOps to empower IT ops. We video taped the conversation, along with some accompanying slides that help explain what the challenges are that ops faces and what are some of the ways to tackle this using AIOps.

    I should mention that Dave and I are old friends, having worked together 20-plus years ago at a dotcom era company called Interliant. Since 2003 or so I have watched Dave build ScienceLogic into the powerhouse it is today. I couldn’t be more happy and proud of him.

    ScienceLogic has been named by EMA as a top vendor in the AI/ML for IT Operations. Dave gives us a good background on ScienceLogic as well as a good background on the use cases and challenges that IT Ops faces that AIOps seems to be the answer for.

    Dave also talks about the differences between AI and machine learning or ML. This seems to be an area of confusion today as well.

    The video is about 30 minutes and excuse Dave and I reminiscing, but there is some really great information here.

    Video on AIOps

     

    — Alan Shimel

  • How to Find and Hire Android Developers in 2018

    How to Find and Hire Android Developers in 2018

    A brilliant app idea demands no less a brilliant mobile development team. That means you have to take the time to search and recruit skilled Android developers and, correspondingly, overcome lots of challenges for this. Here are some tips to help you overcome the difficulties and mitigate possible problems in finding qualified Android developers.

    Roles and Responsibilities of Android Developers

    It’s always a good idea to dive deeper into your employees’ responsibilities. So if you have no technical background, this section will be rather useful for you as it tells more about the skills of a proficient Android developer.

    It’s worth mentioning that the technical skills of Android and iOS developers differ due to the OS differences. A particular set of technologies is used for each OS and if you want to hire iOS developers, you should check the skills they need to have according to the latest market demands.

    Skill Level

    In the IT industry, developers are divided into levels specifying their proficiency. These levels are:

    • Entry level means a developer hasn’t had much experience in developing software products. Junior Android developers typically work on simple projects and they’re curated by more experienced colleagues.
    • Experienced developers work on complex projects and don’t have managerial responsibilities.
    • Senior developers typically have 5+ years of experience and often lead big projects as well as supervise the performance of technical tasks.

    Responsibilities

    Let’s consider Android developers responsibilities in more details.

    UI Engineering and Business Logic Development

    Developers have to re-create the app’s design as well as develop its functionality. Additionally, they should predict what bugs may occur and prevent their appearance.

    Collaborative Skills

    In most cases, developers don’t work on a project alone. They are surrounded by other specialists and need to effectively collaborate with them in order to achieve a common goal: a well-functioning end product.

    Databases and Third-Party APIs

    Android developers should be good enough at reading code written by other developers since they will have to work with external APIs and databases during their projects.

    Unit Testing

    Modular testing is a kind of industry standard. Android developers have to perform it to test a certain part of the app’s functionality and fix any bugs. Unit testing is a part of agile software development that’s designed to create high-quality apps fast.

    Bug Fixing

    Android developers should make everything possible to deliver a bug-free and stable-working product.

    Types of Android Developers

    There are several types of developers you can choose from. Which one to pick depends on your preferences and project.

    • Freelance developers. This type can be a good choice if you are on a limited budget and you want to save as much money as possible. However, bear in mind that, in fact, you have no control over freelancer’s work and all that remains is to rely on their responsibility.
    • In-house developers. These are the ones working on your project at your company’s office. It’s a good option in case you already have an office space and you want to manage the development on your own.
    • Outsourced team. The scheme is simple: You hire a software offshoring company, explain to them your requirements and they build a project for you from scratch.

    Technical Skills of Android Developers

    Android developers must have a set of technical skills that actually make the app development possible. Underneath, we’ve listed basic technologies every Android developer should be able to work with.

    • Java: This is the official language for developing Android apps. This object-oriented language was created in 1995 and currently it’s the world’s most popular programming language. Every Android developer must have a decent knowledge of this language to build software.
    • Kotlin: This is the second official language for Android development and many programmers are switching to it for various reasons.
    • XML: Extensive Markup Language is broadly used for web development, but it is a necessary technology for Android development as well. In simple terms, XML is designed to provide the information exchange via the internet. So, if your app needs to be connected with the internet, developers have to use XML.
    • Android SDK. Android software development kit is a set of programs for various purposes. For instance, it has the integrated tools for debugging, code testing, checking the compatibility with different OS versions, etc.
    • Android Studio. It is an integrated development environment (IDE) developers use to write source code conveniently. This is possible due to a variety of built-in instruments (e.g. preview app for different OS versions).
    • APIs: The ability to work with third-party APIs and integrate them into software is another requirement for Android developers. For example, if you need in-app payments, developers can use Stripe API and adapt a ready-made code to the app’s needs instead of architecting the payment system from scratch.
    • Databases: Android developers should have skills of integrating cloud databases such as Firebase or local ones such as SQL for storing your app’s data.
    • Material Design. It is the Android design language and developers should be acknowledged with its guidelines to build the app’s user interface in the right way.

    Android Developer Rates

    The price for IT services is typically indicated for one working hour. The prices also heavily depend on a region.

    • North America: $150-170/h
    • Australia: $110/h
    • Western Europe: $70/h
    • Eastern Europe: $35-50/h

    Now you know what it takes to find a qualified Android developer!

    — Nataliia Kharchenko

  • Speed Rules in Chef’s DevOps Survey

    Speed Rules in Chef’s DevOps Survey

    DevOps is all about streamlining and accelerating. Organizations that embrace DevOps are driven by a focus on maximizing the combination of efficiency and effectiveness—which explains why speed is the central theme of Chef’s “The State of Enterprise Applications” survey.

    Chef surveyed nearly 350 application and operations professionals in an effort to understand trends in DevOps, identify how the industry is shifting and get an idea of what the future of DevOps looks like. What it found is that speed is one of the primary driving factors for organizations that function at the cutting edge of technology. Chef also found that organizations are eager to adopt new platforms that promise to help them move faster.

    The Need for Speed

    There are a variety of ways to measure success for application development and deployment. You can look at the features and capabilities of the app and whether it delivers the expected functionality, or you can determine success based on user feedback and how satisfied users are with the app experience. According to the Chef survey, 72 percent of organizations are focused on speed as the primary measure of a successful app deployment.

    That said, it generally takes weeks—or even months—to get an app developed and deployed. More than 60 percent of survey respondents shared that it takes days or more to complete an application build, and 55 percent indicated that it takes four or more builds before an app is ready to be deployed. Almost 60 percent said it takes days or more to actually deploy the app once the final build is approved.

    Platforms and Tools to Accelerate App Deployment

    In the quest for speed, organizations are moving to platforms and tools that can help accelerate development and decrease the time it takes to make an app available. According to data from “The State of Enterprise Applications” survey:

    • Only 9 percent of organizations are using public cloud for more than 50 percent of app deployments today, but that is expected to increase to 32 percent by 2020.
    • There is a 144 percent increase expected in the next two years in the number of organizations using container technology for more than 50 percent of app deployments—to 22 percent from 9 percent today.
    • The number of organizations using microservices for more than 50 percent of app deployments is expected to double—to 24 percent from 12 percent—in the next two years.
    • More than 80 percent of survey respondents are adopting a multi-cloud strategy.

    Putting App Deployment in High Gear

    Chef is in the business of automating and streamlining app development and deployment, so it should come as no surprise that the survey included questions related to that as well. The report states, “The most successful software-centric organizations use one consistent way of building, deploying, and managing applications.”

    More than 9 out of 10 (93 percent) of survey participants agreed that an application packaging solution that allows deployment to any environment would be valuable. This is especially true when developers have to deal with hybrid or multi-cloud environments.

    If speed is your primary measure of success for app deployment, you need to make sure you have the tools and processes necessary to develop and deploy applications as quickly as possible. Chef’s report shows organizations are well on their way.

    — Tony Bradley

  • How Artificial Intelligence, Machine Learning Can Help DevOps

    How Artificial Intelligence, Machine Learning Can Help DevOps

    Artificial intelligence (AI) and machine learning (ML) can help the humans in DevOps break free from focusing on simple activities. One aspect of DevOps is automating routine and repeatable actions, and AI and ML can perform these activities with enhanced efficiency to improve the performance of teams and business. There are algorithms that can perform many operations and procedures, allowing those in DevOps to execute their part effectively. This article discusses how DevOps engineers can use AI and ML to their benefit.

    Artificial Intelligence, Machine Learning Driving DevOps Evolution

    Businesses are under a lot of pressure to meet customers’ ever-changing demands, and many embrace DevOps to improve their performance to some extent. However, it can be difficult for many companies to use AI and ML because of the complexity involved. To recognize any benefit with AI and DevOps, a creative mindset may be required.

    The adoption curve of AI/ML may be relatively slow. Only 27 percent of CIOs surveyed by ServiceNow for its report, “The Global Point of View,” have hired employed who have skills in machine learning. But the fact is, DevOps experts may have a lot to gain by adopting even the most basic features of AI and ML. The same survey found that around 85 percent of C-level executives believe AI/ML can offer substantial value in terms of accuracy and rapidity of decision-making, which will lead to improved profitability for the company.

    Tracking and organization in a DevOps environment requires effort because of the complexity involved in the distributed application, which traditionally made things difficult for the team to manage and resolve customer issues. Before the evolution of AI and ML, DevOps team members could spend hundreds of hours and a large amount of resources to identify one point within an exabyte of information. To solve such problems, the future of DevOps is AI-driven, helping to manage the immense capacity of data and computation in day-to-day operations. AI has the potential to become the primary tool for assessing, computing and decision-making procedures in DevOps.

    AI’s Influence on DevOps

    AI can change how DevOps teams develop, deliver, deploy and organize applications to improve the performance and perform the business operations of DevOps. There are three common ways through which AI may influence DevOps:

    Enhanced Data Accessibility

    The lack of unregulated accessibility to data is a critical concern for DevOps teams, which AI can address by releasing data from its formal storage—necessary for big data implementations. AI can collect data from multiple sources and prepare it for reliable and robust evaluation.

    Greater Implementation Efficacy

    AI contributes to self-governed systems, which allows teams to transition from a rules-based human management system. This helps address the complexity of assessing human agents to improve efficacy.

    Effective Resources Use

    AI gives much required competence to automate routine and repeatable tasks, which minimizes the complexity of managing resources to some extent.

    How Can Companies Apply AI and ML to Optimize DevOps?

    Organizations can apply AI and ML to greatly optimize their DevOps environment. For one, AI can help in managing complex data pipelines and create models that can feed data into app the app development process. By 2020, it’s expected AI and ML will take the lead in digital transformation, overtaking IoT.

    However, implementing AI and ML for DevOps also presents a number of challenges for organizations of all sizes. To benefit from AI and ML technologies, a customized DevOps stack is required.

    Open source projects such as the Fabric for Deep Learning (FfDL) and Model Asset eXchange (MAX) can lower the barrier of entry for companies, helping to implement machine learning and making the DevOps process more efficient.

    Application of AI and ML can result in true ROI for a company by optimizing DevOps operations, making IT operations more responsive. They can improve efficiency as well as productivity of the team and play an important role in filling the gap between humans and big data.

    Conclusion

    A company that wants to automate the DevOps have to decide whether to buy or build a custom AI/ML layer. However, the first step is to establish a strong DevOps infrastructure. Once the foundation is created, AI/ML can be applied for increased efficiency. AI/ML can help DevOps teams focus on creativity and innovation by eliminating inefficiencies across the operational life cycle, enabling teams to manage the amount, speed and variability of data. This, in turn, can result in automated enhancement and an increase in DevOps team’s efficiency.

    — Subramonian

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

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

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

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

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

    Audio

    Transcript

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Shimel: It’s June 27.

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

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

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

    Shimel: Excellent.

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

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

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

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

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

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

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

    Beal: I am, indeed. Yes.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    — Alan Shimel

  • ChefConf 2018: Chef Grows Beyond Infrastructure to Apps

    ChefConf 2018: Chef Grows Beyond Infrastructure to Apps

    chefconf keynoteHere I am in Chicagoland for my third ChefConf. I caught the keynotes today with Nathan Harvey, Barry Crist, Adam Jacob, Corie Scobie and more. The big news at this year’s event is that Chef is focused on more than just infrastructure and compliance—Chef is bringing automation to apps and the entire software delivery life cycle.

    I spoke with Chef CEO Barry Crist about this and he said there is a sea change taking place with software is delivered. Chef has seen this wave coming and, over the last few years, has been retooling its offerings to match this. Today, Chef Automate and Chef Habitat represent the heart of Chef’s arsenal in its mission to offer the premier platform to automate the software development, deployment and security life cycle.

    I personally have seen this shift over the last few years. I think back to when we launched devopsy.kinsta.cloud. Chef was already a popular solution within the DevOps community; however, most people will tell you that they used Chef for configuration management. It was great to be able to make sure that as you spun up new instances in the cloud, your infrastructure was configured exactly as you wanted. By automating and using a Chef-type of solution, you could spin up new instances at-will and their configuration would be exactly the same or exactly as you desired.

    At the time, that was pretty cutting-edge. People were writing Chef recipes for all kinds of tasks—again, usually around configuring infrastructure.  With the advent of microservices, containers, Docker and Kubernetes, this type of automated deployment has become commonplace. But the need to automate, especially with security and compliance and app deployment, is perhaps an even bigger mission.

    Crist acknowledged these facts during his keynote. In speaking about Habitat, Crist noted that not only did many of Chef’s customers not understand the real story behind Habitat, but that half of Chef’s own employees didn’t, either. One person who did was Julian Dunn, director of product marketing, who I interviewed on DevOps Chats about Habitat when it first launched. Tony Bradley wrote that it could be a game changer back then, as well.

    Habitat has come a long way since then and still has a ways to go to grow into its ambitious potential, but it is very functional right now. Chef has several clients here at ChefConf talking about their Habitat deployments and plans. Chef now tags Habitat with Automate Any App Anywhere – Build, Deploy, Manage.

    Perhaps further along than Habitat, however, is Chef Automate. In fact, Chef Automate 2.0 was announced ChefConf, and it seems to be an almost complete rewrite of the program, as it is now built on Microsoft Go. Here is Chef’s take on Automate 2.0:

    Chef Automate has been rebuilt from the ground up to provide performance, scale and advanced analytics required by enterprises using DevOps at scale to meet the demands of post-digital transformation. Chef Automate now provides a single control plane for infrastructure and compliance automation to enable a closed-loop ‘detect, correct, automate’ process to make infrastructure effortless.

    New features include:

    • Enhanced operational visibility and debugging – New tools and visualizations, including a streaming event feed, trend graphs and a rich query language, help users analyze infrastructure and compliance automation data from a unified dashboard.
    • Compliance scanning and reporting in any environment – Integration with cloud compliance capabilities of InSpec 2 enhances scanning, which can now be used to evaluate cloud configurations (AWS, Azure, Google Cloud) via APIs for compliance on either an ad-hoc or ongoing basis. Chef Automate 2 also supports scanning of Cisco IOS equipment as a significant start on extending modern compliance capabilities to network devices.
    • Re-architected for speed and flexibility – A Go-based microservices architecture, with a modern, performant web UI atop a REST API, enables Automate 2 to support tens of thousands of nodes from a single installation. In-place upgrades with automatic data migration from Chef Automate 1 ensure that customers retain all historical information.

    Additionally, Chef has released something called Chef Workstation. From the release:

    Chef Workstation enables DevOps teams and practitioners to complete ad-hoc DevOps tasks using all of the familiar Chef capabilities, without agents. This provides a simple and effective way to use Chef to complete tasks and then seamlessly scale those tasks through Chef Automate.

    Capabilities include:

    • New standard desktop/laptop experience for Chef – Includes a new ‘target mode’ for executing Chef recipes or entire cookbooks remotely and Introduces ‘chef’ command as the single point of entry.
    • Foundation for a better workstation experience – Bundling all the tooling previously included in the ChefDK provides an improved user experience and cohesion between tools to deliver a seamless experience for any infrastructure automation task.

    Finally, new enhancements to Inspec, Chef’s compliance and security solution, were announced. Besides security and compliance being built into most everything Chef does, Inspec now sports:

    • Cloud configuration compliance – Verify AWS and Microsoft Azure policies, with Google Cloud Platform support in beta. More than 10 new AWS resources bring it to CIS Level 1 benchmark completeness.
    • Improved out-of-the-box experience – More than 30 new resources, including support for Cisco IOS network devices as agentless targets, are built in.
    • Drastically improved performance – Users now see up to 90 percent performance gains on Windows and 30 percent on Linux/Unix.

    I will report more as it comes here in Chicago and ChefConf 2018.

    — Alan Shimel

  • Dev vs. Ops Needs for Large-Scale Version Control Systems

    Dev vs. Ops Needs for Large-Scale Version Control Systems

    Distributed version control systems (DVCS) such as Git (introduced in 2005 by Linus Torvalds, the creator of Linux) rapidly gained worldwide acceptance by the global software development community. DVCS offer very fast, lightweight and local software change control capabilities that support many parallel code branches across large project code bases. These are compelling benefits for individual developers and development teams. At their heart, DVCS accomplish this by tracking software changes as a series of file system snapshots in local repositories instead of via management of individual file changes in a central database. “A Short History of Git” explains this in more detail.

    The DVCS approach is ideal for individuals and small agile teams because it puts control directly in their hands without the need to transact all file changes with burdensome systems that were designed using a central management paradigm.
    However, the distributed approach taken by DVCS has historically presented challenges for operations, especially when large-scale enterprise software systems consisting of components from many separate repositories need to be managed and controlled. Enterprises with many developers, large source or binary files (e.g. graphics, audio or video), many artifacts or many large containers need granular end-to-end version traceability. Enterprise-class support requirements exceed the original design intentions of DVCS.

    End-to-end software version management offerings that on one hand leverage efficiencies of distributed systems for developers yet still support scalable operations are required to address the needs of Dev and Ops communities in enterprises with large software version management needs. These complementary requirements have driven the evolution and best practices of large-scale hybrid version control systems:

    • Simplify builds and manage complex projects by organizing multiple repositories
    • Move code and build assets into the DevOps pipeline quickly
    • Improve performance for remote sites by using a central system as a proxy/cache
    • Speed up many activities at the system level, such as cloning and copying code
    • Implement a seamless workflow that incorporates assets such as large graphics and binaries, in addition to source code

    Related Content:

    35+ Tools Every DevOps Expert Must Know

    Automation: Achieving Faster Rollouts with Better Accuracy


    As stated, historically, these were problems that could only be addressed by a centralized version control offering. DVCS alone simply couldn’t handle the large-scale continuous integration (CI) and operations requirements of large-scale software development communities. While there are still inherent issues in the way DVCS manages large binary assets, select vendors have begun to tackle the problem by mirroring DVCS repos in real time, which marries the developers’ need for easy branching and local control with the operations team’s needs for faster and more efficient builds.

    For enterprises developing complex software incorporating both binary and text-based assets, large-scale enterprise hybrid version control systems with supporting both distributed and centralized structures offer a best practice solution. They provide capabilities for a global single source of truth, replication of all types of artifacts and manage versions of everything from planning to release. By resolving operational management problems resulting from sprawl of individual Git repositories, while at the same time preserving benefits of distributed systems, today’s enterprise-class centralized and/or hybrid version control systems can meet the needs of both Dev and Ops without sacrificing efficiency or operations control.

    Summary

    What do you think? Do you agree that the benefits of hybrid versions control systems listed above are important to achieving large-scale version control? Are there other solutions you recommend?

    — Marc Hornbeek

  • Barriers to DevOps Culture Change

    Barriers to DevOps Culture Change

    In the quest for DevOps, there are two paths organizations can take. One is to start with automation and attempt to get as much as possible out of automation tools. The other is to start with culture change and use tools to address what increased communications uncovers. Both scenarios are happening in the wild, and both have strengths and weaknesses, but there are themes across both approaches that are worth calling out.

    DevOps: Culture vs. Tools

    An extension of the above distinction is that some IT shops try to implement all changes with tools. After all, a large part of DevOps is the benefits that tools offer, so why not try to reap those benefits without changing the entire culture? This approach meets with limited success. Of course, things improve, since more automation means less room for human error. But there is a limit to how much improvement can be gained without the culture change that allows Ops to ask, “You are slating this project to use BobsEasyDatabase, but we only use the big three. Any chance we can retarget and save issues down the road?” Early and frequent communications can smooth over issues like this and allow a team to do a full-life cycle risk assessment of contentious choices.

    Do not let an aversion to culture change limit your DevOps initiatives. It can be difficult to change teams around such that management responsibility changes or is even blurred. But by increasing the authority of a cross-functional team to make the decisions needed to get reliable software out quickly, these issues can be mitigated. It will be an adjustment for many, including middle management, but it is a change that allows the full force of DevOps to improve software delivery.

    Silos vs. Culture

    In traditional IT, Development happened largely in a vacuum and Operations received the results. The place of security and infrastructure teams was generally with Operations, though they dealt a bit more with development than, say, the systems management team did. The problem was that Development often did what was best for development, with little visibility into how badly it impacted the other teams in the life cycle. The same was true of Operations, which would sometimes “just say no” to any request outside of normal operations without consideration of overall life cycle. And also for Security, which theoretically has veto power for strange implementations in more organizations. These attitudes have to change if DevOps’ strength is to be realized.

    Do not leave silos in place that reduce communications between teams. If possible, rebuild teams along application or application portfolio lines so that Dev, Ops, Security and Infrastructure are together discussing what is best for the application and the company. But if that is not possible, regular stand-up meetings to discuss contentious issues such as the security of a given library or inclusion of “Yet Another Database Management App” in a project. Barriers segment work in ways that make the lives of some easier at the expense of the overall project. Break them down as much as your organization will allow.

    Driving Home the Changes

    In the long run, the point of DevOps is to improve the product and the delivery reliability of the product. Making changes that forward these goals is paramount to success.

    Do not let inertia stop culture change. The DevOps Institute has a Certified DevOps Leader program that points out (among other things) how middle management can be the stumbling block in many DevOps implementations. We won’t give away too much of its training, but will say that the organization has good tools for dealing with the dilemma of telling middle management they must meet deadlines while the organizational structure is shifting under them.

    There always will be people who believe their role is so unique it does not belong as part of the DevOps process. To make DevOps successful at reducing time to market while simultaneously improving quality and agility, every part of the process must be visited. Quite often, the person whose job is so unique is the bottleneck in the process. If the decision is made to change culture, include everyone, even when it’s uncomfortable.

    — Don Macvittie

  • Understanding is Key to Achieving DevOps Culture

    Understanding is Key to Achieving DevOps Culture

    Historically speaking, IT has been composed of silos. This has worked out rather well over the last half century or so, as one team developed systems, another kept them running, another handled security and yet another managed the infrastructure. But it was never nirvana. Working well is not the same as cannot be improved.

    The Growth of DevOps

    Into this static hierarchy of work-performed silos came agile development. Agile addressed shortcomings in traditional development methodologies by breaking problems into smaller pieces and implementing those small pieces quickly. It allowed for a faster check on quality/completeness of those smaller pieces, and tracking the smaller pieces allowed for better prediction of timelines.

    Soon, automated testing was thrown into the mix with agile, so developers could receive faster feedback on their changes and address any issues turned up by automated testing while the chunk of code was fresh in their minds.

    This lead to teams building more and more of the build/test/deploy process into a system that became known as DevOps. As the change from Agile to DevOps occurred, it became more and more important for communications to happen between teams —Development, Ops and Test—not only to get automation into place, but also to keep things flowing smoothly.

    Which brings us to today. Today we have tools to automate just about the entire application life cycle. And while you were reading that sentence, a new tool was released.

    DevOps Culture Definition

    The problem with this plethora of tools is not that they’re useless—some of them are downright astounding in how they help us develop and deploy software faster, and some increase the quality of the code we are shipping while not increasing timelines. The problem is that in the old, siloed world, these tools are never enough—problems that occur often have Douglas Adams’s famous SEP (Somebody Else’s Problem) field wrapped around them.

    This is where DevOps culture comes in. Martin Fowler has a good discussion of culture on his blog, it’s worth a read if you haven’t seen it before. Whether an organization sets out to change its culture or sets out to automate with DevOps tools, a certain amount of culture change is going to happen. That is because lines get blurred relatively quickly if the focus is on turning out high-quality software at velocity.

    DevOps culture is teams working together to achieve the goal of delivery in ways that they would not have a decade ago. Communication is king, and is usually the start of culture change. Operations providing immediate feedback when development makes a dependency assumption might be a starting point, then Development starts including Operations in decisions to build in dependencies.

    Eventually, whether by design or need, teams become reorganized based on the application or application portfolio they are supporting, and the lines between Development and Operations blur into DevOps, where everyone on a team is working closely to achieve the goal of rapid development and deployment of software.

    Culture change can take the form of operational changes, wherein team members start to work more closely together in the absence of major restructuring with the goal of making software manufacturing and deployment better. Culture change also can be formalized, with reorgs of IT to put together teams that will manage an application for the entirety of its life cycle, and Dev/Ops/Security/Infrastructure members are all working together, not as worried about boundaries as in a traditional IT organization. Both are DevOps culture change, though most who specialize in DevOps think the first form is just the early stages, and the second is inevitable in a DevOps shop.

    The long goal of DevOps is to increase the rate of new feature development, reduce the rate of bugs and improve response time to serious issues. Culture change is the vehicle that drives these changes. Automation tools can do some, but increased collaboration means increased response rates to all of the above issues, and that’s where true improvements start to show. More advanced DevOps implementations include business unit owners in the feedback loop, giving them instant access to information about the state of the applications they are responsible for and allowing them to adjust as market conditions change. This is another increase in the mostly communications front that provides customers with more reactive/adaptive solutions.

    — Don Macvittie

  • 15 Things Your Competitors Know About DevOps

    15 Things Your Competitors Know About DevOps

    It’s no secret that DevOps is revolutionizing IT, helping organizations do more, faster. DevOps success is now essential for organizations in their quest to remain competitive. According to the “2015 State of DevOps Report” by Puppet, organizations utilizing DevOps deploy software 30 times more frequently and have lead times that are 200 times shorter. Plus, their failures are limited to 60 times while recovery is 168 times faster.

    Here are the 15 things your DevOps-enabled competitors know that you might not be aware of:

    Easier Code Evaluations

    Code evaluations have become easier than ever. Developers now can move on to tasks and get rid of frequent changes in the code. Successful enterprises quickly react to the changes within the system with ultimate results. This enables greater benefit for the end-user applications.

    Quality Software

    DevOps training is all about transforming the way businesses think about software.

    DevOps elements are meant to be employed in individual teams or projects. But, the real success of the organization lies in the support from the whole. Successful organizations change the way its IT operates, supports and leads the enterprise.

    Different Definition

    Successful DevOps adoption is different for different organizations. Whether it is continuous delivery, quality or speed, every enterprise defines DevOps differently. It depends on you how you define DevOps that meets your enterprise necessities in a clear and consistent tone. Focus more on the results than the methods.

    Continuous Delivery – Streamlining development and avoiding the hurdles to achieve efficient functionality.

    Release Speed – Effectively meeting the expectations of consumers.

    DevOps is Beyond IT

    DevOps has consistently evolved beyond the typical IT concept. It involves software, applications and tech-based services. It brings together the responsibilities of everyone in the company, and not just IT.

    This way the whole enterprise collaborates more closely on a defined DevOps platform. Complexities are effectively eliminated due to fewer barriers between IT Operations and Development teams.

    Transforming the IT Culture

    Transition to a DevOps operating model mainly depends on tools and principles. However, DevOps is all about changing the enterprise IT culture rather than just tools and processes.

    DevOps culture is all about removing the barriers and getting the whole team at one place, which further, improves the work efficiency. It is necessary that everyone—within and outside IT—must understand the importance and competitive advantages of a business to become more agile.

    Digital Transformation

    Digital Transformation is in high demand in recent years. Its foundation lies in applications that constantly create new channels that encourage customers and keep employees productive. DevOps is critical for the success of application strategy and forms an important element of digital transformation.

    Holistic Approach Toward Metrics

    Metrics are the parameters that guide any kind of organization. Your DevOps-enabled competitors are successful because they effectively measure the metrics and change them accordingly to improve growth in the industry.

    The right metrics make sure that DevOps transformation is working. Make a full-dimensional approach of metrics including:

    • Mean Time To Resolution (MTTR)
    • Mean Time Between Failure (MTBF)
    • Process and People Metrics
    • Active Users
    • Development-to-Deployment Lead Time

    Incorporating Automation

    Agility plays an important role in all processes of the DevOps operating model. To make the process more agile, it is essential to employ automation for repetitive tasks. This maintains the workflow of the whole process.

    Automation has expanded to all stages, including, development, testing, production and operation teams. The kinds of automation are:

    • Release Automation – Using tools such as Chef and Puppet.
    • Runbook Automation – Application performance management and monitoring solutions.
    • Automation achieves desired quality goals by maintaining compliance. It reduces costs and delivers a faster response.

    Feedback and Feedforward Cycles

    DevOps promotes agility through healthier integration within the organization. Feed forward and Feed backward in the development life cycle is critical in determining this agility.

    Different functions of the company interact smoothly only when tools lay their focus on software development process. This provides information on the content that is relevant to each audience. Context relevance enables easy creation of dashboards and present this information to the audience in a way which makes sense.

    Real-time Approach to APM

    DevOps is more about culture than just tools. Right tools and right actions highly improve odds of success and evade negative impact.

    Solutions you choose must provide visibility into future problems. Software development and implementation must be maintained in a volatile, fast-paced environment that requires production-ready APM solutions. Your competitors are highly efficient because they are aware of the trick: monitoring applications down to specific functions. Working together ensures quality and makes it easy to predict the success of applications.

    Application Analytics Improve Software Strategy

    Analytics plays an important role in improving software strategy. Utilizing analytics solutions prior to quality user expectations achieve competency.

    Software is not all about just software; it is about how it connects with customers to generate revenue. Ideal analytics are capable of connecting application performance with user management and business data. Be sure to define the vision and establish organizational priorities within the budget.

    Customer-centric and Innovation Cocused

    DevOps improves the communication between developers and IT Operations by building customer experience. DevOps provide value under pressure to the enterprises. Having DevOps within an organization is a definite necessity. It always upholds the competitive advantage and effectively delivers the software to the customers.

    Study Case Studies

    If you are the one aiming to make bigger by employing DevOps in your organization, read case studies and real-world examples. This effectively manages the DevOps transition for any size of the enterprise.

    Macro Environment

    Budget, roles and responsibilities and departments have a come a long way. Product releases have been reduced from annually to quarterly, monthly, weekly, daily and now to several times a day. Microbuilds, microreleases, microupdates, microtesting and microcheck-ins have now become an easy task.

    Welcome Ops Movement

    Don’t stop with the existing movements. Go and explore the Ops and its related tools: viz. DevOps, DevSecOps, BizOps, etc.

    Final Thoughts…

    It is clearly evident that investing in DevOps culture is pure benefit. DevOps is here to transform the way organizations develop, monitor and handle the applications and its underlying infrastructure. It has readily progressed from a niche concept to a business imperative. Every enterprise, small and large, aspires to integrate DevOps tools and principles. Employ the above points to successfully drive the DevOps conversation within your enterprise.

    About the Author / Sirisha Paladhi

    Sirisha Paladhi is a content writer at Mindmajix. During her career, she has written many articles on technology innovations. Connect with her on LinkedIn.