devopsy.kinsta.cloud

Category: DevOps Culture

  • DevOps: Build a Continuous Improvement Culture

    DevOps: Build a Continuous Improvement Culture

    DevOps was built around the concept of continuous everything. We even use it in many of the names—continuous delivery (CD), continuous testing, continuous integration (CI)—and it is a worthy goal to want to improve the places that form bottlenecks in your software delivery systems and processes.

    But what about the bottlenecks in the DevOps systems and processes?

    Like any other system, DevOps involves tools. We choose those tools, invest in learning those tools and use them to do great things. But then we have investment in the tool. If our knowledge and systems for deployment are all based around CD tool X or ARA tool Y, we are just as unlikely to want to move from it as we were unlikely to want to move away from the previous toolset.

    Even if you discount the number of shops that have done pilot or small-team DevOps but kept the core of their business waterfalling, there are still a large number of organizations that stepped into DevOps and stopped improving. Granted, it is a huge job to move a significantly sized application portfolio into the DevOps mold and toolchain, but it is contrary to the process/goals to stop just because you did.

    The market is nowhere near finished evolving: New tools are coming available and massive improvements to existing tools are being released. Keep taking advantage of those facts.

    The more projects/portfolios you have moved into DevOps, the more weight there is to resist change. That is the simple reality, just as the larger a rock, the harder it is to move (assuming the same type of rock, of course). The answer: Watch for those improvements that will make moving the rock worth the force required to do so.

    Working containers into the overall DevOps process, for example, can benefit every step in the toolchain. But if they’re not already in the process, it is a lot of work to get them folded in. I chose this example because for most shops, a little research will show it is well worth the effort. From preconfigured Dev/Test/Prod servers to run-and-done compile instances, containers can make the process more manageable and more agile. The benefits outweigh the costs for most shops.

    So keep an eye out. Don’t implement and spend all of your time on the tools you’ve chosen. Stay aware of what is out there, and what is coming. Understand how it would impact the DevOps process and try to pull in those items that fit the environment.

    And, as always, keep rocking it. The end goal is to keep the systems up, running and usable. And most of you are doing a great job.

    (This, and all blogs, brought to you as much by the geeks behind the scenes as the author and editor.)

    — Don Macvittie

  • DevOps Adoption: The Driving Force of the Industry

    DevOps Adoption: The Driving Force of the Industry

    DevOps has transformed from a mere idea on paper to the way processes function in the face of an immediate requirement. Development and Operations together make for one of the most successful collaborations today.

    As per a research report, people have now begun to understand what DevOps is. When asked how familiar they were with DevOps, 84 percent of respondents said that they well-versed with the concept, in comparison with 60 percent who agreed to the same the previous year.

    DevOps is writing the success stories of the world’s business giants. Facebook, Google, Twitter and Amazon are all working the “DevOps way.” All falls in place when these companies develop, test and successfully deploy code in a matter of one to 23,000 minutes per day. We agree that’s insane!

    How Have We Benefited from DevOps Adoption?

    To sum up the benefits of DevOps adoption in a nutshell, users see:

    • Drastic reduction in lead times—With the pressure to deliver software faster and meet the challenges of the growing market, there is always a need to look at progressive ways of getting the job done, DevOps became the solution. As per statistics, practitioners believe this to be the top benefit of DevOps in 2018. Sixty-nine percent of respondents agreed to this benefit, as compared to 39 percent in 2017.
    • Increased ability to release new features with improved reliability stability and security—The need to improve the user experience and keep the customer equipped with the necessary tools to meet the challenges of a growing business made IT personnel realize that it is always essential to introduce new features into the deployment process. DevOps made it easy. Figures tell us that the implementation of DevOps led to 73 percent of people believing in its benefit of enhanced user experience, this year.
    • Enhanced IT and Organizational Productivity, Higher Profitability, Revenue and Market Shares—Now with the best process having so much to offer, all businesses have gained a lot in terms of savings and earnings. DevOps drives revenue: 26 percent of people reported an increase in revenue in the year 2018 as compared with 20 percent in 2017.

    Why No DevOps?

    Although we’ve seen a major shift in trend from being skeptical about DevOps and its implementation to becoming “pro-DevOps,” over the years, not all of us are up for this big business move. The reasons being many.

    Listed below are the most commonly given reasons by industrialists around the world:

    • Other technology and business priorities—With newer technologies being developed every few weeks, companies are confused over which technology will give their business the required leverage. This leaves them to either becoming very choosy or just ignoring the prospects of adopting a technology at all. Some business owners think about fund allocations. They want to invest their hard-earned money into something they see as more viable or something that convinces them about profits. When it comes to innovative ideas such as DevOps, they think these things may not bring them immediate results or they’re not as important as the “conceived” business priorities. As per a study conducted in February 2018, as much as 38 percent of the sample population opted out of DevOps for the above reason.
    • Lack of resources—Most organizations lack the required resources in terms of personnel, tools and persons with expertise. This discourages organizations from taking up such practices. While it is great to have a workforce with work experience for the dev and ops teams individually, it is crucial to have employees with DevOps experience on board. Similarly, lacking the right tools can have your organizations whimpering in the wake of a growing market despite having an able workforce. Statistics show that 34 percent of people hesitate to adopt DevOps for the given reason.
    • Lack of cooperation between development and operations—Whenever there is a mention of DevOps, there is also a mention of the cultural indifference of Dev and Ops teams. Each team has their unique work culture and when they come together on common ground, they cannot help but fall apart. Most organizations do not encourage the DevOps practice on account of this cultural disparity.A significant 22 percent of the industries under this research shun the idea of DevOps owing to this disparity.
    • ‘We don’t see the value’—It is likely for some business to say this. It is difficult to assess the value of the process from an outsider point of view. If someone has heard about DevOps but don’t how it will profit their businesses, then it is difficult for them to adopt it. As per statistics as small as 6 percent of the sample population did not adopt DevOps for this reason.

    On an End Note

    Organizations have been opting for DevOps after seeing its contributions to the industry. This year has most businesses functioning with major dependence on the skill and agility of the DevOps processes, and this has been proven through the success of their business. We hope the remaining number of entrepreneurs come to realize the importance of DevOps for their business and implement its benefits to build their success and keep up with the challenges of the fast-growing market.

    — Veritis

  • Are You a Product Team in Name Only?

    Are You a Product Team in Name Only?

    A simple litmus test can help determine whether a product team is the real thing or wearing a different name.

    Marketers have been trying to dress up spam, ever since the odd can-shaped meat was invented. It has been called “special processed American meat,” “shoulders of pork and ham” and even “spiced ham.” But, no matter what you call it, Spam is still spam.

    Dressing Up is Not Just for Canned Meat

    Something similar has been going on in IT.  We are getting makeovers as well.

    Instead of putting in the hard work of changing culture, organization and operating model, we are simply just relabeling the status quo.

    For example, projects are now called products, development teams are called squads, meeting are called standups, small sprints are called MVPs and everything is now an experience. The list goes on. But the underlying structure and organization has not changed.

    Maybe executives are hoping that the change in name might just bring about the culture change that they are seeking. But at the end of the day, these newly coined product organizations are still slow, costly and risky, and companies continue to publish subpar code.

    Separating Truth from Fiction

    So how can you tell the difference between a real product organization versus one that is pretending to be? How can you tell if the organization has put in the effort and time to make the real changes versus just a name change? Consider this litmus test:

    1. The team is made up of cross functional SMEs, which includes all the various skill sets (Business, UX, Dev, Test, Ops Etc.) required to ship a product/increment.
    2. There is a dedicated product owner and a scum master.
    3. The product owner is the single owner responsible for both, output (business KPIs) and input (resources) and everyone on the team and within the organization knows about it.
    4. The scrum master helps the product team stay on track, removes impediments and shields the team from external distractions.
    5. The squads are judged on their impact to business metrics (business KPIs are tied to every new feature released).
    6. The teams are autonomous; they (not someone from the outside) decide how much work to commit during a sprint.
    7. The team keeps the backlog well-groomed and accurate, and resolves issues without escalating to management.
    8. The executives trust the product team to do the right thing within a sprint.
    9. Minimal viable product is the default delivery mode and cycle time (development to release) is no more than a few sprints.
    10. For every feature the team has agreed on the definition of done, its business impact and how to measure that impact before it goes into development.
    11. Product team uses continuous integration (which includes a agile development, branching strategy, on-demand environment, automated build and test and strict quality gates).
    12. Feedback is part of the product team’s DNA; failure is expected and is considered as an opportunity to learn.

    If your team espouses the above characteristics, congratulations: You passed the test. More importantly, your organization has done most of the heavy lifting and created a truly high-performing product team. That’s no small feat.

    However, if your team does not share many of the above characteristics, then you have your work cut out for you.

    Good luck.

    — Mustafa Kapadia

  • How to Cultivate a Loyal Developer Community

    How to Cultivate a Loyal Developer Community

    With the number of developer focused companies and products growing, building communities among engineers has become a key strategy to stay competitive. Augmenting and often surpassing traditional marketing techniques, this approach—although challenging—can be an incredibly effective way to engage users and get engineers excited about a product.

    Since our inception over six years ago, DigitalOcean has worked to establish a robust developer community around our product through a variety of channels. This includes our public open-source focused Community, which attracts more than 3 million monthly visitors.

    It Takes a Village to Make a Community

    Beyond creating a product developers love (that always comes first), here are some best practices and lessons we’ve learned for cultivating a great developer community.

    Develop Personal Relationships

    A community implies connection, so first, look for ways to form connections directly and show people you care. In its early days, Twilio did a great job at getting out of the office and doing meetups to speak to devs directly, and I would argue this was essential to it becoming as successful as it is today.

    This also involves finding ways to shine light on individuals in your community. When we found out one of our community members recently had a baby, we sent them a onesie for their newborn. Chances are, you also have community members who are doing amazing things, and would love the recognition for it—either on social media or your blog.

    Taking the time to meet users where they are and working to establish closer relationships with them creates a virtuous cycle: these users help the community grow with their contributions, suggestions and feedback, and therefore feel more empowered to continue to invest in the community. Everyone benefits in this scenario and, equally important, your communication out to the community is genuine because you gain a deeper understanding of exactly who you are talking to and building for.

    To that end, it’s important to have someone or a team (for example: developer advocates or community managers) ready to engage directly with your community and bring the lessons back to the company. You’ll want individuals who are capable of responding, both offline and online, in an authentic way.

    Create Avenues for Them to do Meaningful Work

    While many developers enjoy their work, they often have far-reaching interests beyond code. Companies that find ways to help their communities meld code with what’s important to them personally will see much more stickiness and retention.

    For example, developer analyst firm RedMonk has done a good job of creating conferences (MonkiGras and Monktoberfest) that go beyond technical presentations and instead create discussions around issues such as the intersection of society, culture and technology. This provides a forum for the developer community to connect over shared interests and experiences—not just code or languages.

    We created a program called Write for DOnations that not only pays contributors for  writing technical articles, but also matches this payout with a contribution from us to the author’s choice of tech-focused nonprofits. This not only incentivizes our community to remain active, but makes them feel they’re making a difference. Because we take time to build a relationship with each of our authors, they know that they can help make a regular investment in those organizations.

    Make Product Development Decisions a Two-Way Street

    If you’re creating products for developers, their needs should be top of mind. Using a product feedback forum allows developers to ask questions and make product requests while giving them a faster feedback loop for their product development. We launched our object storage solution “Spaces” last fall in large part because of the flood of requests we received via our User Voice voting system. We’re not alone by any means in creating two-way streets: GitHub has an extensive forum forum for users to talk about different elements on GitHub and get advice. Stripe allows its community to chat directly with its own devs on Freenode as a way of further fostering their own community.

    Providing visibility into your own product road map is also critical — by sharing in advance what you’re planning with your users, you can help them make much smarter long-term decisions.

    Meet Them Where They’re At

    Connecting with developers in person is incredibly powerful, and meetups are a great avenue for this. However, if geographic barriers arise, broadcasting these meetups live is a nice way to engage people dispersed across multiple locations and ensure they too get value from your meetup programming.

    On the more tactical side, sharing swag helps keep your product visible even after the meetup or event has completed. A nice shirt or cute sticker allows your community to feel connected and effectively act as brand ambassadors. We’ve seen this to great effect with our Hacktoberfest effort: After sending t-shirts to individuals helping out with open source projects, we often meet people later at conferences still sporting their well-earned tee.

    Building a community takes effort. When beginning to forge one, it is invaluable to consider how your specific audience enjoys connecting and how the company can serve them best. There is no one formula for creating a vibrant, engaged community, but with some experimentation and a lot of listening, you can create something truly special around your product.

    — Etel Sverdlov

  • What Comes after DevOps? Two Possibilities

    What Comes after DevOps? Two Possibilities

    People have been talking about the “post-DevOps” world since at least 2014. But have we actually arrived in the post-DevOps era? If so, what comes after DevOps? Let’s explore those questions.

    The DevOps concept is more than a decade old. DevOps has seen widespread adoption across companies large and small. “DevOps engineer” is now a common job title for tech folks.

    At a minimum, these developments mean that DevOps is now very mature and mainstream. They may even signal the end of DevOps, depending on your point of view.

    Even though DevOps remains a useful concept, the fact that DevOps is now so mature means it is no longer as novel and dynamic as it once was.

    That begs the question: What comes after DevOps? I think there are two distinct possibilities.

    A Reaction Against DevOps

    One possibility is that we’ll see a backlash against DevOps, and an attempt to replace DevOps processes with alternatives that are designed to do the opposite.

    Indeed, there has already been a fair amount of outspoken criticism of DevOps for years. It has mostly remained under the surface.

    But in an era when almost everyone is doing DevOps, it seems reasonable to expect that some organizations will find it doesn’t solve their problems after all. Those organizations most likely will return to earlier ways of doing things.

    In this scenario, DevOps is unlikely to disappear entirely. But we probably would end up in a hybrid world where software delivery teams mix DevOps principles, tools and practices with those from earlier eras.

    DevOps-ifying the Whole Organization

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

    This trend has already been playing out to a certain extent for years. Concepts such as DevSecOps (which extends DevOps into the security realm) and DevQAOps (which integrates Quality Assurance with continuous delivery) have been around for at least several years.

    Still, there is room for DevOps concepts to establish deeper roots in areas outside of dev and ops. Most organizations could benefit from doing more DevSecOps, for example. And as I’ve written in the past, even PR, legal and other departments could be integrated more tightly into the software delivery process.

    To date, few organizations have sought total DevOps-ification by applying DevOps principles to all business units. But this could be the great innovation of the post-DevOps world. If this scenario plays out, DevOps won’t go away; rather, organizations will double- or triple-down on their investment in DevOps.

    — Chris Tozzi

  • Puppet Report Sees Long DevOps Journey Ahead

    Puppet Report Sees Long DevOps Journey Ahead

    A recent report published by Puppet suggests the level of DevOps maturity within most organizations is still relatively slight. In fact, most of the respondents reported high levels of manual work still occurring across configuration management, deployment, testing and change approval processes.

    Alanna Brown, director of product marketing for Puppet, said the “State of DevOps: Market Segmentation Report” makes it clear that DevOps is being embraced to solve specific pain points with specific IT departments. As a result, silos of DevOps processes are springing up across the enterprise. That next challenge IT organizations will face is trying to unify all the DevOps processes, she said.

    The survey finds deployment automation, version control, continuous integration and infrastructure automation were the most common starting points for DevOps. Less-common starting points were lean practices, visualization of key quality and productivity metrics and setting limits on work in progress.

    Brown said the one surprising thing that study found is there is little correlation between the size of the companies surveyed and their relative DevOps maturity. Reliance on DevOps process may have more to do with needs arising from satisfying customer demand than anything else, noted Brown. The survey finds that media and entertainment and retail industry have the lowest percentage of low IT performers, while financial services, insurance and manufacturing companies had the highest proportion of low performers.

    Not surprisingly, given the relative amount of DevOps immaturity, the survey also finds that reliance on IT automation frameworks is not yet especially widespread.

    The Markets Segmentation report is based on the 2017 “State of DevOps” survey of 3,200 IT professionals that Puppet previously published. While it’s possible many companies may have advanced further down the DevOps journey since then, the report makes it clear that for both technical and cultural reasons fully embracing DevOps is an extended process. In fact, Brown said the report shows DevOps is still mainly being driven by the bottom of the organization up rather than by senior IT leaders. It’s only when DevOps success becomes visibly demonstrated that organizations attempt to replicate that success elsewhere in the organization. At the same time, widespread usage of DevOps processes suggests that DevOps itself is now much more than a grassroots movement, she said.

    Change obviously comes hard to enterprise IT organizations. Many DevOps concepts were initially pioneered by web-scale companies that have the luxury of not having to support legacy applications and processes. Traditional enterprise IT organizations now typically are trying to support DevOps processes alongside process based on Waterfall and ITIL methodologies. Not every application being supported requires that number of release updates that many modern applications require.

    Nevertheless, it’s also clear that as the number of applications being built, tested, deployed and supported continues to grow, the average IT organization is increasingly short-handed. Finding IT professionals with DevOps skill sets is a major challenge. But as more companies come to realize they are really a software company that happens to be selling a specific thing, the higher priority DevOps becomes.

    — Mike Vizard

  • For DevOps, (Organizational) Size Matters

    For DevOps, (Organizational) Size Matters

    When it comes to DevOps, size matters. The number of people in your organization, as well as the size of its infrastructure, play a huge role in shaping how and why you adopt DevOps.

    The importance of company size may come as a surprise. Few conversations about DevOps mention the role of organizational size in building a strategy.

    That may be in due, in part, to the fact that DevOps engineers tend to be obsessed with the idea of scalability. A healthy DevOps process is one that can support an application with a million users just as effectively as it supports an application with a hundred users.

    In theory, your strategy should be similarly scalable. But in reality, this is unlikely to be the case. The way that a company with a dozen employees does DevOps is going to look quite different from the way a Fortune 500 company does.

    Small Companies

    In a sense, DevOps is easiest to achieve at very small organizations. In fact, it is almost inevitable in companies of this size.

    That’s because, when you have a very small IT staff, your engineers will end up playing multiple roles because that is the only way that all IT tasks can be completed successfully. People you hire as developers will have to help support and test the apps they write because otherwise, those processes might not happen.

    What this means is that at small companies, it tends to be something that happens organically, not deliberately. IT teams at such organizations don’t need to plan a DevOps strategy; they just need to let it come into being of its own accord.

    Large Organizations

    You might expect the opposite to be true within large organizations. But in many cases, it’s not. Large companies may also find themselves building their strategies organically.

    The reason is that, at large enterprises, the IT organization tends to be broken down into many small teams, each working on different apps and processes. Because these individual teams are small, their members also tend to embrace DevOps practices by performing multiple IT roles, whether deliberately or not.

    True, large companies often benefit from planning and implementing a companywide strategy. Encouraging DevOps best practices companywide can help to improve collaboration between different teams within the organization. It can also improve the ability of security or QA teams, which may otherwise operate in silos, to interact with other groups.

    But by and large, if you are an enterprise whose IT staff are broken into a number of small teams, you will likely find that DevOps happens more or less on its own.

    Medium-Sized Organizations

    It’s medium-sized organizations that tend to have the hardest time doing DevOps effectively. That’s because these organizations are large enough to have a sizeable IT organization, but too small to break that organization down into multiple project teams.

    As a result, medium-sized organizations erect the most rigid silos around their IT teams. They might have a single team of developers who focus on building a few applications, and a single IT Ops team whose job is to support those applications. But these two teams may not interact much.

    For this reason, a deliberate DevOps strategy is most important for organizations that are of a medium size. Their silos need to be broken down actively.

    Conclusion

    The bottom line: When it comes to adopting and improving DevOps, take some time to evaluate how the size of your organization impacts it. Is your company sized and organized in such a way that it will more or less happen on its own, or do you need to take deliberate steps to implement it? Answering this question is crucial for achieving DevOps in the most seamless way possible.

    — Chris Tozzi

  • The Past, Present and Future of DevOps Infrastructure

    The Past, Present and Future of DevOps Infrastructure

    Infrastructure automation enables organizations to set up operating frameworks that allow smooth functionality with enhanced usage, minimal scope for error and faster deployment of code. The process of infrastructure automation eases development and operations processes by introducing good deployment practices such as computerized testing and versioning.

    The need for automation was realized when the demand for deploying error-free applications at a faster rate increased. Additionally, competition from similar businesses forced organizations to look for a way to bridge the gaps between development and operations to deploy applications that would serve their business needs.

    The Challenge of Implementing DevOps Practice

    The following challenges present a roadblock in bringing out the best results of DevOps practices:

    1. The disparate work cultures of the development and operations teams.
    2. Non-involvement of DBAs in release cycles.
    3. Failure in deployment of error-free codes.

    The Emergence of DevOps

    The introduction of DevOps practices resolved a lot of problems in terms of increasing business operations efficiency. It created a common operating framework where disparate teams including development and operations teams can work together and deliver applications faster that will, in turn, result in effective business operations and an increase in ROI.

    Adopting DevOps involves:

    1. DevOps experts outlining of traceable metrics for creating a roadmap by visualizing the desired outcome.
    2. Creating a pilot framework that will include the tools of both development and operations teams further integrating these existing tools with the DevOps experts’ robust ecosystem,
    3. Analyzing, designing, constructing, automating and implementing the network based on the metrics and resources collated.

    DevOps Tools:

    The DevOps infrastructure automation process uses several tools that define and drive the success of the implementation process. Here is a short overview of some of the more well-known and widely used tools.

    • Jenkins – A Java-based continuous integration (CI) tool contributes to the faster delivery of applications. Jenkins must be aligned with a version control system such as GitHub or SVN. Whenever the code repository receives a new code, a Jenkins server builds and tests the new code and informs the team about results and any changes. Over time, Jenkins has moved from being just a CI tool to being used as an orchestration tool that builds pipelines for application provisioning and deployment.
    • Chef – A ruby-based configuration management tool, Chef includes cookbooks that code infrastructure in domain service language (DSL) in combination with a little bit of programming. Chef creates virtual machines and customizes them in accordance with the rules listed in the cookbooks. An agent residing on all the servers that need configuration extracts the cookbooks from the chef master and runs them on the server to get the desired results.
    • Puppet – Also, a ruby-based configuration management tool, Puppet was developed with system administrators in mind. A configuration code is written using Puppet DSLs and is wrapped in modules. Puppet performs a similar function to Chef but, unlike Puppet, Chef is a developer-focused tool. It runs a puppet agent on all servers that require configuration and extracts the compiled module from the puppet server and installs required software packages as prescribed by the module.
    • Ansible – An agentless configuration management and orchestration tool, Ansible can be used for cloud computing. Ansible has configuration modules called “Playbooks,” which are written in YAML format and are easy to compose in comparison with other configuration management tools.
    • Docker – Docker, a process-level virtualization tool, creates isolated environments for applications known as containers. These containers can be transferred to any other system without making any application changes. Docker has evolved as the next step in virtualization. It is beginning to become a favorite of many DevOps practitioners and leading cloud experts.

    The Future of DevOps Infrastructure Automation

    A lot of organizations are beginning to benefit from the implementation of DevOps infrastructure automation. And with the pace at which the demand for DevOps services is increasing, infrastructure automation has a long way to go.

    As per statistics, by bringing DevOps practices into the picture, organizations can benefit by deploying code up to 30X more frequently and reduce the deployment failure to less than 50 percent.

    — Veritis

  • Transition to DevOps Increasing Across IT Firms

    Transition to DevOps Increasing Across IT Firms

    Demand for faster product development and quick market release created a need for increased collaboration between Development (Dev) and Operations (Ops) teams, which eventually led to “DevOps.” With this, transition to DevOps has become one of the key points of discussion across many IT firms. This article gives you an overview of the demand and trend for organizations to transition to DevOps.

    Rise in IT innovation and burgeoning digital revolution have led to the demand for faster development and quicker releases to stand out in the IT competitive scenario. This transition eventually led to a new culture that saw collaboration between two key IT teams, development and operations teams, which the industry calls DevOps.

    DevOps established a new style of IT functioning, easing different phases of software process from product development to testing and final market release, all in a rapid and reliable way.

    Why DevOps Transition?

    Rapid delivery of independent software components and continuous integration of the same with production systems forms the key principle behind DevOps functioning.

    DevOps is often confused with Agile methodology. Though they share similarities in providing improved IT performance through rapid development, DevOps stands apart from Agile because of its efficacy in the software deployment phase, ensuring a constant communication between the two teams. Thus, DevOps is often termed as a successor to Agile.

    A collaborative approach, key for information exchange across the line, is one of the major factors driving firms to undergo DevOps implementation.

    Though DevOps is well-known as a merger of development and operations teams, an effective DevOps model extends beyond that to other key functional areas of organizations.

    Breaking the old trend of limiting individual teams to their respective work domains, DevOps brought in a scope for knowledge-sharing among them, wherein developers can extend themselves to testing and deployment and operations team members can upgrade their skill set, learning new languages, architectures and tools.

    Increased Demand for DevOps Resource

    Transition to DevOps holds a key demand in the fast-growing IT market, wherein managing with the existing infrastructure or resource plays an almost equal role as coming up with something new.

    Greenfield projects aside, DevOps deployment is most often seen in brownfield projects that encourage building on the existing resources.

    With this situation in place, there is also a lot of demand for DevOps resources across firms. The “2017 Open Source Jobs Report” from the Linux Foundation shows 60 percent demand for DevOps human resources among more than 2,000 IT open source professionals and IT hiring managers.

    This clearly shows the level of demand that transition to DevOps is holding in the IT industry.

    “If there isn’t an existing DevOps role within your company, software developers should spend time sitting with the operations team or vice versa to understand how their processes work and how they can be improved through collaboration,” said Mike Durney, CEO of the job-hunting site Dice.

    The report found:

    • Nearly 50 percent of hiring managers are keen about those DevOps resources with professional credentials such as relevant certifications
    • More than 47 percent of the companies are ready to fund certification programs for their existing personnel
    • 42 percent of companies are keen on adding DevOps skills to their hiring portfolio
    • “DevOps Engineer” profile ranks second in Glassdoor’s Best 50 jobs in America

    Despite its advantages, however, DevOps has a few challenges to overcome related to application integration, test automation, budget and skill set, among others.

    — Veritis

  • With DevOps Culture, It’s Mind Over Matter

    With DevOps Culture, It’s Mind Over Matter

    There is quite a bit of conversation about tools versus culture, and sometimes, those constantly involved in the back-and-forth forget that not everyone is so steeped in the finer points of the conversation.

    Tools is the easy part. There are a ton of tools available to optimize IT operations, from small bespoke products such as the Antsle Private Cloud Server to CA’s broad suite of Dev/Test/DevOps/ARA tools. There are plenty of places to find lists or charts of tools, and I’ll leave you to them, just mentioning the two I’ve written about in the not-too-distant past: Xebia Labs’ Periodic Table of DevOps, and CA/Automic’s Continuous Delivery Landscape.

    My youngest just built a Cube-solving robot, so this picture inspired me.

    But what of culture? When pundits and old hands talk of culture, what exactly are they talking about?

    Well, it still varies a bit from organization to organization, but there are some definite underlying foundations.

    Increased Cross-Team Communications

    Even if an org is full-on DevOps, there is still the requirement of cross-team communications to make sure everyone understands what is going on.

    One of the things that this does not make abundantly clear, I will belabor a bit (sorry, old hands). Communications is not just talking. It is not just email exchanges, it is not just sitting in another team’s meetings while researching your current problem on your phone.

    It can be these things, but it is a breadth of options. People are using Slack channels to keep everyone updated, common notifications or even pub-sub systems to make certain information about the state of IT, operations and builds are getting wide distribution. Increase communication, not chatter.

    Organizational Change

    You hear that a lot, and it can mean complete overhaul of an IT organization, but in an enterprise setting, it rarely does. The reason is simple. There may only be one or two Cisco specialists, or one or two EMC specialists, and these people don’t properly belong on one or two product/project teams in the long term. The same goes for security and a whole further swath of operations team members.

    So in the enterprise, what “organizational change” often means is moving those responsible for development and core deployment closer together on small, product- or portfolio-based teams. Networking staff, security staff and infrastructure staff will join the teams as needed, but are not part of the core team.

    Management Change

    This is another often spoken-of mantra that easily can be misunderstood. In short, managing a small, agile, entire product lifecycle team is not the same as managing a pool of resources that pop from project to project and are either (a) not involved in the operations portion at all, or (b) not involved in the development portion at all.

    For a great set of perspectives on this topic, I’ll recommend our partner The DevOps Institute. It has an eBook and a certification course (DevOps Leader) on this topic.

    Decentralization, Yet Increased Oversight

    This is often a confusing pair of messages we send when talking about what DevOps culture change does. It really is not that complex—pundits just assume everyone already knows, and, honestly, those knee-deep in DevOps do know.

    Decentralization, as taught in the DevOps Leader course mentioned above, is about driving as much decision-making as possible down to the team. When teams are built around a product or group of products, then those with the most pertinent information about what is best for the product quite often can be made within the team, speeding decision-making and implementation.

    Increased oversight is an acknowledgement of two things. First, there is more information available in an agile environment, and that information is available more frequently. Standup meetings offer some, while milestones offer other data. Second, tools are starting to allow rollup of information in a uniform fashion for CIOs, CTOs and business leaders to look at. This means they can quickly see the status of projects they have a vested interest in and provide feedback into the process. To go from, “Oh, this roadmap item is going to take a lot more work than we thought,” to, “Great, we have a plan, let’s keep moving,” is shorter when there is more information available to the decision-makers on both the business side and the IT side.

    There is no doubt plenty I have missed, but these seem to be the core things that those of us discussing this topic a lot assume others know, and that those just looking into DevOps really don’t. Hopefully it will help someone push through the clutter and come to a decision on DevOps in general, or culture changes in particular.

    — Don Macvittie