staging-devopsy.kinsta.cloud

Tag: devops implementation

  • Why DevOps Implementation is Often Unsuccessful – and How to Fix It

    Why DevOps Implementation is Often Unsuccessful – and How to Fix It

    Much like “blockchain” and “big data,” the term “DevOps” is another buzzword currently being thrown around the IT departments of large organizations.

    Many have identified the need for faster software development life cycles; a more precise process closely aligned with business objectives, allowing for clearer workflow and collaboration between the development and operations teams. DevOps is essentially agile, all grown up and ready to take on the constantly innovating and rapidly deploying needs of the modern business.

    For security professionals, it’s a fantastic initiative: We can inject security into the process far earlier, reducing the cost of fixing bugs and avoiding potential catastrophe down the track.

    The problem is, few companies are truly successful in their DevOps implementation. Without the right support, nurturing and understanding across the business, it can quickly become a white elephant, you know, one of those “don’t mention the war” projects.

    So, what’s the problem? There are a few ways to approach DevOps that I believe will make for much smoother sailing. An effective program goes beyond a few fancy new tools, titles and team meetings. It’s not always going to be easy but taking the time to fix a broken strategy (or implement it the right way from start) is going to be far less painful in the long run. Ultimately, it’s going to result in higher quality and more secure software.

    Let’s break it down.

    Let Go of the Agile Apron Strings

    There is somewhat of a misconception that an organization must choose between agile or DevOps, setting down one path or the other, never to look back.

    The thing is, the development process works best when both are being considered and implemented as one. DevOps is not a reinvention of agile development; rather, it is an extension of it. The wheels tend to fall off when there is an expectation the process will be exactly agile, or completely different from agile.

    Agile supports the principle of cross-functional teams, bringing designers, testers and developers together from the beginning and committing to open communication lines throughout a project. Its aim is to stop siloed delivery and reduce double-handling, both of which are benefits of the DevOps process as well. However, DevOps goes a step further, introducing systems, security and operations into the mix to offer a robust, end-to-end skillset that had the ultimate goal of full, functional software delivery to the customer.

    During the inevitable pain-points of moving to a more DevOps-centric process, the risk of siloed development can crop up again. You can often have the original agile team working together, with the security and operations additions still finding their way in the machine. No one is quite sure how to include them, what they should be doing and their overall objectives.

    DevOps does not work without clearly defined objectives, cross-functional onboarding and direct communication with all parties. There will be an adjustment period requiring careful change management but getting everyone on the same page with the enhancements DevOps functionality will bring is half the battle.

    Increasingly, DevOps is placing emphasis on security best practice as part of the process as well, demystifying that step and bridging the gap between the security team and everyone else. As I have said before, we still have a long way to go in empowering developers to code securely from the start, but the successful implementation of DevOps methodologies is an excellent foundation on which security skills can be built within the development team.

    Automation Isn’t Everything (and It’s Not the Most Secure)

    Another feature of DevOps methodology is, to a certain extent, the automation of the software development process. Continuous integration and continuous delivery (CI/CD) principles are the cornerstones of this concept, and as you can likely guess, very reliant on tools.

    Tools are awesome. They can bring unprecedented speed to the software delivery process, managing the code repository, testing, maintenance and storage elements with relatively seamless ease.

    However, while robots might take all our jobs and imprison us someday, they are definitely not there yet. Heavy reliance on tools and automation leaves a window wide open for errors. Scans and tests may not pick up everything, code may go unchecked and that presents enormous quality—not to mention security—issues down the track. An attacker only needs one back door to exploit to steal data, and forgoing the human element in quality and security control can have disastrous consequences.

    The happy medium is to ensure you have a balance of people and tools. Tools should serve as the assistants to a team you trust to deliver on project goals. You should:

    • Allocate enough time for people to become familiar with the chosen DevOps toolchain.
    • Focus on effective collaboration (and how the tools can support that).
    • Address any gaps in the process, whether they are skill/knowledge or tool-based.

    In short, don’t just tool up and hope for the best.

    DevOps Isn’t a Buzzword, It’s a Culture – Are you Growing Yours?

    Change management is tough at the best of times. Fear of the unknown can stop even the most brilliant team members from growing their skills and expanding their horizons.

    You see, merely saying “let’s do DevOps” and making the operations team move desks isn’t going to magically implement a successful process. Many will be confused, and long-serving members of the team will be left feeling disgruntled. Communication of expectations is crucial, as is walking the walk. DevOps represents a cultural movement just as much as a development methodology, and a team should live and breathe a cross-functional, collaborative mindset.

    What does a great DevOps culture look like?

    • Individuals are empowered to lend their expertise to a process, not just leaders.
    • Open, honest and respectful communication between teams.
    • Each person takes responsibility for the overall objective of building quality and security into the development process.
    • Everyone is on the same page with the definition of DevOps in the business, the roadmap and how/what/why of each person’s role.

    For years I have emphasized the importance of building positive security cultures in development teams, and DevOps is no different.

    The right tools, knowledge and support are imperative to achieving security best practice, seeing a downturn in discovered vulnerabilities and opening the team’s eyes to the importance of protecting our data. With DevOps, you must lay the cultural groundwork for positive change: Ensure everyone understands their role, value and expectations, the overall project goals and steps in the process.

    Have you mastered that? Great. Now, let’s shift the needle, dial up the security aspect and make DevSecOps the ultimate plan for software excellence.

    — Pieter Danhieux

  • 5 Mistakes to Avoid When Chasing DevOps Transformation

    5 Mistakes to Avoid When Chasing DevOps Transformation

    In less than a decade, DevOps has become a buzzword of the IT industry, and enterprises are already reaping its benefits.

    But the implementation part still remains a question for many firms, considering the key mistakes that many organizations report in their very approach to DevOps. Most firms are also unsure about what outcomes they want to see from the process.

    Wondering if you’re making the same mistakes? Here are the five most common mistakes that can be included as part of a checklist to successful DevOps implementation.

    Misaligned Focus

    While automation and tools are the elements that steer DevOps, most firms believe that DevOps is all about tooling and automation. In reality, tools are mere enablers and automation takes off the burden of manual work. This collaboration helps firms to realign focus, eliminate process repetition and effectively manage the available software.

    Ultimately, the value of tools lies in what people achieve through them and hence, firms should focus on utilization to achieve expected goals.

    Faster = More Value

    Time-to-market is another key aspect of DevOps that needs a different viewpoint. In general, most firms think of DevOps as a process to increases the pace of the software process.

    But it has to be understood that DevOps takes a lean movement. By developing software on an exponential pace, DevOps process lets you have products delivered more frequently.

    The lean manufacturing process achieves success in software delivery by breaking the chunks of code into manageable units, which naturally results in continuous delivery. Moreover, if you need to alter one component, you can do it simultaneously without impacting the other. This allows you to deliver at optimum speed and still maintain business agility.

    Lack of Continuous Improvement

    As you learn more and get better, you’ll find better ways to improve or cut down steps that add no value. But this will require some amount of effort and investment.

    DevOps delivery pipeline consists of feedback loops, which allow you to inspect, reflect and decide if you are going in the right direction. The faster you improve, the sooner you benefit from the improvements in the process.

    It’s just not about reviewing the process twice a year or every quarter. Continuous improvement demands that every individual part of the DevOps process should get better all the time.

    Dishonesty About Your Progress

    It is important to be clear about goals and timelines as an individual contributor in the software development process. A delay from an individual contributor can lead to a delay on everyone’s part in the process. This also adds to the lack of trust on a team’s potential.

    Whether it is about building features or changing processes, make realistic estimates. It is important to break your tasks into smaller pieces, making it easier for estimates.

    Change Comes Easy

    Change is a part of the growth process and it’s inevitable. But most people fail to adapt to change and continue with familiar patterns, especially when change is difficult.

    It is important to keep adapting to changing trends in the industry, processes and technological advancements including the software delivery lifecycle to evolve and grow, even when it is tough. Increased success will always bring more willingness to change.

    Conclusion

    DevOps is a process that drives innovation and business growth at a faster rate, provided you keep a check on the pain points that hinder the successful DevOps implementation.

    — Veritis

  • Implementing DevOps? Start with a Strategy

    Implementing DevOps? Start with a Strategy

    Organizations today are focused on improving the IT delivery process and taking it to the next level. DevOps plays a key role in achieving this goal, if it’s done right. But while the concept of DevOps is not new—it’s more than a decade old—a significant percentage of organizations have not yet implemented or are facing challenges in leveraging DevOps to achieve the intended benefits. Why do some companies achieve success with their DevOps implementation and others struggle? Simple: Those making DevOps work for them started their journey with a clear and implementable strategy. In fact, a number of organizations have formed their business strategy around DevOps.

    The relationship between DevOps and agile is complementary; however, DevOps implementation must be looked at differently than agile. It needs to be treated as a separate initiative other than the regular IT delivery scope until it’s established. It requires strategic thinking, significant focus and commitment make it successful.

    Key Pillars of DevOps Strategy

    The four key pillars for DevOps strategy are:

    • Identifying the vision and goals.
    • Identifying foundational factors.
    • Critical success factors.
    • Basing the strategy on measurements to track the progress and realization of benefits.

    Vision and Goals

    Drivers and challenges form the basis for vision and goals. Before embarking on the path to DevOps, it is crucial to analyze the “as-is” situation and understand the current challenges and drivers for doing DevOps. Current challenges could include:

    • Too many production defects.
    • Business stakeholders demanding features that the team is unable to deliver.
    • Painful deployments.
    • Team burnout and frustration.
    • Deployments done as ceremonies with multiple teams on call.

    If any of these sound familiar, that’s a sure sign your project needs DevOps.

    Drivers for creating the vision and goals may be external or internal. External drivers may be improving customer satisfaction by meeting expectations around availability, reliability, usability, performance, features, value and time to market. Internal drivers may be improving operational efficiency (speed, throughput, quality) or improving employee loyalty, improving technical capabilities or simply making deployments less painful.

    Critical Success Factors

    Below are the key factors in implementing the DevOps pipeline which includes continuous integration, continuous delivery and deployment. The continuous integration aspects cover configuration management, code packaging, branch/trunk implementation, static code quality analysis, code reviews and static security scans. The objective of continuous delivery and deployment is to move the code from the lower environment to the production environment in an automated way. The key aspects as part of the continuous delivery are embedding continuous testing within the pipeline and automating the applicable tests—unit testing, system testing, API testing and/or browser testing, along with the non-functional testing (performance and security). Another key aspect is integrating continuous monitoring into the pipeline—infrastructure monitoring (application and database servers) and application end user monitoring, which provides key input and metrics on how users are using the application and can be leveraged to improve customer experience.

    Key pillars of DevOps strategy

    Foundational Success Factors

    Foundational factors are critical for DevOps to be successful in an organization. Before embarking on the journey, ensure foundational factors are in place, such as management buy-in and support, maturity of the current agile process, conducive culture, collaboration among teams, CI/CD tools and availability of technical skill sets.

    It can be difficult for agile project teams to focus on working on the DevOps items along with the sprint-specific “functional” requirements. One way to increase the priority is to include the DevOps-related items in the sprint. That said, it can be challenging to focus and achieve DevOps objectives, as they may take a back seat to functional requirements during the sprint. Another option is to form a DevOps-focused group from within the projects (based on technical skills and inclination for innovation) that is assigned with the task of building and implementing a CI/CD pipeline. If necessary, this group can get help or expertise through suppliers. Forming a DevOps-focused group has been shown to be helpful in terms of achieving DevOps objectives.

    Metrics: Identify, Measure and Continuous Improvement

    Tom DeMarco famously said, “You can’t control what you can’t measure.” In DevOps, metrics and measurement are critical for success, as implementations take time. Metrics, therefore, should be aligned with goals and vision to track progress. Also critical are identifying the effectiveness of the identified metrics and making any revisions to existing metrics, as well as identifying and adopting additional elements for success.

    It is helpful to quantify the “as is” situation at the start of the implementation by measuring the metrics. That allows you to see the kind of progress being made on each of the aspects as you go along.

    The metrics can be categorized as per the balanced score card perspectives:

    • Financial (e.g. cost savings).
    • Customer perspective (e.g. time to market, number of defects per deployments).
    • Internal perspective (e.g. average deployments per sprint, number of successful deployments, average time per deployment, mean time to repair).
    • Innovation perspective (e.g. number of enhancements to pipeline).

    Though there are multiple DevOps aspects that can be measured, it is better to start small to avoid being bogged down by measurements. For example, you can start by capturing the average time per deployment or time to market and add other metrics as you go along.

    Conclusion

    DevOps is a critical initiative and focus area for organizations today. To be successful, a DevOps strategy—a top-down approach which provides clarity and transparency within the organization—is necessary. The key pillars of DevOps strategy can help lay the foundation and prepare—and keep—organizations on track during their DevOps journey. The strategy can be part of the project plan for a single project or can be leveraged for scaling out a DevOps initiative throughout the enterprise.

    — Girish Kulkarni

  • 7 DevOps Lessons in 2018: The Path to DevOps Success in 2019

    7 DevOps Lessons in 2018: The Path to DevOps Success in 2019

    We all learn from mistakes, right? But it would be better if we learned faster and didn’t repeat them in our future exercises. And this is exactly what we will discuss here in this blog.

    For a while now, we’ve been overwhelmed by the idea of the DevOps principle. We love how the collaboration between development and operations provides room for automation, continuous integration/delivery and enhanced time-to-market.

    But what about the tiny shortcomings we overlook in the process of continuous delivery?

    Listed below are some of the don’ts—or, rather, lessons learned from our DevOps implementation in 2018:

    Gauging Employee Capacity Over DevOps Delivery

    When Carmen DeArdo, Tasktop’s senior value stream management strategist, posed two questions to a crowd of 200 people, they had no answer to give. What were the questions, you might ask?

    • How many treat their delivery pipeline tooling as an integrated product with a product owner and an architect?
    • How many have any measure of how long it takes for them to deliver a feature or defect?

    Companies treat their delivery pipeline tooling as different components along the delivery chain. And, when it comes to measuring time taken, all that matters is getting the product to the finish line.

    These components are important if companies need to avoid obvious mistakes on the path to success. Consider the above questions the next time you set out on your DevOps mission. Within this aspect, measuring team happiness is as important as an integrated delivery pipeline tooling, and time is taken to introduce a feature.

    Companies need to strike a balance between managing work and achieving team happiness. This is important if the company has a long-term vision. Unhappy employees burdened with work don’t deliver the expected results. A sustainable pace helps companies ensure that employees don’t succumb to pressure.

    Revise the Management Strategy

    Organizations need to encourage their managers in a way that they are not put off by the DevOps process but rather motivated to build and maintain their team.

    Most organizations emphasize giving managers incentives to deliver expected results, maintain quality, expand team size, set immediate goals and rake larger profits. However, this strategy could backfire when applied to a DevOps implementation.

    Companies instead should encourage their managers to create an environment where the teams grow and become flexible, not only contributing to that process but also adding value to other processes, hence, the organization’s overall success. This thought process will lead to a chain of positive outcomes.

    Upskilled and Cross-Skilled

    Gone are the days when specializing in a particular skill was rewarding! The competitive market is looking for a workforce that is upskilled and cross-skilled. In short, employees need to be a package of multiple skills, with an emphasis on soft skills.

    Being multi-skilled not only supports transformational goals but also supports an organization’s goals. When the lack of new skills becomes a constraint, companies must invest in hiring individuals to propel transformation, which is equivalent to investing in automation.

    Automation ≠ DevOps Success

    Somewhere between adopting the DevOps culture and being DevOps-equipped, professionals have shifted from the purpose of DevOps to automation.

    In the process, people have lost control over the overall management of DevOps. Either professionals are in a situation in which the code is not built in the intended way or that the automated part is managed but the steps required for automation are not.

    Organizations instead should refocus their attention on the scalable nature of DevOps, building a new, fully automated process rather than automating an end-to-end process over time, as it is difficult and also time-consuming. Hence, automation does not equal the DevOps mission accomplished!

    From Idea to Blackboard

    DevOps once was more an idea of a team discussion rather than full-fledged process. But we saw 2018 transform DevOps from a mere idea to a part and parcel of everyday business—so much that it defines the way businesses plan their finances, regulations and organizational strategy as a whole.

    Additionally, DevOps experts in 2018 emphasized the need for value delivery than just focusing on details of technical practices. This can be achieved by constructing a managerial framework that bridges the gaps between business and technology.

    Relieve Your DevOps of Old Tech

    Last year also witnessed DevOps professionals moving toward new technology such as containers, Kubernetes and serverless. Why? It’s obviousthese technologies enable DevOps to deliver its promises. Trying to innovate the DevOps process or even innovate its end product with old technology will only take you backwards in the DevOps process.

    In 2019, we should realize that holding on to old technology will mean limiting your organization’s capabilities and impact.

    Identifying the Right DevOps Adoption Patterns

    While there are several DevOps adoption patterns out there, some organizations choose a central DevOps team enabling standard CI/CD tooling. The approach is in sync with DevOps thought leaders’ approach of reducing global complexity.

    However, this approach fails at catering to the needs of different teams. With the focus only on addressing CI/CD tooling, many centralized teams struggle with adoption.

    In another approach, companies seek to engage ambitious and autonomous tools to use DevOps tools and practices.

    This approach tends to match the common DevOps belief, ‘First prove that new work methods fit the enterprise, then spread.’ However, these teams are only successful in delivering projects with high levels of automation involved but have quickly failed to convert team-level experience to company-level.

    A 2019 DevOps adoption approach should focus on having high levels of team autonomy and reducing global complexity.

    Here are some tips to help you achieve this:

    • The central architecture team collect and share recommendations about languages, libraries and tools.
    • Teams consider these recommendations and experiment to see if there’s an opportunity for greater gain.
    • If things aren’t working, teams can change change and undo dead-end technology decisions/ideas.

    Now that we are ready with our lessons, it’s time to go live! Are you ready for your DevOps 2019 showdown?

    — Veritis

  • What To Do When Your DevOps Initiative is Failing

    What To Do When Your DevOps Initiative is Failing

    These days, it is difficult to find someone who hasn’t heard of DevOps. Statistics show that in 2017, just 6 percent of developers worldwide had never heard of it, and in 2018 this number decreased to 3 percent. You have to wonder who these 3 percent of developers are!

    Companies have been embracing DevOps initiatives with two core objectives: to reduce their time to market by delivering and deploying software faster, and to receive quicker feedback from customers. Many of these implementations have been successful. However, undertaking DevOps requires a major shift in terms of an organization’s culture and mindset, and companies often face difficulties.

    I want to examine some of the common challenges we see organizations facing and provide some best practices for overcoming them.

    Why do DevOps Initiatives Fail?

    Some of the core reasons DevOps initiatives fail include:

    • Not spreading a DevOps culture across the entire organization.
    • Choosing the tools without conducting research about what they do and evaluating whether they are a fit in your organization.
    • Setting unrealistic goals.
    • Trying to apply the same recipe that other companies have.
    • Not training your people.
    • Implementing a hybrid approach to DevOps where you attempt to keep your old culture.

    DevOps Initiatives Require Time and Patience

    Measuring your goals and monitoring your progress are the only ways to detect early warning signs that your DevOps initiative is not living up to expectations. But it’s important to note that patience is also required, as in most cases you will not achieve your objectives straight away.

    Getting to a full DevOps environment is not easy, particularly in large organizations, which are used to having siloed structures in their development process. So, start from the bottom up. Establish small goals that should be achievable, such as increasing the unit test coverage, improving the automation suit, reducing the time from code-commit to testing-ready. Measure these and use the results as possible warning signs or alert signals.

    There are also a series of steps you can take to put an initiative back on course. First, re-evaluate the process or processes you are having difficulties with and evaluate if:

    • The right metrics have been set and you are monitoring them.
    • The people applying the initiative are engaged with the DevOps culture, particularly if they are in different areas.
    • You have chosen the right tools.

    The Entire Organization is Responsible for Achieving DevOps Success

    In DevOps, the whole organization should be responsible if the DevOps initiative fails. There shouldn’t be one DevOps department or one person in charge of it; DevOps should be adopted by everyone, following the same path as Agile development. After all, they complement each other.

    Those companies that have successfully implemented DevOps have developed a strategy that fits the specific needs and demands of their organization. Although I’m currently mentioning some strategies that help companies achieve success with their implementation, there is no “magic” DevOps formula. A common mistake companies make when trying to fix a sub-par DevOps initiative is to simply copy what other companies do. Most of these companies end up abandoning the initiative because the outcome is not what they expected.

    Finally, if you’re planning to start implementing DevOps, keep in mind that it’s a process in which technical tools are as important as spreading a new culture based on collaboration, multidisciplinary, autonomy and open-mindedness. As this article points out, in many cases, the blockers to achieving success with DevOps are human, not technical.

    — Gabriel Vasquez

  • The Top 5 Ways DevOps Fails – and How to Prevent Them

    The Top 5 Ways DevOps Fails – and How to Prevent Them

    The working hypothesis for a Gartner report on how to avoid failure with your DevOps effort is that, unless the trajectory changes, “Through 2023, 90 [percent] of DevOps initiatives will fail to fully meet expectations.” The reason? You could boil it down to management not fully understanding DevOps tenets and nuances—things such as targeting business value, measuring success, meeting cultural/organizational challenges, fostering collaboration, understanding the inherently iterative process and managing for realistic expectations.

    DevOps is about people from multiple disciplines coming together to solve problems streamline workflows, develop new processes, break down silos to develop business value. “A lot of people fixate on the tools,” said George Spafford, senior director analyst, Gartner and co-author of the report. “They identify best-of-breed, lay out their toolchain and say, ‘Ta-da!’”

    The tools are important, but they are not the difficult part of DevOps. They are not a key obstacle. To succeed with DevOps, you often have to do something much more difficult: Change mindsets. Gartner identified these five top reasons for the failure of DevOps initiatives:

    1. Doing DevOps for DevOps’ Sake

    It’s important for DevOps initiatives to be grounded in generating business value. If the main goal is to achieve DevOps, you won’t be able to demonstrate sufficient value to sustain support. Failure to identify a business goal and focus the effort on attaining that goal can shut down the DevOps initiative  in only a few months. Identify business value by working closely with business stakeholders on a project-by-project basis to identify opportunities or obstacles and define the business value that will be developed. Avoid the temptation to rush DevOps implementation by taking too large a leap. Trust the DevOps process.

    2. Don’t Ignore the Culture

    DevOps can be intimidating in the early stages. Done right, it usually involves organizational change. People need to understand from leadership that this is not optional. They also need to understand what DevOps is and ultimately how it will affect them. Otherwise, what they imagine will tend to be much worse. It’s also of chief importance to communicate the business goals, both for instituting DevOps and the business value that you hope to generate. Senior leaders must recognize that DevOps teams represent “a fundamental shift away from traditional command-and-control hierarchical management models,” according to the report. “To improve agility, decision-making must move to where the information is.” Relaying information up and down the chain of command to make a decision isn’t feasible with DevOps. The teams need to be empowered to make decisions themselves. For that to work, key DevOps team members need to be fully aware of senior management’s strategic priorities.

    DevOps thrives in an open, honest environment where a frank exchange of perspectives is discussed, analyzed constructively by the group leading to decision-making. Many DevOps initiatives fail because they give short shrift to selecting people with the right temperament to help manage this process. Gartner suggests choosing people who you would describe as being team players, trustworthy, motivated, accountable, smart, experienced and effective communicators. Other words that come to mind include responsible, high emotional IQ, fair-minded, open-minded, aboveboard, not prone to casting blame, respectful and collaborative. In the end, for DevOps to work, you need to foster the type of environment people from multiple disciplines, with multiple agendas, can come together in a small team and get things done.

    3. What We Have Here is a Failure to Collaborate

    DevOps should not be limited to just IT and Ops. For it to succeed in generating business value, DevOps teams must work with other groups and stakeholders. This work “requires a systemic perspective and involvement, not uncoordinated silos,” according to the report. That said, while there is no magic number of DevOps team members, some have recommended five to 10 people. When you get into the range of 20 people, you may find that you DevOps effort is less effective. (Aside: It is possible to have more than one DevOps team.)

    In considering collaboration, don’t forget senior management. Look to gain the support of an executive who can help champion the effort. Finally, you know that DevOps is working when DevOps team members are collaboratively compromising deferring to each other’s needs. The trick is to solve multiple problems with every decision.

    4. DevOps is Iterative

    Too many companies get caught up in the notion that they can launch DevOps in a single bound. According to the report, historically, traditional transformation approaches have a high failure rate. “DevOps involves too many variables for this type of approach to be successful in a large IT organization,” Gartner noted. “An incremental, iterative approach lets organizations focus on continual improvements and avoid the risks” of what is often termed the “big bang” approach. DevOps by its very nature is focused on continuous improvement with an iterative process, rolling out smaller improvements more quickly. Any thought of launching it all in one fell swoop misses the point and shows a distinct lack of understanding about the principles of DevOps.

    5. Set Realistic Expectations

    DevOps and DevSecOps are enjoying the huge level of interest and popularity among enterprises. When that happens, the hype tends to overinflate expectations about the outcomes. Gartner advises that you manage expectations by agreeing on objectives and success metrics. Establish your starting point with whatever metric you adopt, then pursue the goal iteratively. According to the report, “DevOps is not a one-time effort; rather, it’s about trying over and over again.”

    — Scot Finnie

  • DevOps Consultant vs. DevOps Engineer: What’s the Difference?

    DevOps Consultant vs. DevOps Engineer: What’s the Difference?

    Understanding the roles of a DevOps consultant and a DevOps engineer

    Every now and then, every business reaches a tipping point — the point at which it makes more sense to kick off the transformation of any sorts, rather than resist it.

    Let’s imagine a situation:

    You own a company that has released a groundbreaking application. Marketers and sales did their job, and downloads grow at a breakneck pace. Unfortunately, your developers and operations aren’t keeping up with the scale; they cannot upgrade the app and release new features in time. You are afraid customers will lose interest because bugs are too many, and the performance leaves much to be desired.

    What can you, a business owner, do to remedy the situation and save your company?

    Well, actually you could do many things … (Say, hire more developers and testers to plug the gaps.)

    But, after scanning a few articles about DevOps, you determine that’s what can help you:

    • Increase application quality.
    • Enhance user experience and customer satisfaction rates.
    • Improve operational efficiency.
    • Step up employee productivity and their KPIs.
    • Reduce IT-related costs.

    You should quickly hire someone who knows a thing or two about DevOps. But who should you hire? Do you need to reach out to a DevOps consultancy, or should you get a DevOps engineer on your staff?

    These may be trite questions if you have been working in IT your entire life. However, for a casual business owner, they are definitely not.

    In this article, I will dive into the world of business and will do my best to clarify the difference between DevOps engineers and DevOps consultants.

    Who Are DevOps Consultants and DevOps Engineers?

    As a starting point, let’s define who DevOps consultants and DevOps engineers are. Are they actually that different?

    A DevOps consultant is a certified DevOps professional who is usually hired to resolve a specific issue or to educate employees to use DevOps tools, and who works according to the principles of DevOps.

    A DevOps engineer is an in-house tech person trained to implement DevOps practices into IT organizations in a cost-efficient manner and who usually acts according to the design created by a DevOps architect (or provided by a DevOps consultancy).

    Basically, the first provides guidance and shares insights about the ways of resolving problems at hand, while the latter is primarily focused on making a specific design work according to the established procedures.

    Note: Given that there is a lot of controversy surrounding DevOps and the DevOps transformation process, the roles of participants and the terminology may differ. On top of that, some argue that a separate DevOps role can create a third silo that worsens the silos between Dev and Ops teams.

    Who Should a Business Owner Hire?

    DevOps is no longer for unicorns only. Tech startups and even small and medium enterprises (SMEs) that want to manage their IT organizations more efficiently can opt for a DevOps transformation.

    Businesses that have a specific problem to solve (e.g., achieve faster and higher-quality app updates) are better off hiring a DevOps consultant. That person will assess the situation and provide concrete tips and next steps. Then, the business owner may or may not choose to collaborate with the consultant to implement the required changes.

    In the meantime, the necessity to completely overhaul the company’s technology-related processes and practices may encourage the business to establish a separate DevOps role in their IT-organization—a DevOps engineer. 

    (Some might even consider hiring a DevOps architect to create a design for their organization, and a DevOps evangelist to oversee the cultural transformation.)

    Unfortunately, DevOps engineers are hard to find. Not only is a DevOps engineer the second hottest job in the United States right now, but also the controversy about the profession results in ambiguity about what DevOps engineers should and should not do.

    While some DevOps engineers can oversee the DevOps transformation from A to Z, including the cultural aspect, others can realistically manage only specific stages of the DevOps life cycle or work with specific tools such as Jenkins, Maven and and Ant.

    Bear in mind that most DevOps engineers previously were either developer or system administrators, and that plays a considerable role in their competencies as well.

    Therefore, companies must be very specific about what DevOps engineers must be able to do. Otherwise, they risk hiring someone who will not be able to carry it through.

    In other words, even if the business owner may be adamant about hiring a DevOps engineer to assist the company’s Dev and Ops teams, they also may end up paying a third-party DevOps consultancy to create a road map for their DevOps engineer to follow.

    Bias Against DevOps Consultants

    While hiring a DevOps consulting company may be more viable and cost-efficient for most businesses (specifically, small and medium companies), CEOs, CTOs and CIOs are usually biased against DevOps consultants.

    They are afraid that:

    • DevOps consultants will only burn time off the clock and will not do their best to resolve a company’s issues ASAP.
    • They will pay consultants too much, while an in-house employee could do the same job for less.
    • DevOps consultants will get access to classified and business-sensitive data and then take advantage of it.
    • Consultants will never finish their job and will literally abandon the ship in the middle of a DevOps transformation.

    Truth be told, sometimes all of these things really happen. However, it should not dissuade anyone from hiring a DevOps consultant to help their companies do better technology-wise.

    Just consider a few factors here:

    • Not everybody has the skill to become a consultant. (Do not confuse a consultant with a regular contractor.)
    • Consultants’ expertise allows them to provide expert advice with no or little supervision. However, they need time to familiarize themselves with the client’s processes. Only then will they start to add value.
    • It is unlikely that DevOps consultants and DevOps engineers do the same work. Consultants are hired to analyze, provide insight and teach. Engineers are there to implement a validated strategy.
    • And finally, everybody makes mistakes. Any business should be able to reach out to legal folks to settle things down should any issues arise.

    Conclusion

    Experienced DevOps consultants and seasoned DevOps engineers are a scarce commodity, and it is entirely up to a business owner to decide who to hire to benefit their enterprise.

    For sure, they might not have any technical background. So here a few things they should bear in mind:

    Consultants can provide a bird’s eye view of a business. They check what’s right and what’s wrong, provide guidance and teach employees. Oftentimes, they help companies to align their Dev and Ops teams and streamline processes and practices across these teams.

    In the meantime, DevOps engineers are all about doing the job properly in a cost-efficient manner. Basically, they establish and support a healthy DevOps environment according to the company’s strategy.

    What are your thoughts about DevOps consultants vs. DevOps engineers controversy? Who would you hire if you were a business owner?

    — Eugene Duma

  • Integrating DevOps: Avoid These Common Mistakes

    Integrating DevOps: Avoid These Common Mistakes

    DevOps, as the name implies, is a combination of two professional teams—software development and the IT experts. Both the teams collaborate well with the aim of creating a bridge that accelerates and automates the process of software development and a more intensive testing before releasing it into the market with high confidence.

    DevOps has been identified as a software engineering culture that relies on philosophies and practices to bring more agility and improve the organization’s efficiency to cater continuous delivery and integration.

    Now, with the introduction of DevOps culture and transforming trends, the development and operations teams no longer work in isolation. In fact, the role of the DevOps team is also to keep an eye on the software development and manage the infrastructure.

    Many organizations have already begun using the DevOps, while various others are on their way to implement the new software development trend. According to a survey, the number of software developers adopting DevOps has increased to 17 percent in 2018 from 10 percent in 2017 worldwide.

    It is a good decision to implement DevOps and maximize its benefits to the fullest. However, choosing the right tool can be difficult, which could lead to mistakes and further lead to project delay or a complete failure. To avoid this situation, here are some of the common mistakes DevOps developers usually commit while undertaking the projects.

    Choosing the Wrong Team to do the Job

    One of the major mistakes organizations make while integrating DevOps is choosing the wrong team to do the job. It is the task of a proficient project manager to choose an appropriate team, but when inexperienced people come on the board, there can be issues.

    DevOps is a blend of both development and operations; thus, it’s a complicated job. DevOps is not limited to just bringing agility but also conducting the right deployment. Also, developers have to focus on both ends—development and administration—equally.

    Problems can occur when you start concentrating on one aspect of the cycle. So, it is better to hire an experienced team on both ends that can work in full coordination and collaboration with one other. Thes should have a sound technical knowledge and expertise in bringing the best.

    Starting a DevOps Project Without Planning

    Before commencing any project with DevOps, you first need a foolproof strategy and extensive planning. All of the members involved in the project need to understand their role comprehensibly.

    However, some organizations don’t think much about the planning and preparing a road map. They are just anxious to work on the project to complete it as soon as possible.

    This is a wrong mindset that will never be successful. Maintaining a good speed and delivering the project on time is perfect practice, but you cannot prefer speed over quality.

    Emphasizing More on the Agility

    Some of the DevOps developers have a misconceptions that Agile development alone will create a win-win situation for them and that they will deliver optimum applications. But the truth is the other way round.

    Yes, you cannot deny the significance of agility in DevOps development, as it has changed a lot from waterfall. However, merely depending on it to implement DevOps is not the right approach. When you use Agile, you primarily work on incremental, iterative work cadences. It is focused more on ensuring the customer satisfaction but you cannot deliver quality product, as Agile doesn’t have the proper infrastructure.

    Getting Rigid During the Implementation

    Don’t try to be too rigid while integrating the DevOps. This can hamper the entire project; it is difficult to act in accordance with the core tenets of DevOps. However, you can make adjustments using the DevOps model.

    You also should lay some guidelines about how to manage the stability of DevOps in the beginning and make sure it remains the same, even if problems occur.

    You won’t always get the desired result, so be prepared for any unexpected outcomes. You need to identify the root cause of the issue and so make adjustments accordingly within the DevOps ecosystem.

    Not Complete Buy-in

    Your DevOps implementation can also fail if both the development and the IT team are not fully on board. Therefore, it’s crucial that every professional involved in the project is synchronized.

    Remember, if you get stuck at even one point during the development or the testing, it would delay your project. Coordination should be well-knit and there should be one experienced person who can manage the entire team.

    Not Conducting Tests at Regular Intervals

    Another mistake during DevOps implementation is not running tests at regular intervals, which will provide improved outcome. You need to run the tests synchronously.

    Executing the tests at the same time will save lot of time and will allow you to complete your project within set deadlines. You need to employ the concept of continuous integration and continuous deployment (CI/CD) for the automatic process of test cases.

    Don’t Take Security for Granted

    While incorporating the DevOps, you are making a big mistake if you take security for granted. The two complement each other, and so security cannot be ignored. You have to plan a strategy for strengthening the security right from the beginning so that you don’t face any problems later on.

    For instance, if you expand the architecture using DevOps and afterwards find that security is not updated, you will have trouble. If you are developing a microservices architecture, security will come into play as apps interact with one another. And keep in mind that at no point of time can you compromise with security to provide ease of access.

    Not Giving Importance to Database

    Often developers avoid the importance of database during the integration of DevOps—while the implemention expands, the database falls short due to the automation process.

    The automation of database is also necessary as part of other issues such as managing the codes and continuous integration. You have to deal with the database carefully, as it plays vital role for the data-related apps.

    Implementing New Technologies Earlier

    It is good practice to choose the latest technologies for a project but when you are implementing DevOps, you need to be cautious. It is recommended not to jump on new techniques straightaway without proper knowledge and research—don’t go for the experiment.

    Don’t be a copycat and use any procedure just because others are using it. Plugins change frequently. You need to use tools smartly and intelligently according to the project requirements. Analyze the pros and cons of each of the use cases and then make a proper decision.

    Conclusion

    DevOps is a good software development and cultural practice that has gained enough attention round the world. It advocates automation and keeps a check on the entire cycle of software engineering, bringing both the development and the IT team in union.

    However, the developers commit mistakes while implementing the DevOps and so it’s important that they should be aware about these in advance.

    — Mehul Rajput

  • TechRepublic’s Bombshell Survey: A DevOps Fiasco?

    TechRepublic’s Bombshell Survey: A DevOps Fiasco?

    This month, I chose to share the findings of a TechRepublic’s recent survey on DevOps not only because it’s a bombshell within the IT community, but because it brings out two eye-opening facts:

    1. Seventy-eight percent of organizations haven’t fully implemented DevOps because “they don’t get it”
    2. Only 22 percent of organizations have merged their teams for managing infrastructure, operations and development

    In other words, the message underneath is, “You must consider most DevOps success stories with a pinch of salt.”

    The big question is, Why are all these DevOps implementation failures happening? That’s where I bring the answers most experts, including renowned thought leaders, for some reason won’t give you.

    The findings of this vital survey shouldn’t leave you indifferent. Your company’s survival and growth depend on them. They’re recurrently raised in all the conferences and workshops I give. “We deployed the automation toolchain; honestly, I don’t see the business value,” or “Making the business, development, testing and operations work together is an impossible challenge,” is all I hear all the time. The last time I had to address these complaints was at the Econocom’s DevOps Seminar in Toulouse, France.

    The answers I provide result in the same reactions: Companies successfully change their DevOps vision and implementation approach.

    Believe it or not, that’s my six-year experience advising on DevOps worldwide, as well as the observations of an increasing number of reliable IT industry analysts including Joe McKendrick and Jason Bloomberg. The three fundamental failure factors of DevOps implementation are:

    1. Either a lack of or unclear business objectives.
    2. Widespread misconceptions of DevOps including among thought leaders.
    3. Conflicting interests of the DevOps tools business.

    Let me give you a few ideas that will either help you monetize your organization’s transition to DevOps or adjust your existing DevOps capability and make it profitable.

    Unclear Business Objectives Result in Irrelevant DevOps Capabilities

    Again, that’s my experience and the observations of many IT industry analysts, most DevOps initiatives are disconnected from any business objectives.

    In all the workshops I conduct, the question, “What’s your business goal?” gets the same blurry answers: “Adopting DevOps is a must,”  “We must automate our IT processes,”  “Making our IT agile will make our business competitive,” “Speeding up delivery is a competitive advantage our business lines will like,” and “Automating our IT processes will do good to the business.”

    What you must know is, these goals range from vague and fake to inappropriate and nonexistent. They primarily serve the IT department’s interests. Not the business.

    The fact is, there’s a significant gap between business line expectations and the DevOps benefits as imagined by your IT leader peers and their associated vendors. The business looks to meet the challenges of the disrupted markets created by Google, Amazon, Facebook and Apple (GAFA, in the rest of the article)—competition which includes continuous innovation, accelerated time-to-revenue, cost reduction, low prices and market responsiveness. And the only help DevOps experts offer is the acceleration of applications delivery and the automation of IT operations. Is it enough? The answer is clearly no; it’s a drop in the ocean.

    The GAFA are disrupting your company’s markets. The only chance to resist them is to adjust your business model to the new competitive constraints. Because they didn’t transform as their disrupted markets required, Nine West Holdings, the Bon-Ton Stores, Toys R Us, Remington, Southeastern Grocers and Tops Markets were all kicked out of business. Read what Business Insider’s Hailey Peterson said about it in a recent article.

    I encourage you to involve your business lines in your DevOps project and agree with them on a clear business objective. Then, implement DevOps to enable that objective. Otherwise, that’s wasted time and more importantly, wasted investment!

    The Secret of DevOps Has Always Been About How Well You Work, not Technology

    This is something I hope you won’t doubt: Most experts including renowned thought leaders play on words to present DevOps as close to either an agile software development framework or a continuous delivery infrastructure (CDI). Let’s say it straight: That vision, now adopted by CIOs, is erroneous and has been taking thousands of businesses into the wall.

    Adam Jacob’s article, “The Secret of DevOps, It’s Always Been About People, Not Technology,” provides from my perspective, the best definition of DevOps. It presents it primarily as, “… fundamentally about taking the behaviors and beliefs that draw us together as people, combining them with a deep understanding of our customers’ needs, and using that knowledge to ship better products to our customers.” But he makes it clear, “Tools matter. Make no mistake, trying to change the way you work without changing the mechanisms by which you do that work is a futile exercise in excruciating failure. But tools exist in service of the prime directive: building highly functioning, highly effective cross-functional teams, that attack your thorniest business problems as a unit, rather than as lone individuals or silos with competing incentives.”

    What’s interesting with Jacob’s big picture is, it’s definitely business-oriented and takes into account value creation drivers such as the human factor, values and behaviors, processes and practices, cross-functional collaboration and, of course, technology. Every qualified IT leader should understand these drivers as the fundamentals of their company’s survival and growth.

    So, shrinking DevOps to agile software development and Jenkins, Puppet and Docker, and thinking it will result in revenue doesn’t make sense. That’s the reason why the 78 percent of organizations in the TechRepublic’s survey failed!

    Would you agree that to set up a profitable business, the most important thing is to deploy Jenkins, Chef, Docker? I hope not!

    DevOps is about how well you mobilize your company’s assets— staff and skills, values and behaviors, processes and practices, tools and infrastructure—to make it competitive and wealthy. Adopting DevOps, particularly in today’s disrupted industry context, is primarily a business transformation effort. Nothing else!

    If you don’t want to be part of the 88 percent of organizations that proved unable to merge their team for managing infrastructure, operations and development, like Adam Jacob’s article suggests it, tackle DevOps primarily as an agile business operational model. Otherwise, get ready to be among the next GAFA victims!

    Preventing the Next DevOps Fiasco

    I’m afraid the conditions for the next DevOps fiasco are in place. They have a name: The incredible power of IT vendors.

    The incredible power of IT vendors relates to what Harvard’s strategist Michael Porter calls the “bargaining power of suppliers.” It’s the market or industry configuration where the domination of one company or a group of companies reaches a point where they can impose their views, products and services. IT vendors are exactly in that situation.

    IT tools have improved productivity so much over the last 30 years that companies have come to believe that they can fix every business problem including innovation, agility and profitability. IT vendors, using massive marketing hypes, are taking advantage of the situation to make millions of dollars. Dollars aren’t the problem; it’s the poor ROI their clients get.

    Will this TechRepublic’s survey help to prevent the next DevOps fiasco? Time will tell.

    Key Takeaways

    Your company’s priority is to survive the disrupted markets created by the GAFA. You won’t make it happen unless you definitely acknowledge that revenue, the essence of your business, is created as part of complex process that mobilizes across your company’s value chain, your staff and skills, values and behaviors, processes and practices and, of course, tools and infrastructure.

    If DevOps can’t help businesses with what matters right now—survive their industry disruptions— it’s definitely useless!

    As Chris Tozzi, suggests it, “The other main possibility for the post-DevOps world is that we’ll see DevOps extended into more and more parts of the business that are not directly related to the two core areas of DevOps practice, development and operations.”

    Here’s a resource that tells you all about how to implement DevOps as the catalyst of your business competitiveness: “How to Yield Business Benefits with DevOps.”

    — Philippe Abdoulaye

  • Preserving Bottom-Up Innovation in DevOps

    Preserving Bottom-Up Innovation in DevOps

    Balancing top-down control and oversight with bottom-up innovation and autonomy

    The driving force behind DevOps adoption in the enterprise is the idea that it will enable faster and more frequent delivery of better quality software. If all goes well, DevOps should result in higher customer satisfaction and lower costs, but the journey to get there can be challenging. Unfortunately, only a minority of organizations that attempt to implement DevOps actually fully deploy it.

    There are many barriers to overcome before organizations can realize the benefits of DevOps. One of the main challenges is retaining sufficient top-down control and oversight without hampering bottom-up innovation. 

    From Start-Up to Enterprise

    The root of this problem lies in the fact that many ideas in DevOps were developed in environments with small teams and flexible organizational structures. In such setups, where everyone can see what everyone else is doing, visibility and control seldom are an issue. Adapting this approach to an organization with hundreds of geographically distributed teams, in industries with a lot of regulatory baggage and diverse legacy systems, is an entirely different prospect.

    How do enterprise organizations find a structure that enables individual teams to unleash their innovation and maintain a feeling of responsibility without losing oversight and control? If DevOps teams are not empowered to make their own decisions and free to move swiftly, then they’ll struggle to realize the benefits that drive adoption in the first place. 

    Walking the Tightrope

    Individual DevOps teams should be free to make local decisions, but these need to be in alignment with business goals at the management level.

    You don’t want to hamper the speed and reliability that automation brings, or the innovation that can come from autonomous decision-making, so you need to find a way to balance tools, processes and team structure to maintain control and visibility. Avoid flying under the radar; instead, aim for maximum transparency in what your DevOps teams are doing. Set goals and measure, because visibility for management will prove that the new approach is working, build confidence and secure more top-down investment.

    Connecting the Dots

    A large enterprise will have a number of DevOps teams, but they shouldn’t be completely isolated. Requirements such as audit trails, security access logs and compliance controls must be met by all of these teams. There’s little sense in making each individual team responsible for solving the same problems over and over again. Offer a set of standards and tools, but be careful not to shut down choice.

    That same logic applies to competence development, so offer your DevOps teams access to best practices and enable them to learn from each other. The size and structure of an enterprise organization does present unique challenges to DevOps adoption, but there’s also opportunity here to benefit from the scale by sharing and collaborating. Sharing and standardizing the right things will eradicate redundancies and free your DevOps teams to focus on improving their products and innovating, so the business derives maximum value from their efforts. 

    Finding What Works

    The right answer will be different for each organization, but there are some things everyone should keep in mind when building or shopping for tooling. It needs to support a large, diverse environment. Look for support for the platforms you use and consider extensibility, so you can add the functionality you need.

    A key factor here for orchestration tools—especially those that define and execute your delivery pipelines—is that they must be accessible for management. You shouldn’t need to be a technical expert to dip in and get an overview, or compile a report that provides the insight you need. Ensure you collect diverse metrics and present information in a digestible format so you can find bottlenecks and identify successes and failures and really deliver the best experience possible for the end user.

    About the Author / Andrew Phillips

    cropAndrewPhillipsAndrew Phillips is VP of DevOps Strategy for XebiaLabs, provider of software for continuous delivery and DevOps. He is a cloud, service delivery and automation expert and has been part of the shift to more automated application delivery platforms. He contributes to a number of open source projects including Apache jclouds, the leading cloud library, and is a co-organizer of the DynamicInfraDays container community events.