devopsy.kinsta.cloud

Tag: devops adoption

  • DevOps Case Study: Cyxtera Improves Quality of Security Application

    DevOps Case Study: Cyxtera Improves Quality of Security Application

    The ability to fail and recover quickly and frequently roll out new features are DevOps benefits any development team can appreciate. But when the team is building a security application that must protect users in real time, the ability to update and upgrade the product quickly isn’t just a nice-to-have—it’s a requirement. Security applications require rapid development to respond to security issues and must be tested continuously to ensure quality.

    By design, Cyxtera’s AppGate SDP is a highly technical product. A comprehensive software-defined perimeter solution, AppGate SDP is designed to secure any application, on any platform, in any location. The product dynamically creates a one-to-one network connection between the user and the resources they need. These sophisticated capabilities make development and testing a challenge.

    Testing AppGate requires a complex infrastructure that includes the network, user desktops, the application itself and a variety of scenarios. To ensure product quality, everything must be tested, including all upgrade processes on all versions of clients.

    Previously, the AppGate  team used an iterative approach to development, but the cycles were long. In some cases, developers had to wait up to two weeks for feedback on their build, making it difficult to maintain quality.

    In an effort to reduce the time to feedback, the AppGate team adopted a DevOps approach. By automating testing, we sought to eliminate the barrier between developers and test results. Developers are most productive when you give them instant feedback. They are more eager to change their code when they’re excited about a feature they’ve just developed and want to see it succeed.

    In addition to automating tests, we removed the QA team and created a single team of 20 developers who are responsible for coding, testing and implementing the feedback from tests and from customers. This organizational change created some cultural challenges.

    Our developers needed a different attitude, and QA needed a different skill set to go from manual testing to development. That’s not a change you can do overnight, and sometimes it’s not even possible if a QA engineer has no ambitions to become a developer.

    DevOps offers many advantages but can be challenging for organizations to embrace. For us, it took about a year of coding outside the product before developers began coding in the product itself. You need to invest time at the beginning to automate procedures, and that’s not always feasible in a normal project because development is all about quick gains and getting the product to market rapidly.

    After about a year, our AppGate SDP team started to see speed and quality improvements in an order of magnitudes. The team of 20 has performed last year more than 2.5 million automated end-to-end product tests and created 560,000 virtual machines for testing alone. Those numbers are only possible with automation. If a security issue or a bug is identified in the field, the DevOps team can address it immediately. The team’s agility empowers them to respond to inbound customer requests as well.

    An unforeseen benefit of moving to a DevOps model is the additional creativity the team enjoys.  Test automation requires strict rules and processes, but instead of being perceived as a restriction, developers believe the structure gives them more freedom.  Developers can write anything they want as long as the tests, code reviews, security checks, etc., are passed. If the tests weren’t automated, we’d have procedures in place for sign-offs, etc., to make sure everything is done properly. Now developers feel like they have more freedom, and that drives creativity and productivity.

    The new model also provides a safety net, allowing the team to be creative without fear of failure because they know they can recover quickly. They get instant feedback on product quality and feedback for rapid failure. It’s better to fail fast instead of over several weeks, when it’s much harder to fix.

    The AppGate team has the luxury of using the product they build on a daily basis. When developers request access to an application or system, AppGate looks at the user and device profile to enable secure, context-based access. This serves as another layer of testing, and basically makes every developer and employee a test user. It brings a lot of knowledge to the team on how the overall product works (so it goes way beyond the code they have developed), providing a better knowledge base for future improvements.

    Automating tests enables you to scale at an unseen level, but you’re always testing the same use case repeatedly, and that’s not realistic. Using our own product all the time provides a lot of exploratory testing feedback. We’re testing a variety of traffic patterns and different ways of using the product, and we have immediate feedback. This feedback, combined with rapid development, empowers us to deliver a high-quality product.

    — Kurt Glazemakers

  • The Role of DevOps in the Financial Services Industry

    The Role of DevOps in the Financial Services Industry

    We are living in a fast-changing environment where unexpected technological, economic and political changes can be expected and where it is necessary to adapt quickly to these changes. This statement is especially true in the financial services sector, where there is a greater need to exceed the expectations of customers and provide uninterrupted service.

    From small trading firms to the financial industry players—big banks and exchanges—all are racing to deliver features and content to customers more quickly, and opting for DevOps tools, practices and ideas to solve the problems arising in financial systems.

    In DevOps methodology, the development and operations engineers work together in the entire service life cycle, starting from design via the process of development to production operations, maintenance and support. A DevOps approach is helpful for the adoption of various technologies such as blockchain, which is the technology behind cryptocurrencies such as bitcoin wallet. In this article, I will discuss the applications of DevOps methodology in the finance industry.

    How DevOps is Transforming Financial Services

    As said earlier, financial services companies face new challenges in their day-to-day operations in meeting the standards laid down by the unicorns. To support today’s digital age, many financial services companies are modernizing their back-end systems and processes.

    In addition to using legacy systems and code, they can face difficulties in meeting governance requirements, complying with regulations and alleviating risk for better security. These concerns make the software innovation a slow and complex process.

    But, over the past few years, the financial services sector is leading the transformation when it comes to adopting latest technologies and modern software delivery practices including DevOps, continuous delivery (CD) and Agile.

    Finance executives view DevOps as a way to bring value to the market in a more safer and efficient way. DevOps allows financial services to enhance the quality and cadence of application releases while addressing compliance, security, risk and governance strategies. Now, let’s dig deeper into the ways in which is transforming the finance landscape.

    Mitigating Potential Security Threats

    In the financial services industry, compliance and security are major concerns and have been the major setbacks in replacing legacy practices of software development and delivery. In the initial days, DevOps practices were seen as major risk to security and the enhanced velocity of software releases it allows was viewed as a threat to security, governance and regulatory controls.

    In spite of the initial setback, some enterprises that adopted DevOps have shown consistently that these practices actually reduce potential security problems and help companies locate issues and tackle threats more quickly.

    Due to this many companies have embraced the automation practices that enable and enforce compliance, security and audit requirements. Today, financial services companies view DevOps as a resource for security.

    Automating all the Processes

    Automating the processes all through the software delivery pipeline is another essential to enhancing resource utilization, product quality and developer productivity, and allow cross-project and enterprise-scale management and visibility in financial services. For any continuous delivery or DevOps initiative, automating all the processes is becoming a major requirement for enabling scalability and speed, ensuring compliance and achieving higher product quality.

    DevOps offers enterprises with an efficient approach to alleviate risk from software releases and aid the ever-evolving demand for frequent application updates. By managing all the release processes in a single centralized platform and automating the complete end-to-end pipeline, these companies gain visibility into the progress of all DevOps processes and releases and make sure they can optimize, govern and control their delivery pipelines even as they evolve.

    Driving Cultural Transformation

    DevOps focuses on creating an environment and a culture where the business, operations, quality assurance, development and other stakeholders work collaboratively toward a shared goal. While optimizing the technology and tools to scale DevOps adoption, embedding security practices and automating the life cycle are the major steps. DevOps is a mindset and any change in culture takes time.

    This change takes time and even the financial services industry that is regulated heavily is implementing DevOps and leading the change from both the cultural and technology standpoint. Thus, the financial services companies have what they need to keep pace with the unicorns, modernize their benefits and completely harness the benefits of DevOps.

    Orchestration

    For many financial services companies, the four basic software delivery pipeline stages (release, deploy, test and build) consist of numerous processes that hold within them millions of jobs and thousands of tasks executed by a large number of people. These toolsets, processes and the people are often present in silos, making things even more challenging.

    While existing in silos, these people may become skillful at understanding and enhancing their part of finding the solution, but from an organizational perspective, there is no end-to-end visibility and orchestrating the complete pathway is impossible. This leads to a lack of governance, errors, delays, manual handoffs and fragmented processes.

    As the IT operations and development teams are often geographically distributed in these large organizations, it is important to enable shared visibility and control into the different processes, tool chains and infrastructures. Optimizing the process of software delivery shouldn’t be attacked as a separate set of problems but viewed as utilizing a system-level approach, much as the manufacturers of cars apply lean manufacturing principles all through their production lines.

    The implementation of DevOps is spreading rapidly in financial services sector due to the value that this global, systems-level approach enables. DevOps accomplishes this by scaling the latest IT process across the entire organization in order to enable an end-to-end, robust pathway to production.

    Eliminating friction between teams and breaking down functional silos by orchestrating every aspect of the software delivery pipeline to create repeatable, predictable processes that can operate frequently with minimal human intervention prevents many of the challenges distributed companies face.

    Conclusion

    Even facing strong opposition in the beginning, many organizations took a risk implementing DevOps and have benefited substantially. Today, many technologies such as big data analytics are evolving rapidly and are implemented by many organizations around the world. According to a Peoplehr post, data analytics is used to enhance various organizational activities. Those companies that embraced analytics as part of their activities have gained huge benefits from it. In the same way, any new technology such as DevOps has to be embraced by organizations in an effective manner to enhance their overall productivity.

    DevOps implementation eliminates the security problems before they become a major threat and scales the IT processes across the whole enterprise, thus allowing an end-to-end and vigorous pathway to production. Every day, more organizations are switching to DevOps and not looking back. The change to DevOps culture may take time, but it will revolutionize the activities of an organization, including financial services.

    — Sujata Rani

  • Culture Becoming Bigger Issue as DevOps Goes Mainstream

    Culture Becoming Bigger Issue as DevOps Goes Mainstream

    Culture and resistance to DevOps processes appears to be growing at many organizations where DevOps projects have started going mainstream and involving more enterprise groups.

    Cloud automation vendor Quali recently surveyed 1,300 DevOps and IT professionals on some of the key barriers to DevOps adoption and found more respondents identifying culture as a top issue compared to last year. Twenty-two percent of the professionals in Quali’s most recent survey cited stagnant organizational culture as the biggest impediment to DevOps—a substantial 8 percent increase over the 14 percent who said the same thing last year.

    Quali interpreted the trend as likely the result of more groups getting pulled into broadening DevOps projects at many organizations. Innovation cultures and processes are being impacted in a broader manner as this is has happened. The trend shows why managing culture has to become a top-down responsibility, the firm said.

    “As technologies, processes and tools go mainstream, they touch a larger number of people who may need to change the things they do or how they do it,” said Shashi Kiran, chief marketing officer at Quali. “Eventually, change is never easy. It is actually a good thing that culture is there at the top, which means change is touching a lot of people across the organization, which eventually should be net positive.”

    An October 2017 report from analyst firm Forrester Research also suggests that more organizations are at least beginning to recognize the need for a cultural shift. Its research shows organizations are making culture a core focus when implementing DevOps projects. The focus is on shifting the mindset of teams to a culture of experimentation, where failure is used as an opportunity to learn and evolve processes instead of as a reason to add more controls and checks. “These mindset transitions are imperative for successful DevOps, and the market trends are encouraging,” Forrester noted.

    Other Barriers to DevOps Adoption

    While culture is a top barrier to DevOps adoption, it is not the only one. Quali’s survey showed application complexity and legacy processes to be major factors as well, with 20 percent and 21 percent respectively identifying the two issues as among their top barriers to DevOps adoption.

    The survey also found that DevOps teams at many businesses are still heavily dependent on their IT organization for infrastructure and continue to use a ticketing system to request and receive required resources.

    Nearly 50 percent, for instance said they had to wait for up to one month to get access to infrastructure resources that they had requested from IT, while the wait was even longer at about 24 percent of the organizations in the Quali survey. Only 27 percent—or barely more than 1 in 4—of the DevOps teams represented in the survey get access to requested infrastructure in less than one day.

    The numbers are important because slow access to required infrastructure often could have a big impact on the speed and productivity of DevOps teams, Kiran said.

    “DevOps teams don’t want to be bogged down by infrastructure. To a large extent, it needs to be invisible to them,” Kiran said.

    However, the fact is that environments need to be set up for DevOps and many times there is an infrastructure dependency on the back end. “This may be someone else’s responsibility, but the DevOps team ends up waiting for infrastructure to be set up and that’s frustrating for them,” he noted.

    Predictability is important in DevOps environment as is planning and being able to accommodate dynamic change environments, Kiran said. “Self-service is a preferred option where people are involved in environment buildouts, modeling different components and in testing and deploying them,” he said. One-third of the respondents, for instance, said they were strongly inclined to adopt platforms that enabled self-service automation.

    The Quali survey found that the degree to which an organization automates processes has a big impact on its ability to enable a self-service capability. More than two-thirds of the organizations surveyed had some form of automation. Of that, 33 percent had implemented a self-service capability for R&D, development and testing initiatives. Generally, organizations with automation and self-service reported improvements in production and agility compared to organizations that had fewer automation and self-service capabilities.

    So, where in the development life cycle is most of the automation happening in DevOps environments? The answer isn’t clear because automation is happening in a somewhat siloed manner, Kiran said. “Continuous integration is a starting point and larger organizations adopt continuous deployment as well, based on their internal methodology.” But, for the moment at least, there is no platform that can navigate creation of DevOps environments, expose them for testing and push them into production—all as a continuous life cycle—with full-on visibility, Kiran said.

    Kiran’s take on automation is similar to that reported by Forrester last year, which also found silos of automation continuing to be a barrier to DevOps success at many organizations. Forrester has identified “purposeful end-to-end automation” as foundational to DevOps success, especially at scale.

    According to the analyst firm, organizations that have implemented complete automation of the CI/CD pipeline have been able to enable rapid deployment. However, despite progress, plenty of opportunity still exists for automation and for deeper collaboration between infrastructure/operations teams and development teams, Forrester has noted.

    Quali also created an infographic illustrating some of the finer points of the survey, which can be accessed here.

    — Jai Vijayan

  • DevOps: It’s an Odyssey, not a Journey

    DevOps: It’s an Odyssey, not a Journey

    It has become somewhat of a standard practice to tell people, “DevOps is a journey, not a destination,” which attempts to convey the fact that there is no end point that is set in stone. But a journey is a well-planned, point-to-point trip, while DevOps transformation is a messy, figure-out-the-next-steps-as-you-go trip.

    So I propose we quit calling it a journey and start calling it an odyssey. This summer, when my mother takes her 10,000th trip back to Germany, it will be a journey. She’ll start in Cincinnati, Ohio, and travel through a couple of states before finally making her way to Hamburg, Germany. That’s a journey. She knows where she is going, and the discrete steps along the way.

    Her original flight from Germany? That was an odyssey. The trip went Berlin->Naples->Shanghai->Hawaii->California->New Jersey. Of all of that trip, only Berlin->Naples was a choice. Or, rather, the decision to go to Shanghai was a choice that required Berlin to Naples—very much in line with your DevOps choices making decisions for you along the way. And just like her family, you have no idea what your choices will be in a few iterations. They knew they had to go to Shanghai because that was the only port that would allow them in without visas, and they couldn’t get visas. After that? They knew they wanted to get to the United States or Australia (one assumes anywhere far from the insanity that was engulfing Europe and Asia during World War II), but how to get there was a total unknown. “First we start, later we finish,” was her father’s description of the goal.

    And that’s pretty much what DevOps is: First you start, and in the fullness of time you will discover things you hadn’t even considered when starting that just make sense and improve your overall position. There will be fits and starts, wrong turns and massive improvements. It is an odyssey, and one that is designed—just like my mothers’ family’s flight—to make things better in the long run.

    For example, the choice of Ansible or Puppet will make other choices easier. Giving teams more autonomy and increasing communications will make other choices more obvious. It will evolve into more than the first iteration’s goals would suggest, and that’s a good thing if increased agility and reduced manual intervention are the results.

    So keep on that odyssey, but don’t expect a simple end. More likely, the identification and acquisition cost of future improvements will cause more than the benefit they introduce, and you’ll find yourself in a better place, ready to breathe a bit and let the market find new ways to improve all things DevOps.

    Which is cool, because that should be your final goal: “We have improved so much that any improvements we could make right now would offer minimal incremental improvement for a significant cost.” At that point, your journey isn’t done, but you’re able to sit and take a rest, consolidate gains and assess future possibilities.

    And until you hit that point, be excited that every iteration of DevOps is improving responsiveness and taking you closer to your goal.

    Shameless plug: Read about my mothers’ odyssey here.

    — Don Macvittie

  • Overcoming the Awkward Teen Years of DevOps Adoption with Process-Centric IT

    Overcoming the Awkward Teen Years of DevOps Adoption with Process-Centric IT

    DevOps adoption is all over the map. Just last year, xMatters and Atlassian surveyed more than 1,000 companies on their DevOps maturity and found only 65 percent were getting the benefits from their DevOps initiative that they expected. Sixty-six percent described their maturity level at or below intermediate. And another 1,000 organizations were excluded from the survey because they didn’t have a DevOps initiative at all!

    With so much misalignment and insecurity, you might say that organizations are going through their awkward teen years. While many businesses recognize the importance of DevOps and agile methodologies, most are still struggling to truly embrace them, and therefore reap the real benefits. So what’s holding us up? The answer is people issues. Gartner recently surveyed organizations about their biggest barriers to DevOps adoption, and resistance to change was No. 1.

    Becoming Process-Centric

    It’s a complex challenge, but it does have a solution. The best way to enable continuous delivery while supporting legacy initiatives such as major incident and IT service management is to ensure your IT teams are process-centric. This entails mapping out the business processes required to achieve IT objectives and identifying the data, tools and people needed to optimize existing workflows while driving real change. If you’re not sure where to start, here’s how you can get started.

    Map Out Essential Processes

    IT teams frequently make the mistake of buying a checklist of tools they believe are necessary, but this can make it difficult to know where to start when evolving IT to support continuous delivery. Without a business process strategy in place, it’s virtually impossible to integrate your tools and optimize collaboration between teams.

    Enable IT to be a driver in achieving business goals by clearly defining your business objectives and the activities that directly support them, as well as managed entities and available response types. For instance, common business objectives include increasing the frequency of code releases, reducing the number and severity of major incidents, minimizing lead time for product updates and improving SLA standards of uptime.

    Identify and Connect Your Process Ecosystem

    After mapping out your business processes, you’ll need a connected ecosystem of data, tools, people and teams to drive them forward. This ecosystem is possible only if you understand the different types of contextual data you need for each managed process, from monitoring insights to system logs to stakeholder communications.

    Next, choose the tools to manage the processes and data flow. For instance, application performance monitoring and management, ChatOps and issue tracking are all common tool types. Then, pinpoint the people (or teams) that need to be involved in each type of process so that you can keep the right people informed—no more, no less.

    Finally, you should ensure that your teams within development, operations and support have an efficient and streamlined way to collaborate so that processes always advance to completion.

    Operationalize Steps for Collaboration and Resolution

    Now let’s get more specific. What are the steps required to facilitate collaboration and drive resolution? By defining these steps, you can optimize and effectively templatize processes that can be reused, thereby improving both consistency and efficiency each time a recognizable  incident comes into play.

    For each process, start by outlining the tasks necessary to resolve the issue, then detail the tools needed and the personnel or teams that should be involved. Repeat this for all of your processes to define the necessary technology investments.

    Automate and Curate Manual Work

    Operationalizing processes improves efficiency to a certain degree, but you can go a step further to really maximize the benefits. This is where you can leverage both automation and curation of manual work. For each managed process, drill down at the task level to determine whether you can either fully automate or, if human intervention is needed, efficiently curate work.

    For instance, routine tasks that have a defined set of triggers and can use software-driven logic to determine and execute on next steps can be fully automated, whereas tasks that have a defined set of triggers but require that human intervention determine which next steps should be curated. There are, of course, different levels of curation and automation based on associated triggers and response types, so you’ll need to gauge these and plan accordingly.

    Extract and Archive Contextual Information

    It’s important to maintain a repository of information on your business processes and how they are handled. This kind of data gives you complete visibility into issues as they progress, and ensure you’re taking consistent, proven responses to similar situations when they arise in the future. Some stakeholders will, of course, also need access to this information.

    The way to maintain this repository is to understand the unstructured data (such as FYI communications) versus structured data types (such as ChatOps) managed within each process. Once these are identified, you can map the unstructured data into structured data. The rule of thumb for aligning stakeholders is that the business and customers require data from structured sources; they’re looking for the information concerned with status and real business impact.

    In contrast, subject matter experts will often rely on unstructured data. They benefit more from the in-depth insights from system and application logs, performance metrics, and other essential data points to help them assess, resolve and manage situations.

    In Conclusion

    The journey to becoming process-centric may seem daunting, but there is a proven approach that can guide you toward the dream of becoming a mature DevOps organization. Figure out which processes you can automate, which require human intervention, and be sure to let your teams work within the systems they know and trust to ease the resistance to change.

    One persistent danger is that multiple systems can create silos of data that stand in the way of collaborative work. A process-centric IT organization with integrated systems can help move data to enable collaboration, more informed decisions and better outcomes. And nothing takes the awkwardness out of a teenager like better outcomes.

    — Kristin Apgar

  • Enthusiasm for DevOps Greater Than Actual Adoption, Survey Shows

    Enthusiasm for DevOps Greater Than Actual Adoption, Survey Shows

    When it comes to DevOps practices, adoption continues to lag intention by quite a bit.

    GitLab recently surveyed some 5,300 software developers and engineers from mostly small and medium businesses around the world. The survey examined overall attitudes and perceptions around the state of DevOps, with a particular focus on uncovering any disparities that might exist between developers and IT management.

    The responses showed that many organizations are sold on the idea of DevOps, especially those who have implemented it. Sixty-five percent of the developers polled felt that using a DevOps workflow would save development time. An even higher 81 percent of managers shared that same sentiment.

    Organizations with an integrated DevOps strategy reported a high correlation between DevOps practices and overall team productivity. Development teams that deploy code on demand and spent more than half their time on new projects, for instance, had twice the rate of DevOps adoption compared to lower-performing teams. Higher-performing teams also generally considered automation of the software development life cycle a top priority and had access to better tools.

    Yet, the number of organizations in the survey that have actually implemented DevOps practices was far smaller than the otherwise enthusiastic support for it would suggest. In fact, only 23 percent of the respondents in the survey identified their team’s methodology as following a pure DevOps model. Thirty-five percent described their DevOps culture as being somewhat established.

    The low adoption rates are somewhat at odds with Forrester Research’s prediction about 2018 being the “Year of Enterprise DevOps” and may reflect the global nature of the survey base and the fact that many respondents were SMBs. Forrester found DevOps adoption to be around 50 percent when it conducted a survey of its own of 237 DevOps pros last year.

    GitLab’s survey found that while developers view DevOps as critical to software development life cycle, many have not implemented a DevOps workflow. Similarly, while over 95 percent of the survey respondents placed a high value on collaboration and 81 percent felt that such collaboration was easy to achieve, 25 percent said they did not have enough visibility into operations, security and production. And 42 percent reported unclear directions as one of their biggest challenges to getting work done.

    Culture continues to be a big roadblock. “It’s hard to get Dev and Ops to work together in a cross-functional way,” said Mark Pundsack, head of product at GitLab. “That challenge can be exacerbated by tooling. Disjointed toolchains lead to disconnected processes and barriers to communication that get in the way of working together.” Many developers in the survey reported using at least five tools to get their job done.

    Nearly 6 in 10 of the survey respondents (58 percent) pointed to ingrained practices as their biggest roadblock to adopting new tools and practices, while 50 percent blamed an inherent resistance to change.

    Interestingly, remote employees tended to have a more favorable outlook on how things were going with DevOps, with 67 percent saying they had good visibility into what others in the organization were doing compared to 57 percent of on-premises teams.

    “DevOps culture is clearly important to achieving high performance,” Pundsack said. “For managers … the survey identified the top challenge in getting work done was unclear direction and managers should be able to play a role in fixing that.”

    The apparent gap that exists between intent and adoption was not the only surprise in the survey, Pundsack said. Also unexpected was the extent of the discrepancy between how executives think their teams are operating, and what developers are actually saying. When asked how often they deployed code, 47 percent of managers were under the impression their organizations were deploying multiple times a day in contrast to the substantially smaller 39 percent of developers who said the same thing.

    That one area aside, though, developers and IT manager seemed better aligned on other issues in the Gitab survey. For example, more than three-quarters of both developers and managers feel they are set up to succeed and about one-third of them felt that they deadlines they have to deal with are fair.

    GitLab’s survey showed that most organizations expect to invest in continuous integration and continuous deployment tools in 2018, with nearly half strongly agreeing that CI can help speed up the development process.

    “CI can help alleviate blockers in the development cycle such as removing the manual process to verify code before deploying,” thereby allowing development teams to have a faster and more effective feedback cycle, Pundsack said.

    — Jai Vijayan

  • The ‘Mad Men’ Approach to Pitching DevOps

    The ‘Mad Men’ Approach to Pitching DevOps

    It’s been said that the mark of a good salesman is having the ability to sell ice to an Eskimo. And, if you’re familiar with the 1960s-era T.V. hit “Mad Men,” you know that ad exec Don Draper could do just that. His character was debonair, brash and unapologetic—but one hell of a businessman.

    So, what does a smoke-filled, Madison Avenue ad agency have to do with DevOps? Well, if you’re in the market of adopting (and selling) the methodology to the powers that be, the parallels are abundant.

    Before we dive into those similarities, let’s tackle some fundamentals of the DevOps movement, as well as the benefits and value of the agile-inspired approach. DevOps focuses on rapid IT service delivery through the adoption of agile, lean practices with an emphasis on people and company culture. The collaborative practice utilizes automation tools to bridge Dev and Ops teams together throughout the entire service life cycle, from design to the development process to production support.

    Related Content:

    DevOps: The Innovation Power Couple

    Executive Buy-in May Be Preventing DevOps Success

    While that’s a broad definition of DevOps, the specific benefits are vast: Faster software releases with fewer defects; increased operational efficiency; and improved scalability, security and compliance (not to mention a substantial savings in time, money and resources). By practicing DevOps, you also attract a top-notch, hungry talent pool, as well as a different generation and brand of customer.

    For instance, let’s compare TransUnion, a 50-year-old company, versus Credit Karma, a 10-year-old company. In this day and age, folks in their 20s and 30s manage their finances differently than baby boomers—and need an agile, modern and DevOps-forward company that can operate like a startup on an enterprise level (granted, Credit Karma consumes data from TransUnion and other reporting bureaus). For years, we only saw our credit report when we applied for a loan or mortgage. Enter a smartphone app that enables consumers to view their credit report on-demand and the game changes. The TransUnions of the world see this and realize they, too, need to pivot and adjust to their market. Catch my drift?

    With that said, let’s get back to our “Mad Men” DevOps scenario. One of Don Draper’s more notable quotes was, “Change is neither bad or good; it simply is.” You often hear a similar phrase of “adapt or die” in the tech world, and this is particularly true for DevOps adoption.

    So, how do you sell this critical undertaking to the suits in the boardroom? To start, let’s look at three key components of any effective ad campaign pitch: the support of your team, a ton of preparation and a killer presentation.

    Don’t Go It Alone

    There are mixed opinions on whether DevOps adoption is a top-down or a bottom-up initiative, but I’m from the school of thought that it’s both. The key to an effective DevOps approach is not only getting buy-in from leadership, but also getting your Dev and Ops teams to collaborate on a common goal (such as agility or security) and to be willing to adapt to change.

    Think of your colleagues as your creative department in an agency setting: Without their feedback and support, your pitch is likely to fail (and you’ll become the heavily ostracized, needle-nosed “Pete Campbell” of the office).

    Some advice? Become a DevOps evangelist and seek out department innovators to help spread your message. Start small and organize a lunch-and-learn. But, most of all, get people excited and ask for constructive criticism.

    Start with the ‘Why’

    When formulating a business case for DevOps, the most important question to ask is, “Why?” Put yourself in the c-suite’s shoes, understand their management and company goals and find ways to align your strategy with those.

    For example, maybe your CIO is concerned by the cost of application delivery. Work to calculate the cost of an application by estimating staffing costs, labor hours, number of deployments/releases and the potential cost of a production failure—and how practicing DevOps would reduce that costly downtime.

    You’re the ad executive making the pitch—the Don Draper of DevOps, if you will. If you can’t prove its value and make the room as excited about DevOps as you are, you’ll be leaving the boardroom with your tail between your legs.

    Speak Their Language

    Most management doesn’t care about speeds and feeds, so tailor your message according to your audience. While tech folks care about features, non-technical people are excited about benefits, particularly how they outweigh the costs. Consider advantages like faster release times, attracting new customers and creating fewer unplanned outages.

    It’s important to think of these business executives as the ad agency’s client. And, while the concept of DevOps won’t fit into an “elevator pitch” format, try to keep the meeting as brief as possible (providing lunch doesn’t hurt either!). Don’t gloss over
    fundamentals, but ask questions to gauge your audience’s knowledge and adapt your content to further their understanding.

    And, most importantly, keep the jargon to a minimum.

    Finally, I’d be remiss if I didn’t mention one final piece of pitch advice from our resident ad man: “Make it simple, but significant.”

    — Tim Curless

  • Cuba Embraces DevOps, Despite Infrastructure Challenges

    Cuba Embraces DevOps, Despite Infrastructure Challenges

    A few weeks ago I had the pleasure of speaking at the second DevOpsDays event in Cuba alongside some great technologists from across the United States, Europe and Latin America. The conference was held in a beautiful hotel in Varadero overlooking a marina right by the beach. Varadero is approximately two hours by car from Havana.

    The first thing I noticed is that Cuba is full of anachronisms. This became evident as soon as I walked out of Havana Airport and realized that the whole “they have some old cars” thing was real. It was fascinating to see that every single car was pre-1950s, some perfectly maintained with great paint jobs and others in worse condition yet still capable of doing their core job as a mode of transport.

    Talking technology in Cuba was eye-opening, to say the least. Do not expect to have 3G or 4G data on your cellphone. Do not expect to have WiFi in most hotels (you can purchase prepaid internet credit, but the speed will be slower than what you are used to) and definitely do not expect to have WiFi in a private home. These are luxuries.

    But here’s the surprising part: There are companies in Cuba with fully automated CI/CD pipelines achieving 10 to 12 deployments per day and solving real problems, such as the team working under Anesto del Toro at Datys. Cuba even has its very own Docker Captain, who gave a superb demonstration on the value of Docker in front of the DevOpsDays audience.

    Now let me remind you, these guys are not working with stable internet connections and they manage to get the job done on a daily basis.

    Why am I Rambling on About Cuba?

    Engineering is about solving problems. No matter how big or small, it’s about looking at a problem and finding the solution. Now, this is part of Cuban life. If something is broken, they don’t throw it in the trash and buy a new one; they fix it. Their 80-year-old car breaks down two hours outside of town? They get out of the car to fix it and—take my word for this—their friends, family and neighbors will come outside to fix the problem, too. This creates a mindset of solving the problem at hand without fail. This is easily demonstrated when you talk to Cubans about software development: They won’t say they are a Python engineer, a Java engineer or any other choice of language—they are software engineers who understand how development works as a whole. They will use the language required to get the job done to the highest standard.

    Like everywhere else in the world, there were huge differences in levels of DevOps adoption between the various organizations in the country. In contrast to the companies mentioned earlier, there also are organizations that have only just heard of these methodologies or are now considering setting up their first CI pipelines. Like many of us, they are still figuring out how to solve their technical debt and modernize their IT Infrastructure, but the key point is that the stakeholders, C-level executives, junior engineers and everyone else in between want to learn. They are open-minded to the principles of DevOps. Every person in the room at DevOpsDays Cuba was focused and listening to what we had to say. This excited me as a speaker and everyone else in attendance. We could see people who really did want to change and transform the cultures within their technology teams and overall businesses to start adopting these modern and proven practices.

    The journey ahead is a long one. The infrastructure challenges remain in place and there is much to be learned, but it was great to see such positive energy and eagerness to adapt. I want to thank everyone who attended DevOpsDays Cuba for making it such an amazing experience. An even bigger thanks to the organizers Enrique Carbonell, Rudy Gevaert, Yadier Perdemo, Manuel Oliver, Mike Rosado, Manuel Morejon and anyone I’ve missed. The event couldn’t have been better and it was a genuine pleasure to visit Cuba, I hope to return soon and reconnect with as many of you as possible!

    About the Author / Conor Delanbanque

    conordelanbanque

    Conor Delanbanque has been recruiting and leading recruitment teams in the DevOps space for the past few years. As well as being exclusively responsible for growing some of the most innovative DevOps & SRE teams in the US and Europe as an external consultant and recruiting partner, Conor also founded the Future of DevOps Thought Leaders Debate, sponsors DockerNYC Meetup on a regular basis and co-hosts ServerlessNYC. You can tweet him at @ConorDevOps, find him on LinkedIn or at events, expos and writing articles on devopsy.kinsta.cloud.

  • 3 Practical Steps to Employing DevOps

    3 Practical Steps to Employing DevOps

    Everyone seems to be talking about DevOps but, if you are new to it, it might all seem a little overwhelming. One of the hardest things about DevOps is knowing where to begin. This is because to “do DevOps” its seems you have to suddenly start using a lot of new processes and tools at once.

    For an organization that doesn’t use DevOps today, the adoption of this three-step method will promise a generally clean approach.

    Source: https://ukcloud.pro/

    Step 1: Creating the Application Pipeline

    Regardless of the type of application, the pipeline looks—at a distance—very similar. The goal is to weave application releases into a new coordinated process that looks something like this:

    1. The developer makes changes locally to their laptop/PC/Mac, and upon completion (including testing, etc.) issues a Pull Request.
    2. Code review kicks in, the developer changes are reviewed and accepted and a new release can be created.
    3. Someone, or the system, runs a procedure to create a release artifact, which could be a Java JAR file, a Docker file or any other kind of unit of deployment.
    4. Someone, or the system, copies the artifact to the web or application servers and restarts the instances.
    5. Database migrations/updates may be additionally applied, although the database is often left outside of the application release process.

    This process evolves into an automated application-only continuous integration and continuous deployment (CI/CD) pipeline by using a toolset to automate the process as shown in the diagram below:

    Source: https://ukcloud.pro/

    A Typical CI/CD Pipeline

     

    However, be aware that this isn’t ideal (yet), because at this point the application alone is being released (injected) into existing environments.

    Why is this potentially an issue? If the developer has altered the local environment as well as the application but these local environment changes are not part of the release, then they’re not in version control. And, if they are not applied at the same time as the application, then the application will break and the common argument occurs: “Well, it works on my machine!” The solution is for application and infrastructure releases to be synced—and hence steps 2 and 3.

    Step 2: Creating the Infrastructure Pipeline

    Ideally, the infrastructure team has learned from the developer team’s DevOps and CI/CD pipeline journey and can expand and adapt it for the infrastructure (which increasingly is a public cloud).

    There are some differences with the infrastructure pipeline, specifically around units of deployment that are now the infrastructure layers in environments, the things that surround an application such as the DNS, load balancers, the virtual machines and/or containers, databases and a plethora of other complex and interconnected components.

    The big difference here is that the infrastructure is no longer described in a Visio diagram: it is brought to life in code, in a configuration file, in version control—this is infrastructure as code (IAC).

    Before this, a load balancer was described in Visio diagrams, Word documents and Excel spreadsheets of IPs and configurations. This is now swapped to describe everything about the load balancer in a configuration file.

    Here’s an example AWS CloudFormation Configuration for a Load Balancer:

    Whenever this file is changed in Version Control, such as changing the subnets a load balancer can point to, then the automation engine can update an existing infrastructure environment to reflect that one change, and any dependencies that change.

    It also means that you can apply this template to multiple environments just by changing the environment name from staging to production, for example, and be very confident that all environments are consistent, from the developer laptop to production.

    It is also possible to make the templates dynamic to change their behavior according to the environment, so in production the environment will scale out across three datacenters, but on a developer’s laptop it will use a local VirtualBox single-system.

    Step 3: Creating the Full-Stack Pipeline

    The goal of a full-stack pipeline is to ensure that the application and infrastructure changes over time are in sync, both in version control and the release deployments across each pipeline stage. And a developer should never say, “It worked on my laptop!” when a release fails in production.

    The popular CI/CD tools can now automate the full stack because everything is programmable. This means everything can be captured in version control, and the same configuration can use dynamic input parameters to build an environment on a developer’s laptop, or a QA system in the cloud or updates to production.

    Imagine a developer makes an application change that also requires a change to the database, the web instance scaling configuration and the DNS. All of these changes are captured in one version control branch and the developer builds a system on their laptop from this branch, and tests it.

    This is what platform-as-a-service systems can do. By adding an environment configuration file inside the same code base as your application, you can ensure that you have bound your application to the infrastructure. 

    AWS Elastic Beanstalk Example

    This is the target end goal, though it takes a lot of practice, and learning, to get there. It can be very satisfying to watch a build and a deployment, seeing the automation use tags and dynamic configurations to build, or update, the target environment with application and infrastructure changes.

    About the Author / Sarah Lahav

    Sarah Lahav is CEO of SysAid Technologies. As the company’s first employee, Sarah Lahav has remained the vital link between SysAid Technologies and its customers since 2003. She is the current CEO and former VP of Customer Relations at SysAid – two positions that have fueled her passion in customer service. Connect with her on LinkedIn and Twitter.

     

     

  • SMEs Can Benefit from DevOps, Too

    SMEs Can Benefit from DevOps, Too

    The DevOps approach has several clear-cut benefits with the value centered in several key business areas: improved market agility, increased quality and revised culture of cooperation and effectiveness in staff operations. By promoting and implementing a DevOps culture in your SME’s business, Dev and Ops teams align much closer together and can better share in-between knowledge. This lets you create products more fluidly and increase deployment rates. The time for evaluating the business idea, development, testing and moving the finished product into the operations department is reduced dramatically. Quality margins improve, and this feeds back into the ability of your teams to continually fine-tune the products you offer.

    Businesses see a point in adopting DevOps only if it is directly contributing to the company’s increased effectiveness, productivity and, of course, profitability. The only way that it is possible for small and medium enterprises (SMEs) is when their IT and DevOps teams are working in sync and streamlining the provision of tech solutions that solve the business needs. And only a successful and timely DevOps adoption inside your organization will help your company beat competitors and stay afloat as the development across the industry speeds up.

    In the last years, we’ve seen a tremendous application delivery shift in businesses. We’ve moved away from the old ways of having large-scale system implementations based on one single project and its continued maintenance. SMEs now perceive application delivery as a continuous evolution. DevOps plays a leading role, as this software engineering trend ensures that such a major shift is possible. It brings all of the different parts of the enterprise together: business, development and operations teams collaborate on a different, more in-depth level with a goal of automating processes. This helps eliminate the usual constraints and takes the time-to-market issues off the table.

    In the latest ECS-Digital research on adopting DevOps in businesses, 57 percent of SMEs have partially implemented DevOps practices in their daily routine. The key benefit of DevOps for them is improved inter-departmental collaboration. But for the 43 percent that haven’t yet adopted DevOps, the collaboration issues are among the last priorities on the list.

    Step-by-Step Guide to a High-Level DevOps Life Cycle

    According to IBM Cloud Director, the end goal of a relevant DevOps practice is to cut the development time and improve enterprise’s efficiency. A growing business has to start from the “business needs” of the company and go down the road to make it come to life. The goal of adopting DevOps in your company is to push your business needs into production at a quicker pace more reliably. The goal in any DevOps practice is to cut the time and increase the efficiency of processes. You need to move from the “business need” to the “it’s live!” stage.

    Business Needs are a DevOps Priority

    But does your business have to get involved? Of course, your SME leadership focuses on the “business needs” of your company. But when we look at organizations that have implemented proper DevOps practices, the internal structure of the company shifts to focus on delivering great business results across the whole life cycle of your product/services offering.

    DevOps also ensures that employees have the ability to correct their work direction during the whole lifetime of a project. Things and goals tend to change, competitors may roll out some features that may make some of your project’s parts trivial, and all of this makes the need to adjust your project accordingly. This is easily done when your business need is close to both the Development and Operations teams that are able to steer and drive this alignment of goals.

    Have a look at the infographic below that clearly shows how a DevOps delivery cycle looks like:

    The Clash Inside Organizations

    Measuring the impact of DevOps on the things that matter to business is vital. Most SMEs are experimenting with DevOps, and there are some within the company who want to prevent DevOps adoption. The culture within enterprises is shifting too drastically and dramatically, although the effects are mostly positive.

    Such a shift is impacting all operations, with software development impacted the most. SMEs have it easier to change and adapt compared to larger businesses, and this lets them move the workplace culture a step ahead of their larger counterparts.

    If we look at business, operations and developer teams from a historical point of view, it was never a goal to establish inter-connection between them. The teams started cooperating only when it was absolutely necessary to get the other team’s input. SMEs are still faced with such a separation, as most responsibilities are set in stone for each team and the individual employee. All business units are used to working in their closed-in niche, and there is a lack of will to leave the comfort zone and act outside the predefined roles. Such actions in the past could have been viewed negatively.

    While most businesses that want to implement DevOps have employees who want the business to prosper, it can be difficult to force people to act outside their duties. However, to reach the end goals of any business—namely, ensuring fast and quality product delivery—and solve issues on the go, people must interconnect their duties and reach outside their business unit. With proper DevOps application, such collaboration can be smooth and result in the improvement of cross-functions.

    DevOps Represents Change in Internal Business Structures

    Many SMEs are faced with internal structural issues that limit the company’s prospects: Engineers are not willing to be on-call, the Ops team has a negative attitude toward those who write code and executives are slow to embrace automation. Organizations must overcome the culture war to be able to approach the agility and productivity gained by a DevOps model. The faster they can get there, the faster these organizations can take the competitive edge away from traditional enterprises.

    DevOps culture looks very different from organization to organization. However, regardless of the business implementing a DevOps approach, the potential benefits are the same. From faster deployments to increased efficiency and cultural changes toward experimentation and away from rigid planning, a DevOps culture has the ability to transform an organization completely. Wholeheartedly adopting a DevOps culture has real implications on how well a business is positioned to take on the market. With many industries facing uncertainty and a host of upstarts disrupting the status quo, shifting to a DevOps culture can be an important weapon in repositioning your business.

    Empathy is the Core of DevOps Adoption

    One of the foundational ideas behind DevOps is mutual empathy. Having empathy from operations toward developers and vice versa, as well as empathy in other business-related and non-technical company units, remains vital. It’s not about patting your colleague on a shoulder. We are talking about the moral mandate of a developer who just creates their part of the software and doesn’t care about how it can be deployed in production. The goal is to push employees to think outside of their small task, and to take into account the outcome of their work: Is the developed app secure? How hard is it to deploy it? Is it easy to keep it running? etc. If those questions are not accounted for, the developer’s colleagues on the Ops side will pay the price if something goes wrong past the release.

    By ensuring that the SME has empathy for each other at its core, businesses will deliver better products/services. And doing just that is what DevOps aims to bring to companies. Until this idea is ingrained, DevOps will face a cultural war of sorts.

    Your Most Valuable DevOps Resource

    By considering to adopt the DevOps approach to running your SME, you can better rethink the ways your organization operates—how it deploys its teams across the enterprise and how often it addresses structural problems that appear over time. Now you can lay out a new foundation for your SME based on the culture of cooperation and experimentation. With proper guidance in the application of DevOps culture, you can address the waste of time, human resources and money in your business.

    Becoming a DevOps organization is no easy task and taking up on such a challenge requires faith that changing the existing processes will bring its benefits. Reworking and optimizing organizations is the new norm, regardless of their size, industry, and goals. The faith in DevOps culture is driven by the firm and quantifiable statistics, but the intangible benefits to corporate culture are just as compelling. Many businesses are looking at implementing DevOps, and even more, SMEs are in the active process of its application. When your company is delivering quality ahead of time, there is a strong chance your competitors will be left behind as you are getting the bigger piece of the pie.

    Key Takeaways

    • To stay current, businesses need to adapt to an ever-changing environment, respond to competitors and stay on top of the innovation cycle, increasing customer value via responsiveness to change.
    • Increased service quality depends on both the availability of the service and being able to restore the service to an error-free state. Thanks to fast feedback loops and high release velocity, service breakdowns can be removed much more quickly than in the past.
    • DevOps are built on the sound principle of waste reduction such wait times and process overhead due to continuous improvement. This helps to improve agility and has a positive impact on costs.
    • Fostering continuous learning and improving culture through efficient principles is what DevOps is all about. In a fast-paced, unpredictable environment, non-stop improvement is paramount for sustaining your competitive advantage. It is also important for attracting exceptional talent and keeping employee satisfaction at a high level.

    About the Author / Stephan Pushkarev

    Stepan Pushkarev is the Head of DevOps Practice at Squadex.com and CTO at Hydrosphere.io. Co-founded and managed engineering teams for eCommerce, IoT and Ad-tech companies. He is responsible for the full products stack: math models, infrastructure & operations, enterprise applications as well as recruiting, establishing engineering culture and delivery processes. Stepan combines strong technical and managerial skills, and entrepreneurial spirit. Connect with him on LinkedIn.