devopsy.kinsta.cloud

Tag: devops investment

  • DevOps Deeper Dive: IPO Frenzy Heralds Consolidation

    DevOps Deeper Dive: IPO Frenzy Heralds Consolidation

    A spate of initial public offering (IPOs) has resulted in billions of investment dollars being poured into JFrog, Snowflake and Sumo Logic and is likely to fuel of wave of merger and acquisition activity in the months ahead.

    While each of these software companies addresses fundamentally different IT requirements, they are all tapping into a massive amount of liquidity now available, as investors dump the stocks of companies in other sectors that have been adversely impacted by the economic downturn brought on by the COVID-19 pandemic.

    In fact, the reason all these IPOs appear to be occurring all at once now is the plans to go public that many software companies had earlier this year were delayed by the onset of the pandemic. The backlog for potential IPOs is already staggering. Currently there are more than 400 private startup companies with valuations in excess of $1 billion, which according to the financial research firm CB Insights officially makes them “unicorns.” Familiar names of software companies on that list include GitLab, Docker Inc., HashiCorp, Snyk, Postman, OutSystems, Digital Ocean, Auth0, Redis Labs, Databricks, Collabra, Cohesity, Tanium, Rubrik, SentinelOne, Illumio, Netskope and Kaseya.

    The reasons IT organizations should pay attention to these IPOs are twofold. The first is that it signals the company now has ready access to a stream of investment dollars required to fund ongoing innovation, said Scott Bickley, principal research director at Info-Tech Research Group.

    The second, he noted, is that many enterprise IT organizations tend to limit their amount of reliance on a startup company. Venture capitalists that fund these companies often sell them to other companies to recoup their investment as an alternative to launching an IPO. Most enterprise IT organizations don’t want to wake up one morning to discover a key vendor has been acquired by a vendor they would prefer to not do business with, said Bickley.

    That issue can be especially problematic when cloud service providers such as Amazon, which has operations that reach well beyond IT, are involved, he added.

    In fact, one of the reasons many organizations prefer to rely on IT vendors that are public companies is they have a lot more visibility into the overall viability of the vendor, said Bickley.

    “Assessing risk is part of the due diligence process,” he said. “With public companies, there’s a lot more data available.”

    Of course, public companies do get acquired. The fact that they are public companies usually makes the effort a comparatively expensive proposition, depending on the stock price and the number of shares outstanding.

    However, one of the first things many companies do once they go public is to look to acquire other companies that enable them to expand their overall portfolio, said Mitch Ashley, CEO and managing analyst at Accelerated Strategies Group, a market research firm.

    The DevOps sector in particular has seen a wave of acquisitions of late that have been funded in part by IPOs, noted Ashley.

    “We’re in a bit of a roll-up period right now,” he said.

    Many enterprise IT organizations tend to welcome those acquisitions because it allows them to deal with fewer vendors, Ashley noted, adding support also tends to improve because the larger vendor typically has more resources.

    On the downside, he said, large vendors tend to raise prices after acquiring smaller vendors in part to help cover the cost of the acquisition.

    Like it or not, however, mergers and acquisitions are now a fact of IT life that organizations just need to accept, Ashley said.

    Based on the amount of capital available at the moment, IT leaders should also assume the pace of merger and acquisition activity is about to accelerate, even more as more fuel in the form of capital is added to the fire.

  • Did Your Last DevOps Strategy Fail? Try Again

    Did Your Last DevOps Strategy Fail? Try Again

    Let’s get one thing out of the way. DevOps isn’t a panacea—it isn’t magic, it isn’t a requirement for any enterprise and it won’t work for every team in every situation. Above all, it isn’t a yardstick by which an outsider can measure great operations, development or IT. And if anybody tries to tell you it is, feel free to say thanks and politely change the subject. You’re the one responsible for delivering the services your business depends on, and if the way you do it meets the needs of your business and the team is happy, stick with it.

    But if you’ve tried adopting DevOps methodology, it’s likely because your business needs to substantially alter itself to meet specific goals. And DevOps has demonstrated the ability to help many organizations. Unfortunately, just as many seem to abandon DevOps initiatives and roll back, sometimes more frustrated than if they hadn’t tried it in the first place.

    IT might be the team responsible for reliability, but this is a big challenge in an increasingly “fail fast” era. Many businesses are encouraging their departments to experiment, learn from their mistakes and keep trying until they deliver business-transforming innovation. But in IT, the high visibility of issues—even those initially within the accepted risks of a new project—seem to be treated differently. Even minor and expected teething pains can be judged as failures in hindsight. And many of us have seen instances in which attempting something new and encountering difficulty seems to make it five times harder to get off the ground on the next attempt.

    DevOps is a prime example. As its culture and practices gained popularity, companies were quick to jump on the bandwagon—only to stumble in the execution or not deliver anticipated “transformation” or measurable ROI. It’s not uncommon for these companies and decision-makers to be left with a bad taste in their mouths. They may be reluctant to revisit DevOps and try again, even with the gained value of previous investments and lessons learned.

    This isn’t much of a surprise: Humans don’t like to investigate public failures, and everything in IT is public, assessed in binary absolutes. It either works or it doesn’t, apps are up or down, and everyone in the company can see them. It’s also natural for businesses to switch their focus to the next potential success if personal political capital was part of a DevOps project. And as engineers, looking forward is in our DNA. We’ve built our careers around finding new and better ways to meet customers’ needs, solving novel challenges, and permanently squashing nagging issues to make room for new technology. The trick is to avoid considering DevOps a passing fad.

    There’s significant value to be gleaned from any investment in DevOps—a better understanding of the human dynamics of your organization, at a minimum. If your team tried to implement some of the processes of DevOps or took the advanced step of adopting DevOps culture, don’t forget you did it for a reason. Go back and review what led you to consider DevOps in the first place. Chances are the business needs behind it haven’t changed and may have even expanded.

    Outline those earlier reasons—they’re likely still there, even under novel circumstances such as shifting the team to work from home. Did your DevOps effort meet its original objectives, regardless of any rear-view assessment? Drill into the details where it didn’t. Was it due to culture, communication, risk reassessment or operations challenges? Did your team end up building something different than what you intended—a compromise not meeting the business’s needs? Take your time; you likely had many good people on the effort who are eager to share what they learned. A previous misstep could be due to a skills gap, software, management support or something as basic as infrastructure. The first step in taking another swing at DevOps is analyzing the previous attempt with data instead of opinions.

    And there’s a good reason you’re likely planning to try again: The stakes are high. According to Forrester, 80% of revenue growth will depend on digital offerings and operations by 2022. Organizations will survive and grow depending on their ability to design and deliver technology services, respond to issues and meet growing user expectations. At the same time, considering the environment brought on by COVID-19, IT teams are seeking new ways to sustain operations and use the time to build a head start for when business picks up.

    With this in mind, here are a few ways businesses can approach evaluating the execution of a first DevOps attempt to inform a successful second try.

    First: Deputize an Investigator

    You’ll need a deputy to help you conduct a forensic analysis and your QA team might be an unexpected place to find the right candidate. QA likes many of the outcomes of DevOps practices because they’re often suffering horror-show weekends at the hands of big-bang monolithic deployments at several companies. If you don’t find a detective there, empower someone who focuses on quality service and considers it a peer to availability, security and resiliency.

    Your first job will be to demark the fault lines. Remember, the task isn’t to assign blame and a good admin-side manner is required to prevent this. Remind the team the mission is to avoid making the same mistakes, not to point fingers. Perhaps you originally had fantastic buy-in but everyone got caught up in the wrong details. Was the problem operational? You’ll need to know.

    Second: Admit Mistakes and Ask for Feedback

    Once you’ve conducted your analysis, you’re ready to take it to the next step: humanizing past technical actions. Consider what the previous attempt might have been like for different teams and people. Remember what it was like when you rode the help desk, when you were sitting in the data center on a weekend or when you were working as a dev lead under an impossible deadline. Chances are you’ll remember the common frustration was external direction not taking people into account. DevOps success is primarily about people. Align your DevOps reboot with the humans on your team and the processes will follow.

    For instance, your company may have hired outside consultants to “rub a little DevOps on it,” and it’s possible they evangelized a lot of dogma. “Do exactly these things, this exact way, or you’ll fail at digital transformation,” they might have said. There may have even been FUD and frightening charts. Perhaps they said everything would be neatly wrapped up in six months and you’d achieve a high-performing, blended, and fully active nirvana within a year. “You could be the next Netflix!” You’ve probably heard this story several times by now, and if it’s happened to you, know you’re not alone.

    But your approach this time will be different because it will be yours. You will have noted sharp edges needing to be filed down. The broader team will be integral to conversations from the get-go. Internal champions won’t be under the influence of ballyhoo, fancy decks or hard sells. Your team will have a list of concerns but also possibilities reflecting a shared interest in modernizing operations. One look at salaries for job postings with “DevOps” in the skill set has likely piqued more interest from your team than a year ago.

    Open conversation has always been the hallmark of good forensic analysis. Express what you think went wrong the last time and encourage frankness. Acknowledge concerns—previous outcomes may have validated many of them. Your team will be looking for proof you’ve given thought to a process that might—in extreme circumstances—temporarily affect availability or lead to a security concern. Maintain an open invitation for everyone on the team to be a part of the conversation and hear their concerns. And wherever possible, lean toward person-to-person communication. You’re changing hearts and minds, not reviewing governance policy.

    Third: Unite Your Team by Confronting Obstacles Together

    Don’t perform a shotgun wedding between ops and dev. Administrators and developers are drawn to their technology foci for personal reasons and interests. One of the most cited reasons for unsuccessful DevOps plans is a directive to homogenize the team, followed by shock this didn’t work. Developers are attracted to and rewarded for innovation and building new things, while admins take pride in finding ways to migrate the mission-critical apps everyone forgets about onto new hosting platforms. They’re complementary, integrable engineers, but they’re not interchangeable cogs.

    Contrary to popular opinion, telling developers they’re going to carry a pager for escalation doesn’t magically improve code quality and can slow innovation. They may even quit, even in this chaotic economy. And telling ops they need to learn code patterns, git merge and dev toolchains will be an unwelcome distraction not related to keeping their business running or meeting their personal review goals. They also may quit.

    It might be helpful to share with your team the simple idea you embrace: Unfounded stories of friction between dev and ops aren’t about the teams. They’re usually someone else’s war story about the organization, technology or process obstacles dividing them. At its heart, DevOps is about clearing these obstacles, not replacing them with new ones.

    By 2020, you’ve likely met someone from a team who had an opportunity to work based on tenets of DevOps, and they likely have no intention of going back. They’ll tell you they built or modified interaction models and evolved their deployment methodology organically. They streamlined the way code is built, improved testing at the bench level, staging and production. Even some companies needing to maintain specific waterfall processes for business or regulatory reasons may benefit if the transition is organic and incorporates their specific needs.

    Fourth: Set Your Plan in Action

    The last step—and this time, hopefully, the easiest—is to set your plan in motion, especially if you’re doing so at a smaller scale with better instrumentation than before. Ops teams and developers are people of action. We like to research, test and discover, but we’re happiest when our work sees production and we have a positive impact on the business. And often with initial forays into DevOps, stymied progress is what makes teams give up. By tracking ops and business metrics together, all the stakeholders will be able to share a sense of progress toward the overall goals, even when you break a few things along the way. Think of it as fail fast insurance.

    For example, consider adding development metrics and business metrics alongside your traditional infrastructure data. Track rate of change, error rate over time, deployment events and PR requests to get a measure of release times. Share your application performance management (APM) metrics with the whole team—real-time user-to-app-code-to-infrastructure-to-resources data sparks insightful cross-team conversation. But you should also track metrics affected by ops quality, including visitor time on site, page abandons, service desk ticket rate and CSAT. You likely already have the data you need, but perhaps it’s siloed in different systems. If your dashboards combine data mirroring the mix of teams and infrastructure flying in formation, it’ll be much easier to identify issues, evolve your initial plan to suit your unique environment and improve overall DevOps collaboration.

    And this time, you’ll be able to see code check-ins, unit tests, builds, pipeline progress, deployment to staging and prod, and follow-through on performance, issues and anomalies. If the team gets nervous trying something new, you’ll have actionable data, the production feedback loops developers crave and common charts everyone agrees on. It’ll be easier to know your DevOps effort is working and to keep pushing forward as you address unexpected challenges.

    You’ll Know It When You See It

    I made a joke in a talk once that DevOps is a lot like being in a relationship: You kind of fall into it. You learn about it, adopt some of its practices and enjoy the experience when it works. You don’t set out to “get in love” and likewise don’t set out to “get in DevOps.” Rather, you find yourself in a situation developed with experience over time, and you wake up one day and realize, “Hey, we’re a DevOps shop!” That’s why you can’t buy it in a box, and nobody else’s will be like yours. It’s not about the technology, it’s about the humans working together to manage it.

    Maybe this is the best reason to give DevOps another shot. It didn’t spring from a consulting team as a framework to drive engagement or from a vendor with an appliance requiring admins to bend to arcane workflows. It came from people; from developers and administrators who fought the same operations challenges we all have and who wanted to share what they learned. And this is why, outside of a bit of time investment from your team, DevOps is free. It’s made to help, not to sell you anything.

  • An Inconvenient Truth about DevOps

    An Inconvenient Truth about DevOps

    In a company’s early stage, the focus is on producing features for the customer. When the focus is tangible value, it’s natural for a software-as-a-service (SaaS) startup to fill its ranks solely with application developers. But when should a company invest in development operations, and at what level? If it has enough capital to hire four developers, should one of those four be DevOps?

    Over the last few years we’ve continued to wrestle with this question. The value from an app engineer was so tangible, but DevOps was something else. Though no visible product was created, DevOps produced many accelerants. Incorporating development operations promised to make the other engineers faster, more effective and happier, but we always feared a sacrifice in features. The decision was similar to setting up robust automation testing—the value accrues, but the upfront cost is a hard pill to swallow.

    We did it too late, and learned some interesting things along the way.

    The Benefits/Advantages of DevOps

    The benefits to incorporating development operations early on are many. As an immediate ROI, DevOps will add a lot of agility to your team by allowing your other engineers (and your quality control team) to focus on what they do best: create your product.

    What is interesting is that the role always exists implicitly within your development team, but is more effective when explicit. If added early, this position can accelerate your team. If not added in time, each developer will play the role in part. The biggest difference between the traditional engineering role and DevOps is the context required: It is possible for a DevOps person to not really know the business rules of your system and still add tremendous value. This means anyone skilled in the craft can be put to work, which allows for quicker onboarding.

    To better illustrate this, let me start by explaining deeper the importance of DevOps in a startup (and in companies of all sizes, actually). By implementing DevOps practices you will enable quicker product iterations. This is vital for a startup, as much of the success of a new venture depends on meeting release dates and getting new versions of the product in the hands of your users as quick as possible. Also, configuration management (CM) tools provide an inventory of all your software and configurations as a living documentation. Your infrastructure setup will be more predictable, you’ll have a better understanding of your stack. Centralized logging solutions and performance monitoring tools will enhance your monitoring and alerting. In short, investing in DevOps in the beginning yields valued dividends over time as you scale.

    How DevOps Has Impacted Our Business

    Establishing DevOps deeply improved our release process. We used to release new versions of our product much less frequently, taking  30 to 40 hours per month of a developer’s time. Now we are able to release much more often—at least three times a week. In the past we would barely release three times in the same month! Now it takes just a few seconds of a developer’s time, only requiring the push of a button in our continuous integration/continuous deployment tool (CI/CD) Atlassian Bamboo. Builds are run and the application is deployed continuously to our test environments over the course of a few days. After successful rounds of testing performed by our quality control team, we are then ready to push our new release to the production environment by hitting the little icon named “Deploy.” It is enabling.

    This successful implementation of a CI/CD strategy also added much more transparency to our pipeline. Now everyone can see in a central place all the metadata about a release, including what product version is deployed to which environment, what is being deployed and by whom.

    Another result we achieved directly with DevOps was agility in setting up our cloud infrastructure. In the old days we would have to log in to our cloud provider control panel and manually spin up new instances, waiting long minutes for them to start only so we could then secure shell (SSH) into them and make all the necessary installations and apply the required settings. Now, we can simply a run a script in Ansible (our CM tool) that sets up an entire environment for us. And since it is much cheaper now to provision and configure new infrastructure, we are now able to create an entire new process for testing new epics completely segregated from our main infrastructure. This has greatly improved our development processes, allowing for more flexibility, speed and control when developing and testing new product epics.

    DevOps Excellence

    During the past year, we have come across different DevOps professionals and learned a lot about the good, the bad and the ugly DevOps engineer. More importantly, we’ve learned what makes a great one. Topping the list of attributes is extreme attention to detail. Managing an entire infrastructure isn’t easy; it has a lot of moving parts. Being able to not get lost in the details is essential.

    A great DevOps engineer also possesses strong process orientation and a passion for automation. To be supportive to the engineering team, he or she needs to understand deeply the current engineering processes and think of ways to streamline and automate them. The questions the DevOps engineer should ask include:

    • What is our build process?
    • When do we deploy to QA?
    • How do we notify the Quality Control team that a new version is ready to be tested?

    You need someone who can challenge the enterprise status quo and help to define best practices for developing and deploying systems.

    Finally, as happens with the definition of the word, there is no definitive answer on where a DevOps team or individual fit in the engineering organization of a startup. At our company, the DevOps engineers report to the Enterprise Architect, who reports to the CTO. In other organizations we have seen DevOps engineers report to the Head of Infrastructure (who reports to the CTO), or report to the Head of Infrastructure (who in turn reports to the VP of Engineering).

    It really doesn’t matter where it fits in your company architecture. First, define your company and vision, then define your org chart. Just remember to include a box for your DevOps engineer from the beginning!

    About the Author

    Rafael_NevesRafael Neves, head of Enterprise Architecture at ALICE, has more than 8 years of experience with technology, having worked in the financial industry both in the sell-side and the buy-side for most of his career. Prior to joining ALICE, he served as head of Engineering at investment advisory startup Monetar. Before that, he was the head of IT Quality & Process of Brasil Plural, engaging in prominent projects such as the technological structuring of the bank’s Broker Dealer in New York. In 2010 he became the head of Algorithmic Trading in the first electronic trading desk in Brazil at Agora CTVM, the leading brokerage house in the Brazilian Exchange which he joined in 2008. Rafael earned a Bachelor’s Degree in Computer Science from Universidade do Estado do Rio de Janeiro.