devopsy.kinsta.cloud

Tag: devops culture

  • Embracing a DevOps Culture, Part 1

    Embracing a DevOps Culture, Part 1

    DevOps is popular right now. So it should come as no surprise that organizations across all industries are eager to embrace the “DevOps culture.” However, unlike ITIL, implementing DevOps into an organization does not happen overnight.

    Compared to companies such as Netflix or Amazon, most organizations do not have thousands of application deployments per day. In fact, it’s usually newer companies that are able to fully embrace DevOps, since all of their business operations rely on IT already.

    DevOps Philosophy > Procedure

    There are many articles out there that try to define DevOps, but DevOps is more of a philosophy than a procedure. If you polled 100 organizations on their experiences implementing a DevOps strategy within their existing business processes, you’d likely get 100 different answers.

    An organization’s journey toward DevOps is usually unique, since there are so many different factors that influence a DevOps integration. These include the size and age of the company, what industry it’s in (banking/finance, retail, health care, e-commerce, education, public services), how sophisticated its technology is, the nature of its IT (data center or SaaS), organizational structure (siloed or integrated), development methodology (agile or waterfall), the nature of its mission-critical applications (Web 2.0, virtualized, client-server … ) and more. For most companies that exist outside of the startup ecosystem and rely on Web 2.0 and agile application development, Dev and Ops just don’t get along.

    pic01

    Dev vs. Ops

    Trying to collaborate with Dev and Ops can feel like trying to mix oil and vinegar if the goals of each department are not aligned. As a result, IT’s ability to deliver maximum business value is greatly reduced. To efficiently drive the business forward, Dev and Ops must get along.

    Most often, the conflict between Dev and Ops is because the focus of one department is at odds with the focus of the other, which creates tension when it comes time to collaborate with one another. While Development is focused on continuously delivering new products and/or features to meet business needs, IT Operations strives to preserve the availability and the stability of IT services and the IT cost-efficiency.

    pic02

    DevOps Can’t Be Limited by Tools

    First, for a seamless collaboration to occur between Dev and Ops, both departments must use compatible tools. Mismatched toolsets create bottlenecks, misunderstanding and miscommunications, which result in so much wasted time that the implementation process ends up hurting the business.

    Next, processes must align; compatible toolsets with conflicting processes are useless. For example, it’s not unusual to find the service desk is using a ticketing system which is separate from the application development tools used to manage product defects and enhancements.

    Developers tend to rely on toolsets that are optimized for rapid development to provide fast feedback on code changes, to automate build creation and for application release deployments. In addition, the Dev team may be unaware of the runtime environment, which makes it difficult to adjust the code accordingly, whereas Operations uses solutions on the target runtime environment, where stability and performance outstrip flexibility requirements.

    Since the integration process is unique to each organization, it’s key to find tools that are the right fit for your new processes and employees. Just because a team uses the latest application release automation tools to consistently drive repeatable deployments of application into production, does not mean they have adopted DevOps.

    In fact, version control, application release automation and application auto-discovery of business transactions are all tools that help developers meet their objectives, but may not address the other portion of the equation: Operations.

    At the end of the day, one of the most important decisions is choosing the right leadership team across your business—from your C-level executive team to the heads of your Dev and Ops teams. The integration process for DevOps can be difficult; to merge two separate departments and processes together to drive collaboration, both the Dev and Ops team need leaders with clear vision of the bigger picture and what’s needed from everyone to drive the company’s forward.

    About the Author/Vincent Geffray

    vinnyVincent Geffray is Senior Director of Product Marketing at Everbridge with focus on IT Service Alerting & Communications Automation and IoT.

    He has more than 14 years of experience in the information technology business, designing, promoting and selling Enterprise IT Operations Management solutions, including Critical Communications, Application Performance Management, IT Process and Workload Automation. He also has international experience, as he started his career in Europe. Vincent holds a Master of Science (Mechanical Engineering and Computer Science) and executive certificates from the MIT – Sloan School of Management.

    Vincent’s LinkedIn: www.linkedin.com/in/vgeffray

    Vincent’s Twitter: @vgeffray

  • Flash Mob Inflection: Rugged DevOps Revolution

    Flash Mob Inflection: Rugged DevOps Revolution

    Truthfully, I was never a huge fan of the HBO series “The Sopranos.” It’s not that it wasn’t entertaining; I just didn’t agree with the “best ever” label that so many espoused during the show’s halcyon days.

    This had something to do with living in Hoboken, N.J., at the time and feeling the show was a heavily glamorized caricature of the real-life Mafioso I still perceived to be in my midst. More specifically, it’s hard for anything mob-related to stand up next to “Goodfellas” and “The Godfather”—among my favorite films, ever.

    Either way, I currently find myself identifying with the series’ defining sentiment (copped directly from The Godfather, but hammered home as The Sopranos main theme): “Just when I thought I was out … they pull me back in.”

    It wasn’t that I assumed that I’d never delve back into the domain of IT security after transitioning into the DevOps market last year; leveraging DevOps methodologies to improve security, policy compliance and related workflows stands as a core element of the overall movement.

    But, in recent months and weeks it has become increasingly obvious that the security facet of the larger DevOps revolution appears poised for explosion as the buzz around emerging best practices, business models and solutions providers grows from a low hum into a steady roar.

    After spending a few days talking DevOps security with Derek Weeks of Sonatype at CA World ’15 (we were booth neighbors and dinner mates) and giving more consideration to his company’s angle on securing the systems development life cycle (SDLC) supply chain, the internal gears really got spinning.

    Regardless of whether you buy into Sonatype’s security-heavy approach, the concept of aggressively and proactively addressing security across the DevOps spectrum makes infinite sense. The ultimate downfall of applications security has always been the challenge of securing all the underlying layers of code (and today, microservices), especially as applications are assembled using heavier doses of shared, open source componentry.

    As further evidence, nearly every major solutions vendor focused on the DevOps space—whether oriented toward the vibrant application performance management (APM), configuration management and continuous testing segments, among many others—seems to have launched some initiative aimed at integrating security into their products.

    The rise of security capabilities adjacent to—and supporting inclusion into—the DevOps world, such as container giant Docker’s Content Trust initiative, along with the advancement of related startups including Twistlock, Scalock and StackRoxs, offers more proof of this growing momentum. And that’s only the container security piece of the puzzle.

    Of course, there are also a number of emerging startups aimed at addressing the DevOps security opportunity, backed by well-known venture capitalists. A shortlist might include providers such as Immunio, Prevoty and UpGuard (formerly known as ScriptRock, which recently rebranded itself under the guise of a “DevOps security” provider), and we’re sure to see many more. And don’t forget the growing emphasis on DevOps security among established security industry stalwarts such as CyberArk, Snort and Tripwire, among others.

    For a comprehensive list of the various types of DevOps security best practices and tools that we should expect to see gain wider adoption, this October 2015 blog by noted security analyst Adrian Lane of Securosis serves as a basic framework. Each of the areas of focus that he cites clearly offers significant opportunity for both new and existing methodologies.

    Finally, one need look no further than this year’s RSA Security Conference, to be held in San Francisco at this end of this month, as tacit proof of the continued growth of what people now varyingly refer to as DevSecOps or Rugged DevOps (I prefer the latter as it just sounds cooler).

    In addition to multiple conference sessions, notably a “DevOps Throwdown” between security industry veterans Caleb Sima, Chris Wysopal and Gary McGraw, there’s also the 2nd Annual DevOps Connect: Rugged DevOps Edition. If last year’s event is any indication (standing room only, venue literally at max capacity), this daylong DevOps security track at RSA will be an even more high-profile element of the entire week.

    Further, if DevOps security—or, at the very least, the growing focus on adjacent segments such as container security—isn’t the unofficial theme of this year’s entire RSA show, I’d be extremely surprised.

    Meanwhile (self-serving), my employer CA Technologies absolutely has a lot going on that complements and contributes to this growing DevOps Security market momentum.

    For all of those reasons, here I find myself again, drawn closer back into the security space that I’ve called home for roughly the last decade. I guess that’s just how it goes, as DevOps and security are inarguably two of the most significant trends in IT these days and inextricably linked at their respective cores.

    There are definitely worse fates out there. But, just when you think you’re out …

  • DevOps Brings IT Out of the Shadows

    DevOps Brings IT Out of the Shadows

    One of the biggest threats to organizations today is shadow IT—unsanctioned and unknown technologies and applications being employed by maverick users. Shadow IT represents a security risk for your company—the IT department can’t defend and protect technologies and assets it doesn’t know about—and should be eliminated. One of the best defenses against shadow IT is DevOps.

    When I worked in the trenches as a one-man IT department—part network admin, part tech support—there always were one or two individuals who knew enough to be dangerous. As frustrating as it was to deal with completely clueless users who didn’t know the difference between the computer and the monitor and weren’t even really sure where the power button was, those who knew enough to go rogue and reconfigure their devices or introduce new applications and services were a more existential problem for the organization. In today’s era of BYOD and cloud services, shadow IT is a scourge significantly greater than what I faced.

    Don’t get me wrong—I’ve also been on the other side of that equation and I understand the motivation that drives shadow IT. Users just want to get their jobs done, and the people in the trenches know better than anyone what the hurdles are and how to fix them. Requesting new technologies or capabilities from IT is a cumbersome and tedious process at many organizations, so in the name of expediency users just do what they need to do on their own.

    DevOps can help solve the shadow IT problem in a better and more sustainable way, though. There are two benefits that DevOps brings to the table that minimize the potential for shadow IT: More rapid development and empowering individuals.

    First, an IT organization that has embraced DevOps will be quicker to respond to requests from users. Replacing the traditional software development life cycle with a more agile and continuous pace of development means that feature requests can be incorporated much faster.

    Second, one of the cornerstones of DevOps is the underlying culture—the breaking down of silos and removal of barriers and bureaucratic nonsense that get in the way of efficient progress. Essentially, those rogue technologies and applications that comprise shadow IT in other organizations are simply a part of the larger DevOps whole in an organization that has embraced DevOps. There is even a term ascribed to users outside of traditional IT/developer roles who develop solutions: “citizen developers.”

    The 2015 State of Citizen Development Report explains in more detail what a citizen developer is: “Citizen Developers are empowered problem-solvers from the various lines of business who have the drive and determination to engage in app development even though they lack traditional coding skills.”

    That isn’t to suggest that in a DevOps world everyone can just go set up virtual servers, or store data on personal cloud services and that it’s OK. It just means that when users are given the tools and freedom to develop solutions that have the blessing of IT and the rest of the organization, they don’t need to function in the shadows.

    Embracing DevOps and the citizen developer movement enables IT to work in harmony with users to develop solutions that work rather than fighting against each other and ending up with shadow IT servers, applications and cloud services that IT isn’t even aware of. Organizations that are concerned about the impact of shadow IT should look at ways to harness the power rather than just trying to ban shadow IT completely.

  • Continuous is the Engine that Drives DevOps

    Continuous is the Engine that Drives DevOps

    It has been stated time and time (and time and time) again that DevOps is primarily a matter of shifting IT culture. The tools and practices that comprise DevOps play a secondary role. But that is only partially true: In reality, the culture shift revolves around continuity, and the applications and tools that fuel continuous delivery drive the DevOps engine.

    I alluded to this point in a post in early 2015. I stated, “Everything is continuous. Continuous development and continuous testing lead to continuous deployment and continuous delivery, which requires continuous support. Continuous monitoring produces continuous integration and continuous change. Continuous security results in continuous incident response … or vice versa. To top it off, all of the continuous activities continuously feed each other to drive more continuousness in some sort of DevOps Mobius strip of continuity.”

    That post last year was a bit tongue in cheek. I have since refined my position, however, and come to the conclusion that the hint of sarcasm was perhaps unwarranted. That continuous continuousness is the crux of the culture shift. It is the thing that separates DevOps from non-DevOps.

    On the Continuous Journey

    Speaking on the topic of continuous security, Andrew Storms, vice president of Security Services at New Context, explains, “Smaller incremental changes are always easier to handle than a large behemoth of a release that can include hundreds of changes. Try finding the single change in a monthly release that resulted in an unexpected security hole in your database configuration vs the release with only two changes that was just developed and released in the last few hours. Security practitioners cannot continue to rely on manual, human-controlled processes to defend against attacks. Automation is a requirement for the next evolutionary phase of security protection.”

    That sentiment extends beyond security to all of IT. When we talk about the culture shift in IT required for DevOps, we are generally talking about breaking down silos and removing the barriers between different teams. The goal of the culture shift is to shed tedious bureaucracy and red tape and empower employees to freely collaborate and cooperate to get things done. In other words, we want to eliminate barriers and roadblocks so productivity can be more continuous.

    Assuming the DevOps transformation begins at that level, it creates an environment of continuous collaboration which becomes continuous development. What follows is a natural evolution of continuity. Continuous development becomes continuous delivery, which requires continuous testing and continuous deployments, followed by continuous monitoring, which provides the metrics and feedback that take you back to the beginning of the loop.

    All of the “continuous” tools and solutions may seem to be part of the technologies and practices that come after the DevOps culture shift, and to some extent, that is true. However, they are also indispensable and inseparable from that DevOps culture shift because without all of the various gears meshing together smoothly—and continuously—what you’re left with is a more traditional approach to IT where everything comes to a halt.

    Is DevOps more of a cultural shift than a collection of tools? Absolutely. That culture shift revolves around continuity, though. Continuousness is the culture shift that drives DevOps.

  • Performance Testing: The Unexpected Missing Link in DevOps

    Performance Testing: The Unexpected Missing Link in DevOps

    It is no secret that DevOps and continuous delivery goes hand in hand in the enterprise, but how do processes such as performance testing fit in to the equation?

    Many enterprises still harbor the traditional way of thinking—that the QA and performance testing group is completely separate from the development group. A widely held myth is that each has different roles, responsibilities, backgrounds and areas of expertise. However, with DevOps gaining popularity in the enterprise, the distinct separation between testing, development and operations is no longer. In fact, to successfully implement performance testing, the once-siloed departments must work together.

    Creating a Culture for DevOps

    The most common purpose of DevOps is to have an automated pipeline of software and application deployment updates. An enterprise cannot implement DevOps unless all are on board, from the top down. To do this, there must be buy-in from not only the software engineers and technology buyers, but also the C-suite. This ensures DevOps processes and strategies are being implemented appropriately.

    However, it’s not just about getting the tools needed for DevOps; there must be a culture shift toward collaboration for it to be effective. That is when an enterprise gets the most from the shift to DevOps and becomes the most agile.

    Once DevOps is embraced, experts and power users can help facilitate how it is being used to drive maximum benefit and help the organization get more from it. The key way to determine and evaluate this maximum benefit is through continuously testing throughout the development process. While the first thought may be for “functional” testing (to ensure code operates without errors and to provide fast feedback to developers when things go wrong), no organization can afford to release applications that deliver slow user experiences, and so “performance” testing with fast feedback is equally critical. Continuous testing is only scalable and sustainable if it is automated.

    DevOps Makes Load Testing Easier

    A key benefit of DevOps is that automation makes everything—from implementation to functional and performance testing—faster and more predictable. Tool chains ensure that the “right things” are done with every code push. A concern commonly cited by those who have not yet implemented performance testing is that it is “too time consuming” and they will be unable to facilitate different tests at the rate they need to be done to be effective. But surprise! Organizations that already practice DevOps are in a better position to add performance testing to the mix, in a fully automated fashion. A solution like BlazeMeter takes just minutes to get API tests up and running, by just adding the HTTP transaction for specific pages or endpoints to test. Once set up, these tests will continuously run automatically and will notify the team when there are any problems or potential problem areas. When there are known surges in website traffic, more Uniform Resource Identifiers (URIs) can be added to the test, but this will not impact the autonomy of it.

    Another key function of DevOps is scalability through the enterprise, and scalability of user traffic is extremely important. While performance testing would still scale without DevOps, operating on the same principles makes each concept more relevant to the folks who are analyzing the outcome of both. The key is to integrate performance testing directly with an already existing continuous delivery or integration pipeline, such as Jenkins or CircleCI. Here, fast, small-scoped performance tests are able to run in parallel to ensure performance is as expected before promoting a build to the next stage. Tests run in staging or QA environments, such as IBM BlueMix or Chef, can also be automated and integrated.

    Performance testing is also important not just because of its easy integration into DevOps practices and how it fits into the CD pipeline, but the overall customer experience as well. A properly functioning webpage or mobile application is the connection between your brand and your target customer, and if it doesn’t load properly or in a timely manner, you may lose a customer to a competitor. Performance testing ensures the user doesn’t experience slowdowns or the dreaded downtime, which is often the result of a poorly functioning back-end system. Incorporating performance testing into workflows creates a centralized environment where all team members have what they need to design, run or analyze tests, while communicating quickly and clearly with each other and everybody in the enterprise.

    Performance testing and DevOps are not opposing forces; and performance tests run automatically within the tool chain save time, rather than consuming more. The reality is that during this age of rapid software delivery, testing is the glue that keeps the development process on track and high quality. Performance testing should be part of every software delivery workflow, and DevOps is allowing that to happen.

    About the Author/Michael Sage, Chief Evangelist

    unnamedMichael Sage brings a 15-year career of enterprise software pedigree and customer success to BlazeMeter. Prior to BlazeMeter, Michael (better known as “Sage”) was a solutions architect and consultant in software delivery and performance management. He has worked with industry-leading companies including Mercury Interactive, Hewlett-Packard and New Relic, helping teams implement integrated solutions that enhanced the performance and experience of their customers. A self-taught hacker and open source evangelist, Sage always has the pulse on the cultural zeitgeist inflected with a heathy dose of humor.

  • How DevOps Can Effect Culture Change to Improve Business

    How DevOps Can Effect Culture Change to Improve Business

    The rift between Dev and Ops teams has long been one of the main obstacles for organizations managing their IT capabilities. Overcoming it can be crucial for a successful business. In fact, every company should be able to achieve harmony by improving process automation, implementing better procedures and refining workflow regulations. This is where DevOps culture steps in.

    To be successful, your DevOps approach must include a detailed understanding of your culture and learned behaviors that will influence the changes you want to see in your organization.

    According to recent Gartner research, DevOps will only work when both Dev and Ops are willing to collaborate. They need to embrace change at a behavioral level to initiate and achieve culture change. If not, there is a 90 percent likelihood that any DevOps initiative will fail.

    In discussing the importance of communication in implementing DevOps know-how with Consultancy UK, Gartner’s research director Laurie Wurster explained: “With respect to culture, DevOps seeks to change the dynamics in which operations and development teams interact. Key to this change are the issues of trust, honesty and responsibility. In essence, the goal is to enable each organization to see the perspective of the other and to modify behavior accordingly, while motivating autonomy.”

    Theory vs. Practice

    In reality, the existing autonomy of the operations and development teams is one of the most common reasons for a possible failure of the DevOps approach. While the business culture of developers is founded on innovation and breaking the status quo, life in Operations can seem unthinkable without a procedure-based routine.

    Going further, these two teams can be pushed apart by their own executives. After all, handing out separate tasks and objectives without actually putting the Dev and Ops teams in a room together (even when working on the same project!) has been a traditional approach that dates back decades.

    Deadlines and Objectives

    With Dev and Ops each being unaware of the business value of the other, the departments end up sharing only two business factors: deadlines and objectives. This often leads to a blame game—explaining a delay or a failure seems much easier when you have someone else to blame and a team with an unknown value is always an easy target.

    Putting a stop to this poor practice by initiating cooperation and reminding both they are part of the same organization is the best way to improve efficiency and speed of innovation. IT managers must build bridges and encourage Dev and Ops to discover new ways to accomplish their shared objectives.

    DevOps for an Agile Reboot

    Modern business has realized that while Agile improves speed and service delivery, it may have skipped some very important aspects of culture change resulting in the birth of “fragile infrastructure.” The term is used to describe the damage that can be caused by Agile’s ‘shortcut policy,’ in which teams may compromise to meet their deadlines.

    Many see DevOps as the savior that comes just in time to influence business on a cultural level and unite with Agile toward excellence.

    One of DevOps’s flagmen, Mike Kavis, vice president and principal architect at Cloud Technology Partners and a Forbes contributor, points out that “the solution is for dev and ops to collaborate on the environment specs and together build the appropriate automation scripts that can provision environments with a single touch of a button without the need of additional configurations.”

    When implementing the DevOps approach, developers can be the toughest audience. They may remember all the arguments and rifts with operations, potentially caused by tentative coding leading to functionality issues within the environment—a destabilization every Operations team fears and detests. So, one question remains: How can you build this collaboration?

    Incentivize Accordingly

    As stated by Forrester analyst Kurt Bittner, IT companies of today are helping the cultural rift between dev and ops by incentivizing the teams to do different things—developers are prompted to deliver quickly, while operators are targeted to keep the services up and running.

    Encouraged to pull in opposite directions, it is only natural that the two business units end up facing a rift, making cooperation seem more illusion than reality.

    Because most companies set their priorities based in part on its incentives policy, it is important that those priorities agree with the company goals. In short, once you “go DevOps,” make sure your incentives policy is encouraging rather than hindering collaboration.

    Set Shared Goals

    DevOps supporters see DevOps as a cultural movement and a philosophy, rather than a framework or simply an approach.

    “DevOps is a mindset of moving away from fragile systems that take too long to deploy to reliable software that can be deployed quickly. DevOps requires great collaboration and teamwork, not just within IT, but also with management and product,” Kavis notes.

    Identifying a goal that can bridge the gap and make teams work together is a great way to initiate a change in a positive direction. As Bittner explains, “Part of that means measuring devs on stability, and part of that means measuring ops on innovation. But the best thing is to reward everybody on improving the customer experience.”

    A recent case study presented by Orbitz Worldwide’s senior software engineers Greg Burton and Ori Rawlings at the Velocity Conference neatly demonstrated how setting a common goal for Dev and Ops can bring actual results.

    The goal itself was simple but ambitious: to double the hotel search capacity across the whole website. While achieving it by working closely with operatives, the development team managed to get a hold of many issues plaguing the system on day to day.

    In fact, being a back-end developer himself, Burton defined the term “feature guilt”—the belief among developers that any time spent in aiding operations to resolve outstanding performance issues is lost and unproductive, so everything that does not involve new features must be completed quickly.

    Like many other professionals, Burton also believes change should be realized as soon as possible throughout the organization to prevent substantial losses for everyone. Working on a shared goal, such as improving the customer experience, for example, can help influence developers to appreciate that maintaining a system is as important as developing new features.

    Change the Culture of Fear

    As Bittner notes, “If agile was the opening act, continuous delivery is the headliner.” Once the culture change is favorable and the company is running at full capacity thanks to the DevOps approach, favoring innovation and experiments within the organization becomes one of DevOps’s main advantages. Still, allowing it to work might prove unattainable to some companies. What lies beneath is the fear of failure that can paralyze every manager and employee.

    Randy Bias, director of the CloudStack Foundation and vice president Technology at EMC, speaks of “a culture of fear” that exists within organizations, which is driven by an “endemic” fear of failure.

    This is caused by the widely adopted practice of heavily penalizing every form of failure instead of focusing on how to minimize the potential losses and still allow experimentation for the sake of innovation.

    The real question is, How can you make this possible when your business is at stake? The secret to success, according to many industry experts, is creating a structure based on separate components that can malfunction without leading the company to bankruptcy.

    As hard as this may be for companies relying on monolithic applications, it is best to adopt microservice architecture that will permit managers to allow developers freedom, even if this means paying the cost for the potential mistakes.

    According to Mike Kavis, vice president and principal architect at Cloud Technology Partners, and Etsy’s CEO Chad Dickerson, it is essential to allow people to make mistakes as freely as reason allows and turn postmortems into productive and proactive meetings, not a blame game.

    One of the greatest success stories of today’s business practices, the e-commerce platform Etsy is a great example of the benefits of DevOps practices and blame-free meetings.

    Senior vice president of Technical Operations John Allspaw, who is in charge of Etsy’s “blameless postmortems,” told Business Insider: “Less-skilled companies name, blame and shame. It’s not about avoiding accountability. In a blameless culture, it’s easier for people to take responsibility for their mistakes and learn from them. Developers already feel quite guilty when they break the site.”

    Seeing is Believing

    One-on-one meetings with management, prearranged brainstorming and specially made presentations are no longer enough to effectively influence culture change. Encouraging communication between teams with the right incentives is vital, but modern management needs to push even further.

    The best way to make developers understand operations and vice versa is to get them together and even share job descriptions.

    Companies like OnShape, for example, have taken a big step in reorganizing on-call duty by making developers and operations actually work together. According to Paul Beltrani, webops at MC10 Inc. and former techops at Onshape, this has been a win-win game, as the change has helped both teams.

    Developers have gotten a grasp of the after-effect of a faulty code, while operations have gained a better understanding of how the code works. Furthermore, making dev and ops share a responsibility has also proven to be less stressful, as developers and operations were effectively cooperating by exchanging knowledge to handle the issues.

    CenturyLink goes even further in this direction, by transforming its dev and ops teams into product teams able to support the entire service.

    “It aims to be light on management and process, with each product team assigned each aspect of the product with a laser focus,” explains Jared Wray, CTO of CenturyLink Cloud and head of the development center. “There’s no throwing it over the fence, and there’s no distractions between the two organizations.”

    Patience is a Virtue

    If you’re willing to transform your organization according to DevOps, you should invest all of your patience and good will; be ready to listen and improve.

    As every business is unique in its organizational structure and services, and is counting on many individuals, there is no strict route to follow when implementing DevOps. Of course, there is something all professionals agree on: “Most people think they’re going to snap their fingers and it’s going to happen overnight by doing a reorg. But it’s a full culture shift. It took us three years to make this model, and we’re still evolving it,” Wray says.

    According to Chris Nowak, senior vice president and head of DevOps Services at Bank of America, it’s natural to face initial resistance when presenting teams with new requirements and processes and the best way to handle it is with care. Nowak recommends the human approach: finding and encouraging opinion leaders who can influence change and “eventually help other teams let go and embrace a new way.”

    So, setting clear goals is the first step to becoming a DevOps success and rushing change has only ever resulted in a temporary workaround. DevOps is gaining more and more popularity, making it possible to gather opinions and learn from the forerunners.

    Industry experts have come together to found the DevOps Institute and share a common language through the DevOps Foundation course, so maybe now more than ever is a good time for your business to “go DevOps” and see the value.

  • 3 Ways to Develop the Perfect DevOps Culture

    3 Ways to Develop the Perfect DevOps Culture

    DevOps is not a new concept, but it is still maturing.

    In the seven years since the first “DevOps Day” took place in Europe, DevOps’ influence has spread to every corner of the world. Many organizations have embraced the concept, and it’s changed the way business is done. These companies have benefited from removing the gulf between development and operation teams—we have seen companies consistently churn out better software, in shorter time periods, to achieve new levels of efficiency.

    However, this success has not been replicated for all sectors. Federal agencies, for example, have been slow to adapt to DevOps. For other companies, a rush to implement DevOps has led to ongoing issues that prevent them from realizing the true benefits of DevOps.

    Building a DevOps Culture

    Many companies are moving in the right direction to implement DevOps successfully, but critical barriers still remain in developing the perfect culture. Here are three ways you can make the vision of DevOps a reality:

    1: End the Culture of Fear

    Much like previous aversions to cloud, the biggest barrier to implementing DevOps is the fear of change. This is a common problem across sectors, because trying something new can be daunting. This is true for federal agencies protecting national security or private companies attempting an ambitious new project. Successful DevOps begins with buy-in from the highest levels of management—but how do you get them on board?

    The best approach is to start small by moving forward with a low-risk, high-reward pilot program. This is an opportunity to get the development and operations teams in the same room and allow them to work together toward a common goal. Once executives see the positive results—reduced time-to-value, efficiency gains and cost savings—they’ll be more apt to double down on establishing a companywide DevOps culture.

    2: Find and Establish Talent

    A DevOps culture is different and requires a shift in mentality. It also requires talented people with unique skills and experience. Since DevOps is still a relatively new concept—even by technology standards—talented people are scarce and in high demand. But companies can bridge the talent gap through a targeted strategy that incorporates both recruiting and training.

    We are starting to see more companies provide educational support programs to develop talent. That must continue if companies want to build the next generation of DevOps leaders. These programs allow employees to grow their skills to better meet the needs of DevOps, which will fuel their career growth while helping their company improve its efficiency.

    In parallel with training, companies must aggressively recruit tech talent from top universities that have DevOps classes. Recruitment of tech talent has rarely been more fierce, and it will only intensify as more federal agencies implement DevOps and compete for talent. The commitment from federal agencies to emerging IT strategies, including DevOps and agile development, will make them far more attractive to the best STEM talent. 

    3: Measure, Measure, Then Measure Again

    The ability to deliver impactful ROI metrics is one of the best aspects of DevOps, because it removes all the guesswork whether it is making an impact. The numbers will tell you daily.

    The first step is to measure your current metrics, whether you’re struggling to make DevOps work or implementing it for the first time. Companies must know how efficient—or inefficient—existing software development processes are before beginning to change. With the right talent in place with the right frame of mind, it’s time to track the improvement.

    Also, understand what results to expect and plan accordingly. Based on our experience, deployment should be eight to 10 times faster with 50 percent uplift in quality (measuring reduction of incidents and incident duration), while software builds should be three to four times quicker.

    If you properly set up the perfect DevOps culture, the results can be astounding. We’ve seen a company institute a DevOps structure and reduce release windows from two days to two hours, simply through repeatability and scalability.

    The Goal: Break Down Barriers

    Despite DevOps rapidly growing in importance, questions remain from those skeptical about its effectiveness. It reminds me of a line I hear frequently at conferences and shows that always gets a laugh: “To err is human. To err on 10,000 servers in 10 minutes is DevOps.”

    The truth, however, is that DevOps is a very simple concept about working together and working smarter. It is the realization of a more efficient, more productive organizational model. It’s time for all companies to break down barriers, create a modern culture, and deliver better software in shorter cycles.

    About the Author/Raj Ananthanpillai

    Raj_headshotMr. Ananthanpillai is the Chairman, CEO and President of InfoZen and has been with the company since January 2004. Previously, he served as the Chief Strategy Officer of ePlus, a business process automation and financial services company, responsible for technology, marketing, analyst relations and business strategy. Prior to that, he was the president and CEO of NetBalance, a venture capital-backed multimillion-dollar software company, which was successfully sold in 2000. You can connect with Raj on twitter or on linkedin.

  • Six Honest Serving Men of DevOps !

    “I Keep Six Honest Serving Men” is a famous poem by Rudyard Kipling.

    Take help from these honest men in a brave and dangerous new DevOps world:

    I keep six honest serving-men
    (They taught me all I knew);
    Their names are What and Why and When
    And How and Where and Who.
    I send them over land and sea,
    I send them east and west;
    But after they have worked for me,
    I give them all a rest.

    These six questions have been very useful in every new DevOps assignment: Ask the right questions early in the assignment and you can worry less about irritating others. It’s also the time to ask seemingly stupid but pointed questions.

    You will find that these questions are of great help to the team in finding better ways of working or to eliminate unnecessary process steps and bottlenecks. And, as a new member, you gain a better understanding of the product and approach.

    So, be bold in those retrospectives and interactions, and challenge any biases of the incumbent team.

  • Big Room Planning: Getting Everyone on the Same Page

    Many organizations—or even teams within organizations—are attempting to embrace DevOps. The operational and strategic advantages of DevOps over traditional business methodologies make it a virtual business imperative. One of the prevailing ideas about DevOps is that it’s about a culture shift more than tools and principles—and a big part of that culture shift is making sure everyone is on the same page.

    Rally Software—which was acquired by CA in May of 2015—provides software and services to help customers succeed with Agile development. One of the main components of the services side is to educate customers about the importance of working in harmony and guiding customers through a process called Big Room Planning. DevOps is a natural extension of Agile development principles to the rest of the business, so Big Room Planning can be an effective tool for DevOps just as it is for Agile development planning.

    I spoke with Steve Wolfe, director of Product Marketing for Rally, who explained the goal of Big Room Planning is to teach customers how to be more collaborative and help them get to a position where they’re able to respond faster to customer demand or market pressure. The idea is to foster an environment of collaborative planning that brings in the whole organization.

    “At Rally we’ve learned that delivering the most value from your software usually requires multiple, coordinated development teams—often distributed—working together and with the business,” Wolfe noted in a blog post. “Building software at this level is complicated, with a lot of moving parts, dependencies and competing priorities.”

    Many organizations—particularly organizations that already are familiar with Agile development—understand the value of consistent feedback and frequent iterations. Collaboration is a keystone of Agile. However, when you take that to a broader scale with DevOps, it becomes critical that all parties impacting—or affected by—the project be represented in the collaborative effort.

    Wolfe noted even in companies that use Agile development effectively, problems arise when teams work in isolation. Teams create plans that they agree on in their group, but aren’t realistic or don’t align with broader business goals. Meanwhile, other teams or departments don’t feel committed to plans they had no part in creating. The result is more like the traditional business model than DevOps: You end up with a situation in which any one team can halt progress and create a bottleneck.

    The Big Room Planning approach is intended to address that problem. The entire organization must be engaged, with full support from all of the affected roles and departments in the planning process. As the name implies, you need to get everyone together in a big room (or virtually via web conferencing, if necessary) and collaborate on a grander scale to make sure everyone agrees with and is committed to the plan.

    Wolfe also stressed that leadership support is essential. He recommends finding someone to champion the concept—an executive to lead the Big Room Planning effort. In and of itself, this idea doesn’t seem all that revolutionary; common sense dictates that development will flow more smoothly and business will function more effectively when everyone is on the same page and working toward the same goals. The crucial part is to not take it for granted and to use a strategy such as Big Room Planning to ensure more effective cooperation and collaboration.

  • Carving through the hype – take the DevOps maturity assessment

    Carving through the hype – take the DevOps maturity assessment

    As anyone who spends time with their family over the holidays can attest, the notion of maturity is a highly subjective concept.

    Whether it’s sizing up the next generation’s advancement or defaulting to time-honored inter-sibling behaviors, annual get-togethers offer tangible proof of what’s new and those things that likely won’t ever change.

    In the domain of DevOps – an umbrella concept that encompasses a massive array of processes and supporting capabilities – gauging the maturity of your organization’s standing is also a highly interpretive task.

    Given that “DevOps” means something different to nearly every organization, based on its unique makeup, methodologies, tools, and most importantly, business goals, attempting to measure progress against any outside model may seem an effort of limited value.

    That said, as an increasing number of organizations seek to embrace DevOps, and growing recognition that well-worn stories of leading-edge “unicorns” don’t relate closely to most people’s real-world expectations, many teams are left wondering where their own efforts stand, especially in comparison to their peers.

    To help acquit this pursuit, and allow organizations to scope their progress, CA recently launched the second iteration of its online DevOps Assessment.

    Split into three short surveys covering core limbs of the DevOps tree – “Develop and Test”, “Release and Deploy”, and “Manage and Monitor” – this free tool offers detailed insight into how your organization’s maturity stacks up to that of other practitioners.

    For instance, in the domain of development, how well do your teams fare in defining and managing requirements, and then presenting them to others in a structured manner? Related to release cycles, are your teams truly meeting business-driven expectations for more frequent application deployments, shorter lead times, and higher success rates? Or, when it comes to applications monitoring, are you able to distinguish the most critical and recurrent problems and how they truly impact business services?

    These are perhaps some of the most fundamental questions that one could apply to measurement of DevOps adoption in general, but further investigation attempts to take a closer look at more finite, underlying issues.

    Are your development teams accurately replicating realistic conditions from production systems to create virtual services and testing scenarios? Are your application release deployments fully automated across development, test and production environments? Can your teams monitor complete business services that link user experience, transactions and applications to infrastructure to pinpoint any root cause issues?

    The best thing about the survey is that it immediately provides visibility into how your answers compare to those of previous respondents. There’s no fuzzy math or editorial interpretation (though we may highlight trends in a report at some point), merely instant validation, and the option to create a customized report card charting where your efforts stand in relation to those of your peers.

    If you’re wondering precisely just how to achieve your long-term DevOps goals comparative to where you stand today, it might even be worth leveraging some of the involved questions for the purpose of evolving process and methodology.

    The only remaining questions are: Do you think that you’re ahead of the curve? Are you afraid to find out just how far you’re behind the crowd? And most importantly, what do you have to lose?

    Take the survey today and get a real-world fix on your overall level of DevOps maturity. Guaranteed it’s a far more informative activity than debating family and friends over whose turn it is to carve the turkey, or wash the dishes.