devopsy.kinsta.cloud

Tag: devops myths

  • DevOps Myths Debunked

    DevOps Myths Debunked

    Leaders need not be DevOps experts, but they need to distinguish DevOps myths and realities to lead their digital transformation projects.

    As I indicated in a recent article, Engineering Practices Can Overcome DevOps Challenges, leaders need to set an inspiring DevOps directional vision for the organization, and proactively stimulate and sponsor team activities toward goals. To be credible, communication from leaders need to distinguish between myth and reality. It is easy for leaders to get confused, because there are many popular myths surrounding DevOps. It’s important to remember that, in DevOps, definitions and engineering best practices for DevOps have not entirely been nailed down.

    As Doug Miller, senior director strategic partnerships, Perforce Software, said “Working in an industry that has yet to settle on an accepted ‘definition’ for DevOps makes each day a challenge. The ever-morphing landscape makes it difficult for technology vendors and consumers alike to ensure we’re all talking about the same thing in the same way.”

    Here are some of the most important myths that leaders need to be aware of.

    Debunking DevOps Myths

    Myth: “DevOps is a cultural movement.”

    The truth is that implementing DevOps requires a careful and balanced engineering approach that considers a wide array of people, process and technology aspects. In my article, The Time Has Come for an Engineering Approach to DevOps, I explained that while culture is a critical success factor, DevOps is much more than just culture. Furthermore, DevOps is not just a movement. In the larger context of software engineering history, the word “DevOps” is new, and perhaps it will be replaced by another word someday, but the underlying engineering principles and practices that constitute DevOps could apply to almost any engineering project throughout the ages.

    Myth: “DevOps requires continuous deployments.”

    The truth is that DevOps enables continuous delivery of release artifacts to a staging environment to be ready to deploy safely, but frequent deployments to production is not always a goal. There are valid customer use cases that do not desire frequent deployments to production. For example, customers may not want to receive a new version of a software platform product frequently, because each new version may be disruptive and risky for reasons beyond the scope of the product itself. The engineering benefits of delivering complete releases to staging without deployment to production are still considerable. Each release is produced and validated in a pre-production environment, and made ready for deployment on demand without disrupting customers that do not want to take a new release.

    Myth: “DevOps applies to any software product, service or application.”

    The truth is that DevOps engineering yields high ROI in many circumstances, but some cases do not warrant investment in the people, process, and technology changes needed for DevOps. For example, applications that rarely change do not warrant the cost of DevOps changes. Organizations that are heavily siloed will find it too frustrating and counterproductive to implement DevOps. The application of DevOps to some commercial off-the-shelf (COTS) products may not yield sufficient ROI, because business-to-business barriers may behave as impenetrable organizational silos. Applications that have few tools in their toolchains suitable for DevOps may find the transition to DevOps too expensive.

    Myth: “DevOps requires Agile.”

    The truth is that DevOps and Agile can be either complementary or competitive. The notions of working with small, incremental changes is common to both Agile and DevOps. However, organizations that embrace Agile are focused on optimization of the development end of the pipeline, and may struggle with DevOps, which emphasizes engineering of end-to-end process optimizations.

    Myth: “The scope of DevOps is the same as CI/CD.”

    The truth is that a well-engineered DevOps implementation encompasses continuous integration/continuous delivery (CI/CD), but also extend beyond integration and delivery into other practice areas such as planning, operations, governance, disaster recovery and other practices that must work together with CI/CD to accomplish business goals.

    Myth: “DevOps does not apply to platform products such as software code embedded in manufactured products.”

    The truth is that DevOps does apply to embedded code products, as well as web services, business applications and other types of products. It even applies to development of software and services for DevOps itself! In the case of platform products, typically, deployments are planned. They are not continuous, but, instead, continuous deliveries of candidate releases are delivered to a staging environment to make sure the changes implemented for the platform are fully developed and verified as the platform is built, instead of waiting for a big-bang release.

    Myth: “DevOps is an elimination of IT operations.”

    Jeremy Bosch, in his article, Top 9 Debunked DevOps Myths, “As per the NoOps concept, the IT sector will become so automated that it will not require any in-house team to manage the software. However, no matter how automated the services may become, there will always be a need for operations. Although there may be changes in operations, they will still hold significance in DevOps.”

    There are many persistent myths about DevOps, such as the examples in this article, that can confuse and misdirect uninformed leaders. Leaders that learn to distinguish between DevOps myths and realities are better able to communicate realistic goals to lead their digital transformation projects.

  • 5 Myths About Software Development

    5 Myths About Software Development

    2020 has broken many rules about software development. Some perceived trends, however, remain myths

    Some trends come and go, some trends stick. I remember when Docker launched and it was barely mature enough to run unit tests, and now containers are a common way for modern orgs to deploy applications. We’ve seen the rise of microservices but also the return to the monolith. We’ve seen “observability” take off in popularity, while serverless remains a buzzword with limited (but fast-growing!) adoption. Machine learning and artificial intelligence are still click-worthy headlines, but how much actual ML is being used within our applications?

    The True State of Software Development

    Let’s look at five common myths about the current state of software development and evaluate why they’re not completely true:

    Digital Transformation Initiatives Will Be Hindered by the Pandemic

    We live in an online world where every business is already a software business (or rapidly becoming one). The impact of the pandemic further highlighted ISG’s research which stated that “2020 will still see the rapid scaling of digital initiatives across industries.” While some industries have been hit so hard that digital projects had no choice but to stop (e.g. the airline industry), in many circumstances this will be the catalyst to fully embrace digital transformation.

    The Waterfall Method Still Works

    Organizations that haven’t adopted more agile and iterative approaches to building software are operating at a significant disadvantage. I know there are many big companies that still believe in doing all of the strategic planning upfront (I know this because I talk to these companies), but the truth is that it leaves very little room for flexibility and improvement in real-time. In today’s world, the customers and the users are kings—it is no longer possible to build great products without their input. If you take anything away from this article, it’s that the waterfall methodology needs to be abandoned once and for all.

    Everyone Loves Kubernetes

    K8s is not a one-size-fits-all solution. The fact of the matter is that a large chunk of the enterprise still hasn’t fully embraced the cloud, let alone started containerizing their applications. So while we have to give credit where it’s due and acknowledge that K8s is the clear leader for orchestrating containers, we also have to acknowledge that the hype doesn’t quite match the adoption. It’s still a relatively young technology.

    According to a report from Datadog last year, 45% of their customers that run containers use Kubernetes. That number is growing and is certainly impressive, but when you realize that only a chunk of their customers run containers in the first place and they are a modern monitoring solution where we’d expect to see a higher percentage than a random sampling, it’s clear that K8s is far from mainstream.

    Everyone Is Doing Tracing

    The rise of the digital age has put monitoring and observability in the forefront. As we rely more and more on online services for internal and external interactions, we better make sure they are working properly. But at the same time, regardless of industry headlines and conference talks focusing on tracing, the truth is that the industry at large has yet to adopt it.

    For most organizations, there’s so much room for improvement in getting logging and metrics right, that there’s no need to opt for tracing (yet). After all, Google built most of its global platform relying on metrics. Unlike SREs, developers often find tracing alien and very cumbersome to deploy and wield. Instead, more and more companies are opting to empower their engineers to see what’s going on in remote environments through software understandability.

    AI Will Solve Our IT Problems

    We’ve been hearing about the promises of AI in IT for a long time now. One of the terms still actively promoted that I am very skeptical of is “AIOps.” What does that even mean, really? According to a recent report from OverOps, only a very small percentage of companies are even considering AIOps in their plans for the future.

    That said, I do believe in making better, data-driven decisions. So the more data we can collect, contextualize and understand, the better. We see how this helps companies identify anomalies, alert on issues and even project out into the future. But none of this, really, is artificial intelligence.

    Conclusion

    There’s often a gap between hype and actual adoption. That’s the role of good marketing. And ultimately, hype helps drive adoption. But as technical practitioners, we need to stay rooted in reality in software development and beyond. So while I am convinced agile has proven to be the best way to build and deploy software, and that most organizations would benefit from letting go of old-fashioned waterfall processes; on the other end, I haven’t been fully convinced of the benefits of tracing and AIOps for most companies.

  • Detours Ahead: Overcoming DevOps Challenges

    Detours Ahead: Overcoming DevOps Challenges

    Saying that you’re interested in DevOps is another way of saying you’re interested in change. That’s what DevOps promises any organization. No matter the problems a company is trying to solve or the goals it’s trying to reach, DevOps depends on a willingness to embrace some big changes. Sure, it can help you streamline software deployments, but it requires shaking up a company’s usual processes and routines. As we all know, change can be complicated, so before your organization transitions to an agile culture, it’s best to prepare for the likely challenges ahead.

    Breaking Old Habits for Continuous Delivery

    Many of the procedures we follow at work each day are second nature, and what’s familiar carries a certain comfort with it. Even when we realize a more efficient process is within reach, old habits are tough to break. For an organization that employs hundreds, any change can be a challenge.

    And DevOps offers no shortage of challenges. It entails overhauling a company’s deployment process, its communication patterns, its department structures and even the roles of individuals on a team. Yet unless an organization is willing to let go of its old habits, the benefits of continuous delivery won’t ever be achieved. When acclimating people to this new procedure, it’s important to convey that the old procedure – one team throwing code over the wall to another one – will be left behind for actual collaboration in which Development, Operations and possibly other departments work together, not just in silos.

    Getting Past the Resistance to Change

    Encountering some reluctance to change will be natural, and a smooth transition depends on making everyone aware of why DevOps will be a big step forward. This includes communicating what the advantages will be for individuals, departments and the company as a whole. With an agile plan in place, greater efficiencies will become the norm, and a team will have the ability to spot and fix problems more quickly, so 3 a.m. phone calls to the system admin won’t happen anymore. Once managers through C-level folks are aware of these potential advantages, resistance will gradually turn into acceptance and enthusiasm.

    Combating the Myths and Rumors

    Many think DevOps is only for the well-known unicorn companies, such as Etsy and Facebook, or that it’s an exact science that will produce the same results for everyone. Some even believe the rumor that DevOps only works with certain operating systems. The truth is that continuous development can take place anywhere as long as the company culture is right. As detailed in the Rackspace-sponsored e-book, The DevOps Mindset: Real-World Insights from Tech Leaders, many DevOps practitioners went through their own uphill climbs to become more agile, and they have the firsthand experience to resolve many popular misconceptions.

    “You don’t have to be in Silicon Valley to embrace the DevOps culture,” says James Kenigsberg of 2U. “In fact, many new firms these days have a bad habit of building shiny technology because it is shiny, which goes against the DevOps principles of communication and transparency.”

    Jeff Hackert of Chef dispels the myth that DevOps is a one-size-fits-all solution. “It is not a set of proscriptions or a recipe that will give you a defined best practices outcome,” he explains. “Your best practice is the collective wisdom of the very smart people you’ve hired to solve your problems. And if what you have is a siloed or broken environment, you want to increase the communication, not impose new rules.”

    Getting Automated Without a Struggle

    When an organization is considering DevOps, they may find that the opportunities for efficiency not only involve employee collaboration, but technology as well. Most IT departments would jump at any chance to save time when it comes to coding procedures, and automation is a means of making this happen. By offloading these processes to an automated system, people can tackle other tasks, and businesses that release several deployments a day can greatly simplify their rollouts. For those who might not be familiar with the ins and outs of automation, receiving some guidance from a trusted IT provider can be a good first step. Finding an advisor to guide your initial automation efforts can prevent the expense of hiring a DevOps engineer with automation knowledge.

    Finding a Path Around DevOps Obstacles

    Every company’s DevOps strategy will be unique, and every company’s plan for overcoming challenges will be just as unique. Whatever the circumstances, communication will be crucial to any adoption, as it ensures that everyone understands why such a change is necessary. Getting acquainted with the success stories out there will dispel any myths circulating among team members, and stumbling blocks can be avoided by the understanding that familiar silos will be replaced by more efficient collaborations.

    Despite its challenges, DevOps can be the catalyst for a variety of improvements, from productivity to employee morale. Those who are the most successful at being agile will not only have the right culture in place, but be able to negotiate the challenges that DevOps has in store for those ready to embrace change.