devopsy.kinsta.cloud

Tag: devops implementation

  • 5 Prerequisites for a Successful DevOps Initiative

    5 Prerequisites for a Successful DevOps Initiative

    There are certain tools and attitudes that are essential to any successful DevOps transformation.

    The manner in which a DevOps transformation is performed will have huge implications on the level of agility the company is able to achieve. However, before that point is even reached, some vital foundations must be laid. It is from that foundation that any innovation occurs. With that in mind, each of these elements are equally important, and should be regarded as such.

    Consensus

    Your first achievement on the road to successful DevOps should be an agreement on what DevOps means to your company and how it should be applied to your needs. Consensus on a strategy is almost as important as the strategy itself and must be in place before a detailed road map is constructed. Remember that DevOps is subjective and its implementation should vary from company to company. Consensus hopefully will be easy, but if not, it must be built by persuading doubters of the need for certain principles and practices selected.

    This is the first step on a cultural journey; the collaboration between Dev and Ops staff and their consensus on a plan could make or break the DevOps idea. The concepts behind the initiative need to be agreed on from all corners of IT, as well as the business and any other key stakeholders such as suppliers. It is important the cons and pros of switching to DevOps are made clear for a balanced proposition. The argument for a shakeup on this scale needs to be compelling and justified for it to go ahead.

    Consensus also involves handling expectations. To keep everyone happy there must be metrics and approximate timelines set in place so everyone knows what to expect and when, to avoid conflict further down the line. Only once consensus has been achieved and the basics are put in place can a more detailed road map be built.

    Flexibility

    A thorough road map is the skeleton that allows its muscular teams to flex independently toward a common goal. However, flexibility without allegiance to the agreed principles can cause chaos. The DNA that runs through all teams stays the same but applications vary, and so teams need to work autonomously if they are to cater for the specific needs and nature of the app they are working on.

    While the road map gives a structure and handles expectations, DevOps culture needs to be tied to business outcomes and not formal internal milestones. Each DevOps team needs to be trusted to interpret the road map as it suits the specific project they are working on. Agile methodologies must be used, of course, but their interpretation is devolved to the teams themselves. This license and trust is key in allowing DevOps teams to react quickly and mold around the needs of the individual application.

    Teams need freedom in terms of what tools they use and to an extent, how they use them. The methodology used to achieve the agreed core principles should have an element of flexibility. Tool-agnosticism is a must when choosing an automation solution for effective DevOps. Teams are happier and work faster when allowed to choose the tools that suits them best, making them more successful.

    Automation

    As C. Little said, “DevOps isn’t about automation, just as astronomy isn’t about telescopes.” An automated continuous delivery pipeline should underpin any DevOps initiative, adding consistency and reliability to flexible delivery methodologies. Tribal knowledge from Dev and Ops is gathered to create a pipeline that is the sum of the knowledge of its contributors. The pipeline is repeatable, and over time is made more efficient by rooting out inefficient manual processes. Modelling into a workflow helps all involved visualize where a team is in the app life cycle and what next steps need to be taken next and by who.

    Trust in application release automation can be a big deciding factor in how companies achieve successful DevOps practice. Sometimes there is a culture within a company of wanting to have manual control over certain processes that inevitably slow things down. Automating any and every manual task possible is essential to speed up DevOps. If a manual intervention is needed, the relevant member of staff can be notified by the automation solution itself, which automates out the remainder of the task for which manual intervention is not required. Over time, manual interventions will disappear altogether.

    The ability to give DevOps teams freedom in their tool selection keeps staff productive but adds yet more complexity and leads to a highly heterogeneous workplace. It’s important your automation solution has approved integrations to all tools DevOps teams might choose and also releases free integration to new tools quickly, so you can stay on top of the latest trends and continue to be successful.

    Cooperation

    Unless you’re a startup with heavy investment, you’ll likely be changing the structure and workload of your existing staff rather than hiring a new team suited perfectly to their individual roles. The success of DevOps depends on the ability to make positive change in the way team members collaborate.

    Resistance to change may occur due to staff being accustomed to working in one particular way for a long time. However, this could also be down to personality type. As it is Ops and Infrastructure staff who face the biggest changes and are used to limiting rather than encouraging risk, often they can be the most resistant to change. Often devlopers do not have to change the way they work to the same extent, so fewer feathers are ruffled.

    I have seen big corporations that do not have compliance from everyone, so their DevOps is limited in scope and unfortunately they will never reach full agility. Sometimes you must adjust your teams to ensure positivity to DevOps and receptivity change in general.

    Rethink Architecture

    I’m not saying DevOps cannot be implemented in legacy systems, but there are elements of legacy systems that make it hard to instill full automation and continuous delivery. What is important is that the organization is open to a certain degree of architectural change. Monolithic apps can certainly slow down a DevOps initiative—often it’s mainframe apps that are not built with a service-orientated architecture—so it’s important to know how to adapt them to fit your strategy.

    A full architectural revolution is not needed to be successful. Obviously this is where cloud-native startups have an advantage as they can assemble their infrastructure from scratch, but there is no need to rip and replace existing systems for the sake of it and waste money. Certain elements of even the most monolithic systems can be modernized—for example, Siebel deployments can be fully automated so operations staff are free to concentrate on more demanding aspects of the cultural change DevOps involves.

    DevOps applications can interact with legacy systems if we use the right techniques. Make sure your automation solution has integrations with the likes of SAP, Oracle and Siebel, and so enables legacy systems to be enablers on your digital journey rather than obstacles that will stand in your way as you seek to reach full DevOps and end-to-end continuous delivery.

  • You Say You’re Doing DevOps, But What Does That Mean?

    You Say You’re Doing DevOps, But What Does That Mean?

    From recent conversations I have been having, it is clear that DevOps is top of mind for many. Out of the 40 or so customers I have spoken with recently, the overwhelming majority brought up DevOps during our conversation. They believe they ought to do DevOps, but they wanted me to help them define it and point the best way to get started.

    From my experience, many claim to be “doing DevOps,” but when you drill in, you’ll find wildly varying degrees of what this means. If a team is doing anything at all within the larger DevOps value chain, such as testing their software, they often believe they’re doing DevOps.

    Our latest survey on the implementation of DevOps points out how easy it is for companies to say they’re doing DevOps but how difficult it is to do DevOps effectively. There’s widespread agreement among the respondents on all the different things that should get done, but very few people are making significant progress in most of them. If you ask about specific DevOps success factors, very few people are doing them.

    Understanding, Then Doing DevOps

    Why is DevOps so hard? In general:

    1. companies don’t know how to do it
    2. companies aren’t sure what it is
    3. it’s too hard given the existing organization and/or culture
    4. too many jobs and people identify with existing tools and technologies
    5. there may be regulatory issues
    6. there’s a lack of leadership on what needs to get accomplished and the direct impact on users/customers

    The biggest issue usually is the organizational structure. People within IT are working in roles that have institutionalized the separation of dev and ops for 20 or 30 years, and suddenly this must change. Ops, in particular, has a process that is somewhat opaque, but now it has to be transparent, ops teams have to coordinate closely with the development teams, and they are being measured on totally different things. That’s a huge shift.

    Going back to the results of the survey, if you told me 20 percent of companies are doing some element of DevOps exceptionally well, I would agree with that. If you tell me 20 percent of companies are doing DevOps end-to-end the way I think it ought to be done, I would say that number is probably closer to 5 percent.

    The definition of DevOps makes all the difference. To me, DevOps focuses on the distance between the idea and the customer, whether that idea is a feature, an application or a business model. The purpose of DevOps is to optimize that distance.

    I use the word “optimize” for a very particular reason, because there are several different dimensions beyond speed that we need to think about. We also need to optimize for reliability, or perhaps it is appropriate to think of that as quality. Efficiency is another dimension: How much does it cost to run that pipeline? Finally, agility: If I have to make a change based on the customer feedback or the market conditions, how rapidly can I change?

    Based on your customers and what you’re trying to achieve in your business, you might optimize for those four dimensions differently than some other company. In some cases, a company might choose to emphasize speed, rolling out a new release every single day. In other cases, reliability, efficiency or agility might be given more weight.

    The purpose of DevOps is to make speed, reliability, efficiency and agility a given so companies can focus on digital disruption and serving their customers better—we can see that in the survey results. If we also look at the 20 percent that are farthest along in implementing DevOps, we see their most important metrics are customer-facing metrics. In other words, it is clear that with the emergence of companies focused on business insight analytics, more organizations want to know if their application is meeting the needs of the customers as it was intended.

    This is where the cultural and organizational challenges of DevOps come into play. If the ops team owns ops-related metrics, and the dev team owns dev-related metrics, then the organization is probably losing its focus on the customers. Those internal, traditional metrics are not going to get organizations to the Promised Land. You may have developed a bunch of code faster because you’re agile—and that’s great—but it’s only the first step. Instead, if we turn this around and say, “We expect this application to generate a million dollars of new revenue every four hours,” that’s a totally different mindset, and you have a much better chance of DevOps success. The app is either generating the revenue or not, and it’s the feedback you get based on the usage of the application that tells you what else you need to do.

    ING is a great example of a company that has a group of people who are focused on metrics that track the distance between the idea and the customers, and they wake up every day with a focus on how to optimize that distance. The rest of the company is then organized and culturally aligned to deliver against that.

    When you talk to most companies, you’ll find that there are elements of agile development, code pipelining or release automation that they do very well. These companies are taking a vertical or functional slice—such as test automation or release automation—and concentrating on optimizing there. That just gets us back to where we started our discussion, with everybody saying they are doing DevOps but no one doing it successfully. A better way would be to take an application and optimize all of the delivery metrics around that application. Take it all the way, end-to-end, and focus on solving a customer problem. Once that end-to-end distance is optimized, then you can apply what you’ve learned to other applications.

  • The Human Factor in DevOps

    The Human Factor in DevOps

    DevOps is about pinpointing and eliminating bottlenecks in order to deploy code often—shortening the time-to-market and increasing quality and effectiveness. One of the most common bottlenecks in the release process is the interaction between the developers and the integration services/operations group.

    Development (Dev) is entrusted with producing innovative software quickly while Operations (Ops) knows that service failures are often attributed to changes. This means Ops feels that if fewer changes are executed, fewer failures will occur and the system will be more stable and responsive. The natural conflict and opposing priorities between the two groups can create a productive equilibrium, but often results in communication difficulties, animosity and a financial loss for the company.

    (more…)

  • DevOps: Caution Ahead

    DevOps: Caution Ahead

    Despite the continued adoption of enterprise DevOps practices, some organizations, especially those in highly-regulated industries remain cautious about moving forward too quickly.

    “There’s no doubt that DevOps brings benefits for some organizations,” says Martin Fisher, director of information security at Atlanta-based WellStar Health System. “However, many pushing for DevOps underestimate the amount of technological and cultural change that is necessary to overcome before moving ahead to boldly, especially among those in security and regulatory compliance roles that are concerned with securing and auditing processes they see as they’re potentially losing control over,” Fisher says. “You can’t audit and secure what you can’t control,” he says.

    Eric Cowperthwaite, former chief information security officer at Providence Health and Services agrees. “There are some who want to move too fast. In many organizations the culture just isn’t yet there, especially where they are used to very rigid quality assurance and audit controls,” says Cowperthwaite, currently a VP at Core Security.

    It’s certainly not uncommon to find chief security officers in heavily regulated industries who are concerned that the move to DevOps is an excuse to cut corners and move more quickly by cutting out necessary oversight. “You’ll find if you have a developer that’s producing a dozen mistakes a day, if you poke at them about it then you’ll find out that they’re tired of the structure, of the bureaucracy,” he says. “DevOps need to be done in a mindful and thoughtful way,” Fisher says.

    Cowperthwaite agrees, and contends that in certain environments DevOps will be – should be – taken slowly. “You have legacy systems and very highly audited and controlled systems where DevOps is just not going to flow for some time,” he says.

    It’s not just the cultural shift, but also the shift in necessary for good governance capabilities to keep up, they contend. “Not all systems are geared to handle 200 commits a day, nor do they have the ability for reasonable tracking and accountability for that kind of speed. In fact, there are many legacy systems were it’s not even possible at all,” Fisher says.

    However, not that all companies that move toward DevOps are attempting to automate everything – at least not at first. But it is higher levels of automation most certainly seek. A survey recently conducted by automated server management software provider JumpCloud found that many companies are turning to DevOps to automate time consuming activity, such as deployment, patching, user management, log file analysis, and forensics activities.

    Some of the trepidation is warranted, to be sure, and some of it may be due to the media and industry focus on the outlier DevOp implementers. “I think, justifiably, a lot of the fear comes from the fact that a lot of the companies that have gotten the most press regarding DevOps are doing things that are radically different than what is going on within the bulk of IT work at traditional enterprises such as banks, healthcare, and organizations like that,” says David Mortman, chief security architect and distinguished engineer at Dell Software Enstratius.

    When it comes to enterprises with trepidations when moving toward DevOps, all of the interviewees we spoke with agreed the key is to move slow. But still move and develop the culture and the toolsets slowly. “Pick one system that is separate and use it as a concept,” Fisher advises. “The DevOps ‘true believers’ are given a hall pass to fully run their systems and group in a DevOps model. As they learn and improve you slowly assimilate into the broader environment,” he says.

    Mortman sees it in a similar way, but notes that it’s not just about technology and absolute speed, but also collaboration, culture, and relative speed. “How fast is fast for your organization? If you’re only making changes to your big medical records database every 18 months, and you switch to every three months – that’s faster. That’s more continuous deployment than you were doing before. No one has to jump right in,” Mortman says.

    “I started working with those sort of DevOps-y concepts back before I was aware of the term “DevOps,” Mortman adds. “I was calling it “Agile InfoSec” and “Agile Ops.” And with that mindset, even the most regulated, paranoid enterprise can embrace DevOps. Start with small, modestly achievable goals and build from there. Collaborate and more tightly integrate the teams.