devopsy.kinsta.cloud

Tag: devops solutions

  • Cloud and DevOps: CI/CD and Market Analysis

    Cloud and DevOps: CI/CD and Market Analysis

    Companies today are under heavy pressure to deliver software faster and with more quality than their competitors. A set of good features and their reach to customers can increase only when the company releases software updates frequently. As a result, organizations are embracing DevOps and CI/CD approaches to improve their ability to plan, build, test and release applications and features to market quickly with quality and at scale. IDC predicts the worldwide DevOps software market will reach $8 billion by 2022, up from $3.9 billion in 2017. 

    The buzz around continuous integration, continuous deployment and continuous delivery is more than ever today, but in practice, the actual usage of CI/CD seems to be less. It can be because of the shortage of skill set required in DevOps or companies still practicing traditional software development methodologies. Enterprises are not understanding the amount of money they are leaving on the table by missing CI/CD and DevOps automation practices. 

    For many companies, DevOps is something they have to try because their competition is doing so or because it is a trend. This is a desperate attempt without understanding the consequences and basic understanding of DevOps principles. 

    For the most part, it is a disparate set of tools that customers have to connect together for their software delivery that creates chaos around. On the other hand, it is difficult to choose the right tools and understand what are the best practices. That’s why we are starting to see a trend of DevOps companies delivering a unified toolset so that customers have a complete solution out of the box ⁠—without having to worry about finding many different solutions from different vendors.  

    What Is CI/CD?

    Whenever a developer commits and pushes changes to the repository, the CI system will rebuild the branch and run all related test cases to verify that new changes won’t break the existing application and functionalities. 

    Continuous delivery is an extension of continuous integration that helps you deploy your application with a click of a button. It means deploying changes every time they pass CI tests. With this, you can easily automate your build and testing phase and most of your release process as well.

    With continuous deployment, developers will be able to release or deploy software automatically into the production environment. In this stage, no manual code check-ins happen into the app. Code is automatically tested through the CI process for issues, and if none are found, then the code is deployed.

    Why CI/CD?

    CI/CD serves as the best practice for testing and deployment of applications. For the purpose of quality assurance, making CI/CD the single channel to deploy code is the best practice. DevOps teams should ensure that everything is going through the CI/CD pipeline so that the code in testing and production are the same. This will also reduce human error and avoid deploying other versions not being tested by mistake.

    One of the biggest reasons for companies to practice CI/CD today is faster software delivery, which leads to more frequent updates to customers. It makes them feel happy and a constant improvement with frequent releases will ensure enhanced customer satisfaction. This is a competitive advantage because it allows companies to deliver new features more often. It can help companies stay ahead of competitors.

    Passing code through the CI/CD pipeline ensures that any changes made adhere to the established standards before moving to the next stage in the delivery pipeline. Any failure or discrepancy prevents the advancement of such changes to the next step until it is rectified. This simply means this approach of CI/CD ensures that bad code does not get into the production. CI/CD promotes the fail fast, learn fast and deliver fast approach. When you have automated CI/CD in place, the code is run through the CI/CD process constantly with each commit by developers which allows bugs to be caught quickly ⁠— it is easier to isolate the bug since each small change is tested separately. 

    What Is the CI/CD Pipeline?

    A CI/CD pipeline is a deployment pipeline workflow that is integrated with automation. When conducted well, it will minimize manual handoffs and errors to enhance the feedback loops throughout the software delivery life cycle, allowing development teams to deliver smaller chunks of releases within a shorter time.

    The CI/CD pipeline is now mainstream among software companies, and it has become the backbone of the modern DevOps environment. While DevOps lays principles and standards related to the culture aspect, CI/CD focuses on the automation, flow, process and tools. CI/CD scenario has changed with the introduction of containerization and microservices. Now, every cloud vendor has support and integration with tools such as Docker and Kubernetes that help the CI/CD pipeline to scale. 

    Stages of the Continuous Delivery Pipeline

    • Test Automation and CI: This is the important stage where the new features and prototypes are prepared, coding is done and then the code is integrated with the base. With the use of a CI server, the unit tests and packaging is done.
    • Build Automation: This is the stage where the artifacts are pushed by developers (i.e., Dependencies, Docker image) to the registry (i.e., Amazon ECR or Docker hub or any container registry).
    • Alpha Deployments: In this stage, developer checks-in changes. It is the place for developers to carefully see the changes they’ve made and how they interact with each other and affect other systems. Also, here developers can be able to see if they broke anything in the master branch.
    • Beta Deployments: This is the stage where testers carry out manual testing. Manual testing is still required to see the perfection of CI tools. This gives the DevOps team the guarantee that the condition of the application is good and will work definitely as desired when deployed.
    • Production Deployments: Here comes the final stage, where the app goes live.

    What Is the Market Saying About CI/CD? 

    • The search volume has gradually increased in the world for the keyword “CI CD Pipeline” on Google.
    • When Mabl, a test automation company surveyed 500 software testers, 53% of the people said their team uses continuous integration, while 38% embrace continuous delivery and only 29% have adopted continuous deployment. 
    • A DevOps related survey from Codefresh showed that a third of companies had automated more than half of their workloads, but only 1% were all the way there. Almost no one has automated the entire CI/CD process. A plurality of engineering teams have automated less than 10% of the process.
    • The iOS Developer Community Survey is the largest survey of Apple platform developers ever undertaken, where 2,290 people filled in the questionnaire in which CI/CD questions were also a part of the survey. 

    Below are the results that showed a majority of developers are practicing CI/CD when it comes to business apps. 

    Figure 1: Do you practice continuous delivery for your personal/hobby apps?
    Figure 2: Do you practice continuous delivery for your business’s apps?
    • The way forward: Companies will not be able to fully take advantage of containers and DevOps unless they embrace the use of a proper deployment pipeline. Companies will start offering pre-built pipelines to customers, something like JFrog pipelines. There is a need for a unified platform that has all the tools needed to support a CI/CD system ⁠— automation (Pipelines), binary repository management (Artifactory), security (Xray), release/deployment (Distribution), etc. JFrog provides a unified platform.
    • Codefresh conducted a survey and published the results of the survey of 130 developers at the KubeCon + CloudNativeCon Europe 2019 conference ⁠— and the results were a bit shocking. It showed that nearly a third (32%) don’t use any continuous integration or continuous delivery (CI/CD) platform at all. Sixty percent of the survey respondents said their organization has yet to take full advantage of automation to accelerate software development and deployment.
    • The Market Radar Report by GigaOm is a recent research on the enterprise CI/CD solutions where the author compares the leading CI/CD solutions in the industry and rates them depending on different valuation criteria. According to the results, JFrog, Codefresh and GitLab are outperformers as shown below.
    Figure 3: GigaOm Radar for CI/CD. Source: GigaOm.

    The CI/CD solutions considered were AWS, CircleCI, CloudBees, CodeFresh, GitLab, IBM, JFrog, Micro Focus, Microsoft, Red Hat and Xebia Labs. You can download the free analyst comparison report here: GigaOm Radar For Enterprise CI/CD.

    CI/CD is one of the DevOps best practices because it ensures proper alignment between developers and operations. While it enhances automation, developers can push code changes more reliably and frequently. At the same time, the operations team can see greater stability because environments have standard configurations, and rollback procedures are automated. To win the CI/CD game, both dev and ops teams need to develop consensus on the right tools and approaches that are beneficial for the business growth in the long run. 

    Cloud and DevOps Go Hand in Hand

    You can’t do DevOps without the cloud. DevOps won’t have much value without it, and the cloud won’t do much without DevOps. 

    Cloud computing has many definitions, the fundamental explanation of the cloud can be defined as a system that enables and supports the provisioning of infrastructure. Thus, it allows it to be described as code or templates, facilitating the creation of repeatable processes. That is also the basic principle of DevOps, automating the processes/tasks in the software development life cycle to the fullest extent.

    One of the biggest benefits of cloud for CI/CD is the dynamic nature of cloud infrastructure. This is perfect for the ephemeral and bursty nature of CI/CD workloads. Cloud resources can automatically scale up and down based on CI/CD workloads. This allows huge management and cost benefits for enterprises. Enterprise companies don’t need to have their own servers to maintain, they need to increase these servers as CI/CD workloads increase or waste server resources when they are idle.

    Regardless of how your organization defines the cloud technologies and, despite which DevOps routes you travel to achieve digital transformation with the cloud integration, the aesthetics of cloud technologies and services can be easily amalgamated in the DevOps dictionary because they radically complement DevOps principles and processes. 

    For DevOps implementation, Agile principles serve as a driver, as there are shorter release cycles and automation to deliver fast and achieve the deadlines. To implement continuous practices, cloud computing is a great facilitator, since resources are available quickly for all the activities involved in development and application lifecycle management. Agile principles, along with cloud computing and DevOps practices, enable high developer productivity and faster growth in organizations.

    With secured cloud gateways, users get the ability to access enterprise resources easily from anywhere and with any device, without compromising on the security of the network. Letting users access your network from their devices might sometimes seem scary, but the modern cloud platforms have much more to offer, they come with built-in security stacks to help provide administrators with the tools they need to manage and support security.

    DevOps coupled with cloud tech has enormous benefits for businesses employing them:

    1. Increased developer productivity and collaboration.
    2. Faster time to market through quick and easy access to development environments.
    3. Help to automate different repetitive tasks so that developers can focus on the tasks that matter.
    4. Cloud complexity and system maintenance can be incredibly reduced by automation and infrastructure as code approaches.
    5. Increase security with modern cloud platforms and principles that serve to eliminate the manual error.
    6. Help to eliminate downtime through cloud-based continuous business operations. Developers can build stateless applications with automation, which will increase the availability and failover ability, along with increasing business reliability and improved customer satisfaction.
    7. Scale to new heights — one of the main reasons businesses employ cloud and DevOps is to scale their infrastructure and applications as and when needed. 

    Cloud Deployment Models

    When the cloud provider entirely hosts organization’s applications and data, it is a public cloud. With just having an internet connection, the employees of the company employing public cloud can access the applications. 

    A private cloud is when the resources of an organization such as storage, compute and networking resources exist in a provider’s data center. Companies prefer private cloud mainly because of security and for storing highly sensitive data when it comes to running applications. 

    One more modern approach is the hybrid cloud; it is a combination of private and public cloud services. According to the traffic and demand considerations, organizations can make the change. Some customers may have on-prem CI/CD systems. Some of these CI/CD systems can expand their workloads to the cloud in a hybrid setup. This can allow them to realize the benefits of cloud now and not have to do a complete migration.

    Mainly, when there is high demand, workloads can be run in the public cloud, and then when things get back to normal, return to the private cloud. This approach reduces the overhead cost spent on cloud resources. Additionally, the key point is, sensitive information, data and critical applications can be kept in the private cloud. In contrast, less-sensitive data and applications can be stored and run in the public cloud.

    Choosing DevOps Cloud Solutions

    If cloud is like an instrument, then DevOps is the musician who plays it.

    Cloud computing and DevOps play a vital role and are interlocking parts of the IT strategy. Together, cloud and DevOps help IT shift its emphasis from “How far and long can we go without an outage?” to “How often we can deliver new and stable functionality/feature?” or “How fast/quickly can we deploy a new service?”

    Businesses today are looking for ways to digital transformation with the help of the cloud, DevOps and automation practices. Considering the competition in the cloud space, it is overwhelming to see so many vendors and get confused on what to choose. 

    Here, in the State of DevOps Cloud Solutions 2020, you can see a high-level overview of the cloud DevOps platform solutions available today, and what you should expect from vendors in your cloud DevOps journey.

  • The Battle for End-to-End DevOps Champion Is On

    The Battle for End-to-End DevOps Champion Is On

    This past week’s CollabNet/Xebia Labs merger brings another challenger to the “end-to-end” DevOps market. There is a huge prize waiting for the winner. But which of the challengers has the right stuff to win this battle? Will any of the current pack even be around at the end of the day? Who will be the winners and losers? What will it take to win?

    The eventual dominant player in the end-t0-end DevOps provider market will be rewarded with what should be a great pot of gold. It is this promise of hegemony over DevOps and the rewards it commands that have so many chasing the prize.  CloudBees, JFrog and GitLab are some of the DevOps darlings in this market. Chef has a similar game plan, and now the new entity stemming from the CollabNet/Xebia Labs deal will also be a player. I believe GitHub/Microsoft will make a play in this market, too.

    At this point in time, who knows which company will be triumphant and which will be regulated to the trash heap of also-rans? One thing I learned from my friend Brad Feld is that if you are not in the top three in your category, get out. In the end-to-end DevOps or complete DevOps market, there will be some winners and there will be some losers.

    Sanjeev Sharma, principal analyst for ASG, had this to say about the market:
    As engineers strive to streamline their application delivery pipelines to be able to achieve true continuous delivery, a massive stumbling block becomes an end-to-end delivery pipeline with tools that are seamlessly integrated. At one end of this spectrum we have organizations that acquire best-of-breed tools and glue them together themselves, owning the resulting plumbing. At the other end there are organizations that want tools from a single vendor that ‘just work,’ integrated out of the box. The pendulum today has swung toward the single vendor, integrated out-of-the-box side. The growth of platform vendors like GitLab and the consolidation of CI/CD tool vendors with larger ones is the result of this swing.

    Right now, while several contenders have a great vision, none of them really have a bonafide end-to-end platform or suite with functionality all the way across. There are also other contenders that I have not mentioned, but here is my take on what is out there that I see:

                1. GitLab – The company recently won our DevOps Dozen DevOps solution provider of the year and it was well-deserved. Sid Sijbrandij and team have done a great job laying out a bold, ambitious vision of GitLab’s eventual full functionality. On top of this, they add almost 200 new features a month, every month. The company is growing by leaps and bounds, with almost 1,200 employees, and has raised hundreds of millions of dollars with a valuation of $2.75 billion. GitLab has the resources to go deep in this market and has built some tremendous momentum. On the other hand, the fact is today GitLab customers primarily use the Git repo functionality and the CI module. The other modules are still being built out to be market-competitive, including some good work in security. I suspect it may take a few acquisitions to give the company market-competitive solutions in some of the other areas it is building out. At the end of the day, you have to make GitLab a clear favorite to be one of the survivors/winners, especially with such a high valuation.
                2. CloudBees – The Jenkins train has pulled CloudBees to the top of the mountain, but to succeed in this race, the company is going to need more than that to stay there. Jenkins is a bit long in the tooth and Kubernetes has been a game-changer. Jenkins itself has been turned over to the Continuous Delivery Foundation (Linux Foundation) as has JenkinsX, which works very well in K8s environments. But CloudBees has shown it is more than Jenkins and made some key acquisitions including Electric Cloud, which have given the company great enterprise customers and added to its talent pool. Other, smaller acquisitions have given CloudBees some fresh new functionality such as feature flags, for instance, which are upgrading and refreshing the mix. At the end of the day, though, CloudBees’ potential in this market is based on its ability to execute on its vision of a dual-product lineup that features both software delivery management (SDM), which they have already announced, and upgrading their existing software, which helps people with their CI/CD pipelines. Having both working together could give CloudBees an unbeatable place in the market. This vision may not be as ambitious or broad as GitLab’s but could be more attainable, more quickly.
                3. JFrog – Shlomi Ben Haim and his “Frogs” have built a DevOps powerhouse by understanding developers’ needs and wants and using open source as a market-penetration weapon as well as or better than anyone else. The company’s community/customers are fanatical in their support and the “change the world with liquid software” culture it has built is contagious.
                  When you consider JFrog started with a repository for artifacts and what it built on top of it is pretty amazing. The company continues to add new repositories for many of the popular languages in use as well. The downside for JFrog is that it just added its JFrog pipelines via acquisition and is still working to make it a best-in-class solution. XRay is JFrog’s security product for testing artifacts and code prior to deployment, and I think it will probably make another acquisition to bolster its security chops. The Frogs have the energy and will to win this thing, but they have a lot of work ahead of them to compete with an end-to-end or complete DevOps vision. Rumor is a new version of the platform is on the way; we will have to see what this brings. The company may wind up being bought for billions by a larger player (GCP, Microsoft), which could make JFrog a winner in any event.
                4. GitHub – GitHub is just a repository, you say? Nonsense. Make no mistake about it, GitHub is going to be a player in this race. With the deep pockets and ambition to continue being a developer powerhouse at Microsoft, the company is determined to make sure GitHub is a complete DevOps solution. GitHub is adding functionality every day and has an amazing array of tools that plug into and extend GitHub. As the de facto standard—with something like 30 million developer accounts already and Microsoft’s Azure and war chest—don’t bet against GitHub being the last man or company standing here.
                5. CollabNet VersionOne/Xebia Labs entity. So, this is the new kid on the block—so new that we don’t even know its name yet. This merger was orchestrated by the private equity group TPG, which bought CollabNet last year and pledged $500 million to use to acquire and grow the CollabNet business into a complete DevOps platform. That $500 million probably represented a lot more than the firm paid for CollabNet, which was a 15 years-or-so-old company that had some good tools in the agile market. Since its merger with VersionOne, it has released a value stream management solution (it may not have been called that, but that’s what it is) and tried to market the whole thing as a suite. Obviously there was not a smooth path between the companies and some parts were missing; the street had the TPG transaction at less than $100 million. Some of its holes are getting filled with the Xebia Labs merger/acquisition. Rumor on the street was that TPG paid something like $226 million for Xebia—not a petty amount, but remember, Xebia raised about $100 million a while back. Again, the rumor is that a good chunk of that money was used to “buy” Xebia out of its ownership by the Dutch Xebia group. After paying that off, the current Xebia ownership used the remaining funds to try and keep Xebia competitive. You can do the math from there. In recent times we haven’t heard a lot from Xebia. It was assumed the company would either raise more money or look for a merger to gain enough girth to compete in this newly energized complete DevOps market. This deal seems to fit the bill.A real plus for this new entity is the addition of Ashok Reddy as CEO. Reddy is a seasoned player with large public company executive experience in the DevOps space, as well as GM of enterprise divisions. However, it is going to take more money and more functionality to create a market competitive entity in this space. There has to be a security module, for instance. The issue is with the inflated prices that companies in this space are garnering—what can be bought with the dollars left or what can be built holistically? Will TPG perhaps put more money on the table?  It’s too early to count this new player out, but as the new kid on the block, it has to play catchup against some of the other players.

    These are just five of the players. As I mentioned, Chef, one of the original DevOps darlings, also wants to play in the complete DevOps space. There are others lined up behind Chef, but we have to end this article somewhere. It is going to be an interesting few months as we see the winners in this space emerge.

    In the meantime, if you like this kind of analysis—no-holds-barred, tell it like it is, open and free—check out Accelerated Strategies Group at https://accelst.com. ASG is the new analyst firm MediaOps is working with, and it is doing to analysis what open source is doing to software. Knowledge wants to be free.

    — Alan Shimel

  • 6 Common Causes of Conflict DevOps Sets Out to Solve

    6 Common Causes of Conflict DevOps Sets Out to Solve

    It’s a very exciting time to work in Information Technology – as John Willis* put it:

    “DevOps finally proves how IT can be a strategic advantage that allows a business to beat the pants off the competition. This is the moment we’ve all been waiting for.”

    I work with organizations that are palpably excited that the software and applications they are creating deliver groundbreaking, mission-critical capabilities to their end users and plan to outsource all their ‘generic’ IT – the services that don’t offer anything unique to their customers’ experience. The challenge though, is that these organizations have a lot of habits and history to deal with; while the business puts pressure on IT to develop and deliver more innovation faster, the increasing criticality of these applications and the evolved complexity and fragility of the systems they run on results in lots of risk and lots of pain when things don’t go according to plan. Here’s how we see this often playing out in today’s enterprise IT marketplace.

    Herewith, 6 of the most common causes of conflict DevOps sets out to solve that we hear when we’re talking to our customers:

    1. I need a server… now

    This is without a doubt the most common complaint we hear: that operations teams, or those responsible for making infrastructure available to development are blockers, too slow and don’t understand the needs of the business. What we see actually happening is demands for immediate drops of physical and virtual servers from teams who not only have literally just heard of this requirement coming down the line but have a pretty full on schedule of planned work too. Oh, and more than likely unexpected system failures and defects are generating a fair amount of unplanned work too having a direct knock on effect to their ability to respond to these demands and their planned work.

    Recommendations:

    • Culturally something has to happen to ensure everyone knows that they are on the same team and it feels like it. Try involving operations in the development cycles earlier so they have visibility of what’s coming down the line and are bought into the overall goals of the project
    • Make it easier to deliver new infrastructure by automating it, creating or using cloud and virtualization infrastructure
    • Aim for an on demand deployment capability
    • Analyze your teams’ planned/unplanned work proportions and try and figure out ways to eliminate the problems that distract from the goals trying to be achieved – this might be better testing or better monitoring of outages

    2. I want access to the production systems

    This one usually comes about after the developers have reached a tipping point in their frustration in not getting their needs/demands met in what they would consider a timely fashion. Sometimes it indicates that an organisation doesn’t appreciate or hasn’t implemented workable controls in the operations teams. DevOps doesn’t mean throwing all process out of the window and putting live environments at risk – it’s by no means mutually exclusive with methodologies like ITIL but it is about individuals collaborating better to achieve a shared desired outcome.

    Recommendations:

    • Read this article: “DevOps Does Not Equal Developers Managing Production”(link)
    • Involve development in the definition of your change control processes and set up of any systems
    • Set some Service Level Agreements as a team

    3. Something is wrong…whose fault is it?

    One thing DevOps is very clear it’s not about is blame. The “S” in CAMS* is for “Sharing” – that’s sharing ideas, goals, workloads and responsibility – it’s about being innovative, taking calculated risks, protecting against failure and BEING NICE. That means no finger-pointing and no swearing at each other.

    Recommendations:

    • Watch this video from AppDynamics: “The Real DevOps of Silicon Valley”
    • Read more about running a good, healthy retrospective – and practice it. Here’s an example from the UK Government Service Design Manual
    • Consider implementing tooling that will enable you to pre-empt failure or fail smartly. And that will help you identify the root cause fast

    4. So many alerts they are meaningless

    We spend a good proportion of our time working with companies to implement systems for smart failure or that can pre-empt failure as mentioned above. This is one third of our devops utopia triumvirate. The kind of systems that can deliver this capability are the new breed of Application Performance Management solutions like appdynamics. One of the challenges we often find though is that enterprises already have monitoring systems. Lots of them. Monitoring lots of different things. All producing a multitude of alerts. This is when we see alert fatigue. This is not something I believe is, or have indeed witnessed to be, relevant only to the healthcare industry. When someone receives a lot of alerts, of which a very large proportion are meaningless, it becomes highly likely that the critical ones are missed.

    Recommendations:

    • Review and consolidate your existing systems
    • Take some time to really understand what alerts matter and adjust your policies according – and consider this an ongoing task to tweak your systems as your situations change
    • Some DevOps proponents recommend alerting development on system outage immediately – I think this could work, if development are bought into the process and not thinking they are simply being blamed (see 4 above) – sharing the load is definitely a good idea, as long as the process makes overall responsibility clear and forces resolution

    5. I don’t have time to save time

    We hear this one a lot, particularly when we start to talk about business cases for automation tools. The two things driving DevOps (1: the increased rate of innovation and 2: the fragility of today’s evolution of IT infrastructure) together result in very high workloads and a LOT of unplanned work. Throw a recession and budgets that have been squeezed hard year on year on year and what you get is a lot of late nights and a lot of missed targets. DevOps is designed to streamline the throughput of work at a cultural, interaction and application based level – diffusing the pressure building up in many IT departments today.

    Recommendations:

    • Consider ringfencing some budget so invite in an external consultancy to perform an audit or assessment of your current DevOps state – you may feel they won’t tell you anything you don’t already know, but you will have someone documenting your position for you and giving you justification to take the next step in your transformation
    •  Make time – find a senior decision maker who will listen and mandate a project where you can prove something – for example the savings made by automating a piece of a process

    6. Our hero is a bottleneck…

    This one is particularly common when we are talking about release and deployment automation. And if you’ve read “The Phoenix Project” * you’ll recognize Brent as being one of these. What tends to happen is this: one day an engineer decides that building servers is a tedious, manual process and that they could write a quick script to make that bit a bit quicker. The next day, they write another one. And another one. Until, over a period of months or even years a whole bunch of scripts have been written automating lots of parts of the process – I like to call this a ‘script monster’. The problem is that even though the script monster works pretty well most of the time, when it fails it’s virtually impossible for anyone other than its creator to troubleshoot. So when there’s an outage at 3am, you have to call ‘Brent/the creator/Frankenstein’ and he breezes in and saves the day. But what if he isn’t there one day?

    Recommendations:

    • Create an environment embracing autonomy, mastery and purpose – where ideas are heard and acted upon. Often these ‘script monsters’ wouldn’t have been born if Frankenstein had felt he had alternatives to explore
    • Understand motivations: yours and your colleagues’. Some people are particularly motivated by certainty at work and if they have made themselves indispensable by creating something like a script monster, they may feel threatened if someone proposes to take it away from them
    • These heroes are often genuinely some of the most talented members of the team, so if they are resistant to change, talk to them about exciting new projects they can be involved with – make them the master of a shiny new system that will multiply the frequency of releases ten – one-hundred fold by allowing others to push them through an automated process – deployment on demand

    In Summary

    DevOps isn’t voodoo, a silver bullet or automatic. But it is a drive to encourage a different, positive and innovative way of thinking to address a common set of issues affecting the experience of living in, working with and using IT in the world we live in today. Be DevOpstastic.

    What other causes of conflict have you experienced that DevOps can resolve?