staging-devopsy.kinsta.cloud

Tag: devops

  • What Is Resilience Engineering?

    What Is Resilience Engineering?

    Admitting things will go wrong isn’t easy for anyone or any team. But modern engineering practices have moved beyond this fear, giving birth to a new practice in DevOps and site reliability engineering (SRE) known as resilience engineering.

    Resilience engineering today isn’t thought of as a function. However, just as DevOps was a description of culture before it was a role and site reliability was an extension of operations before it was a focus, I wouldn’t be surprised if resilience engineering became a function in the new future. The first question most will ask however is, “Isn’t this just SRE?” The purpose of the term is to change the focus from simply reacting to incidents to developing long-term response strategies for them.

    Because the expectation in these environments is that things will break, resilience is the responsibility of existing DevOps and cloud operations teams. When applications and services do break, a “fly by the seat of your pants” response strategy will not work.

    A Focus on Frameworks

    Resilience engineering, while rooted in engineering practices, is largely focused on building strategies and a framework for their execution. This leaves the process of building resilience into a largely unestablished system in part because each system is unique. And, how you respond to issues in that system will likely be unique, even if the management plane that reports issues is not.

    The job of resilience engineering is to:

    Establish procedures, habits and decision trees

    When things break, fight is the only option. Operators and on-call engineers need to address issues in a systematic and repeatable way and do their best to remove emotion and fear from the equation. This not only helps triage and resolve issues, but it also makes sure the activity associated with the issue leads to meaningful insights in post mortems and future collaboration. Part of that is establishing habits and decision-making processes for those who are on-call. The processes help prioritize what to focus on, help catch details because details are critical.

    Be data-driven

    Resilience engineering must rely on data. This is another place where traditional SRE practices grow with a focus on resilience. In typical SRE environments, the focus is on the now, using real-time dashboards of the current state. When you think about resilience you are thinking about the past’s impact on the future, not the now. The only way to do that is to make sure the data supports it; thus, part of resilience engineering is making sure the data is there. Instead of data silos that most organizations have across their delivery chain. Resilience engineering should ensure that telemetry across the entire delivery chain is captured, correlated and shared. The reason this is critical is that what happens early in the delivery chain directly impacts incidents. That activity can be the source of answers, it can be the triggers for rollback, or it can be the clarity needed to prevent similar issues in the future. Without continuity between each stage of the delivery chain, it’s easy to miss correlated events that can lead to more systemic problems.

    Engineering out of reproducible incidents

    For most, the best part of resilience engineering is taking what is learned from previous incidents and finding ways to automate future resolution. Learning from data and having consistency in habit leads to the ability to create runbooks and automate remediation for known issues. Often incident response audit trails can read like playbooks for addressing issues of a particular type. When the resolution is not directly related to code and the potential of issues to surface again in the future is inevitable, being able to build intelligence to address it saves waking someone up at midnight and much shorter impact on customers.

    The Resilience Stack

    Organizations looking to embrace resilience engineering need to have a toolkit built for it. It’s pretty straightforward but worth highlighting. The resilience stack will include:

    1. Observability and/or monitoring tool.
    2. Incident response tool.
    3. On-call strategy documentation.
    4. Post mortem process and documentation.
    5. Documented processes including recommend response steps.
    6. Path to automation.

    For those with a relatively mature and automated environment, the next step is chaos engineering—embracing chaos as a way to get ahead of incidents before they happen in the wild.

    Get your markdown skills to maximum level. There is a lot of documenting that needs to happen with comprehensive resilience engineering. But these documents should not be shelf-ware—they should be living and ultimately lead to the implementation of automation or feedback to development.

    As for monitoring, observability and incident response tools, it’s not enough to simply implement them. Knowing how data will be collected, consumed and actualized is also necessary. So is establishing an on-call strategy with purpose, not just because having everyone on-call is the “cool thing to do.”

    It may seem obvious to say that organizations want system resiliency. What is not obvious is how to execute it. When organizations see the gaps (and are often embarrassed by them), they understand that resilience is a focus for either current functions or new ones in the future. That is why it’s worthwhile to talk about resilience engineering and what makes it effective.

  • Survey: Cloud Security, DevOps Emerging as Enterprise Priorities

    Survey: Cloud Security, DevOps Emerging as Enterprise Priorities

    A survey published today by 2nd Watch, a provider of IT services, finds that in the wake of the COVID-19 pandemic, cloud security and DevOps have emerged as the top two priorities for large enterprise IT organizations.

    The survey queried more than 100 IT directors working at companies with at least $500 million in annual sales and IT budgets of at least $50 million per year, Three-quarters of respondents (75%) said they are prioritizing cloud security, followed by cloud-native culture change, also known as DevOps, (60%) and conferencing/collaboration (51%).

    Chris Garvey, executive vice president of product for 2nd Watch, said the report shows that not only are more large enterprises accelerating cloud adoption, but the projects being launched are also more strategic to the business.

    The survey finds 60% of respondents said they are prioritizing projects with potentially large payoffs over cost-conscious projects. Nearly half (47%) said now is the time to position their company for the long haul, while 39% said they are accelerating the use of the cloud to deliver digital products. As part of those efforts, more than a third (34%) said they are accelerating the migration of applications to the cloud.

    A total of 93% of respondents use at least two cloud platforms, with Microsoft Azure being the most widely employed.

    Cloud computing platforms, however, are not without their challenges. Most respondents (82%) said they’ve experienced cloud-related challenges, with 77% reporting those issues have caused them to alter their cloud strategies. Nearly half (46%) said experiencing cloud security-related challenges, while 48% said cloud computing turned out to be more expensive than initially anticipated.

    The top challenges identified are providing remote workers access to corporate systems (63%), providing remote worker support (57%) and conferencing/collaboration systems that haven’t worked as expected (47%). Half said they are accelerating the use of the cloud to support remote employees, with 58% expecting at least half of their company’s employees will become full-time remote workers in 2021.

    Overall, nearly two-thirds (64%) said their IT related budgets have stayed the same or grown since COVID-19 began, and 59% said their cloud budgets would increase over the next 12 months. A total of 80%, however, acknowledged they are concerned COVID-19 will continue to impact their IT strategy and only half (50%) said they were confident in their organization’s ability to adjust.

    Primary areas of focus over the next 12 months include databases (42%), internet of things (39%), data warehousing (35%), artificial intelligence/machine learning (34%) and data lakes (26%).

    Garvey said large enterprises are clearly looking to take advantage of their deeper pockets to accelerate digital transformation initiatives at a time when smaller rivals may not be able to invest. However, because the pandemic has impacted some verticals more adversely than others, the level of digital business transformation occurring across different vertical sectors is uneven, he noted.

    It may be a while before the winners and losers are identified in the wake of the pandemic. However, it’s clear large organizations are betting on IT now more than ever to differentiate themselves. As large organizations assess the damage from the pandemic, it’s likely that the future of many of these companies will depend on the degree to which they can adopt a wide array of not just emerging technology platforms, but also the processes required to master them.

  • TechStrong TV: ‘The Startup Community Way,’ With Brad Feld

    TechStrong TV: ‘The Startup Community Way,’ With Brad Feld

    Brad Feld, co-founder of Foundry Group and Tech Stars, recently joined us on TechStrong TV to talk about his new book, co-authored by Ian Hathaway, “The Startup Community Way.” Brad is one of my oldest friends and has a lot of great insight into the tech community and the shift in the balance of power in many organizations, and his latest book discusses that at length and more.

    The video is immediately below, followed by the transcript of our conversation. Enjoy!

    Transcript

    Alan Shimel: Hey, everyone, thanks for joining us on this segment for TechStrong TV. I am, like, thrilled beyond thrilled to be joined by an old friend of mine—not that he’s old, but we’ve known each other a very, very long time—my friend, Brad Feld, who really needs no introduction in any kinda tech kinda discussion. Hey, Brad—welcome.

    Brad Feld: Alan, it’s great to be here. Awesome to see you.

    Shimel: It’s awesome to see you, my friend. I haven’t seen you in too long, and I don’t know when I’m gonna see you in person again with the current state of affairs, but I hope it’s soon.

    Feld: I get virtual Alan and you get virtual Brad.

    Shimel: That’s the best that we’re gonna have to do. So, Brad, we have you on here today because your book came out, I guess it was last week it came out officially, right? And it’s called “The Startup Community Way.” It is a sequel or follow on to “The Startup Community” book that you originally authored how long ago? That had to be, what, seven years ago was the first book?

    Feld: Yeah, “Startup Communities” came out in 2012, and along with the publication of “The Startup Community Way,” we came out with a second edition of “Startup Communities” that has some updates to it and some things that I got wrong the first time around fixed. So, it’s nice to freshen up.

    Shimel: Well, we’re gonna talk about those. Yep, and we should mention, Brad, that you have a coauthor in this “The Startup Community Way” book, and that’s Ian Hathaway. And Ian may be less entrepreneurial or less experienced in the VC entrepreneur world, but very experienced in research and kind of doing, you know, looking at this scientifically, if you will.

    Feld: Yeah, he was a really good coauthor, he’s become a close friend, and part of the thing that was good about it was, we do have different frames of reference. So, as we talk through and work through the book and work through different ideas around the book, you know, pressing against each other from different frames of reference really generated, I think, much better ideas and much better writing.

    Shimel: Excellent. So, Brad, I’m gonna make some assumptions, here. First of all, our audience is a very geeky, techy audience, right? We cater to digital transformation, DevOps, cloud-native, open source kinda stuff, and of course, cyber. They know who Brad Feld is. They’re familiar with tech stars, they’re familiar with startups, they’re probably even familiar with the term startup community, which you kinda initially coined with the book, right? So, I don’t want to spend all of our time sort of laying that foundation. They’re familiar with who Brad Feld is as well.

    And if you’re not, I’m gonna tell you really quick. I sold my first company to Brad in 1997. He’ll tell you I was wearing a stupid sports jacket, but we’re not even gonna talk about it. [Laughter] He’s been at SoftBank Venture Capital, Mobius, Foundry Group, started Techstars, one of the kind of forces behind—how do you pronounce it? National Nitwit is—what does it stand for, Brad?

    Feld: NCWIT, National Center for Women in Information Technology.

    Shimel: Yep, and, you know, one of my favorite things you’ve done. But, I mean, beyond—we could go on and on, but let’s not. Brad, I started reading “The Startup Community Way,” and I have some issues, questions, areas I want to jump in on with you if it’s okay.

    Feld: Sure. So, obviously, with your initial “Startup Community,” you had what you coined the Boulder Thesis, and there were four main points in the Boulder Thesis. Number one, though, and sort of primal to me was that, for startup communities to thrive, they need to be led by entrepreneurs, right? These entrepreneurs had to have a long-range kinda commitment to the community, and let’s stop right there for a second.

    Shimel: I noticed in this, in the new book, you kind of made a realization that, in informing that, we set the entrepreneurs up as sort of the alpha predators, as the top dogs on the food chain, right? But in doing so, it might have created a little bit of us versus them between entrepreneurs and the other, I’m not gonna say equal participants, but vital participants in this equation of a startup community. The workers of these companies who go to work at entrepreneurs, universities, government agencies—the community, right? It’s not just entrepreneurs.

    And I think one of the things you’re seeking to address in the book is to kinda ease that tension, the us-versus-them tension, correct?

    Feld: Yeah, that was a mistake I made in the first book, and it was a mistake of language, not of intent or description. So, in the first book, I made the strong assertion that the leaders of a startup community have to be entrepreneurs and, in the absence of a critical mass of entrepreneurs playing leadership roles, your startup community won’t grow and evolve.

    I then labeled everyone else a feeder, and my intention was not to have leaders be one up on feeders—you know, one up, one down relationship—but just different. And I tried to categorize them differently and spent a fair amount of time in the book describing what leaders do and what feeders do. And the miss was, there’s a lot of people who play leadership roles in startup communities who are not entrepreneurs, and in the new book—and I also went back and updated the second edition of the old book—I now call them instigators. And the idea of an instigator is that they are playing a leadership role in the startup community, and that’s a very powerful notion.

    So, essentially, people now are classified as leaders and instigators, and the organizations are feeders, and that’s really important, because the organizations tend to be hierarchical. They tend to have their own agenda in addition to the agenda of the startup community. And the fundamental goal of a startup community, pure and simple, is to help entrepreneurs succeed. And the feeder organizations, part of their goal as organizations are to help entrepreneurs succeed, but that’s not their only goal.

    We also distinguish now between the notion of a startup community and an entrepreneurial ecosystem. A startup community, at its core, exists to help entrepreneurs succeed, and an entrepreneurial ecosystem has, at its core, a startup community, but it’s a much bigger thing, and it engaged all of these other organizations around their goals and how they engaged with entrepreneurship.

    So, I think we’ve done a better job in “The Startup Community Way” of talking about leadership and who provides leadership and the people providing the leadership in the startup community being both the leaders, the entrepreneurs, and the instigators, people who aren’t entrepreneurs, but who are playing a leadership role. And then the organizations, the other actors who contribute to the startup community but don’t control it, don’t try to organize it, don’t try to run it, just participate in it.

    Shimel: Excellent. You know, Brad, there’s a lot of analogies there to what we see in the DevOps world, right? The developers have become the entrepreneurs of the first edition of startup community, where it seems the rest of the DevOps ecosystem revolves around these developers, and look, developers are impossible to hire. They’re, as you know from your companies, they demand a lot of money, they want a lot of say over their environments, their culture, and everything else. They’re kinda calling the shots, and the rest of the world kind of revolves around it.

    But also, a lot more is thrown on these developers’ shoulders in terms of what—they’re no longer responsible just for code, they’re responsible for deployment, they’re responsible to make sure the testing is right, you know, for that whole software factory. They, in essence, run the factory. And a similar kinda thing has happened in DevOps where we say, “Hold on—yes, the developers’ role is a very important role, but so is that of the cyber person, so is that of the SRE, so is that of the tester. And literally, it does take a community, and it’s caused a bit of a realignment, if you will, within how we look at DevOps and cloud native and continuous deployment.

    I wonder, you know, carrying that analogy out, Brad, though, I think a lot of our audience out here, they tend to interchange entrepreneur with technical entrepreneur, and I wanted to talk to you about the role of the business entrepreneur for my own selfish reasons, but you know—and you have a ton of experience on this. When we talk about entrepreneurs, Brad, how much of it is, you know, so a technical entrepreneur, the kind of person who goes on to be the CTO in their startup or in their company versus people who come from the business side of things, right? And what’s the right mix, or what’s a—I don’t know if there is a right mix, but what’s the right formula for when we look at the entrepreneurs within the greater entrepreneurial ecosystem, within the startup community, between technical entrepreneurs and, let’s call them, business-orientated entrepreneurs? Make sense?

    Feld: Well, they’re both—it makes total sense. They’re both essential. And when I talk about entrepreneur, I don’t really distinguish between the two. I think there are many different roles that founders or entrepreneurs play. And, for a lot of people, the word entrepreneur tends to be triggering. Like, it used to be something that was very well understood.

    Today, the word entrepreneur gets used, I would say, almost indiscriminately in a lot of different contexts. And, to your question, I would come back to the notion specifically of a founder. A founder of a company, somebody who is one of the people who helps create the company from the very beginning, and you need a combination. You need technical founders, technical entrepreneurs. You need business founders, business entrepreneurs. Most companies generally have more than one co-founder, but there are definitely successful companies with one founder.

    But generally speaking, if you have more than one founder, especially if you have a combination of a business founder and a technical founder, you can make a lot more progress a lot quicker in many cases. And if you have three or four founders, I generally try to encourage people to have at least an equal number of technical founders to non-technical founders, and preferably, more technical founders than non-technical founders. And, you know, Alan, you’re humble. I mean, you talk about yourself as the business guy, but you have very, very deep technical experience at this point. Even when I met you when you were running your first company in the late 1990s, you had deep technical experience.

    So, the technical founder doesn’t necessarily mean just somebody who writes code, and I like to shift the language to be product-oriented instead of technical. So, if you think about three founders, three co-founders, the idea that two of them are focused on product and one of them is focused on the business, and the product and the business obviously overlap with the customer, and so, all three of the founders are paying attention to the customer, the evolution of what you’re trying to do from the very beginning can move a lot quicker.

    By the way, there are a lot of very, very good technical founders who also have strong business sense in the same way that you’re a strong business person that also has strong technical sense. So, it’s not cut and dried, and you’re not like, “Oh, I’m in this box and you’re in this box.” I try to encourage entrepreneurs to think more broadly about what they’re doing and how they’re doing it.

    Shimel: Excellent. Hey, I’d like to shift a little bit away from the entrepreneur because they get all the press, anyway. I want to talk about something that was really highlighted in your book, and that is the role of, within the community, within the ecosystem, the role of universities and the role of government, the role of these hierarchical groups as you referred to them.

    Let’s talk a little—and I’m gonna bring it home to what I see here in South Florida, for instance, but Brad, you know, (a) it’s an important role they played in this big picture, but what optimally, what can the government do optimally, for instance, to help you—there’s federal, there’s state, there’s local—you know, where do you see it?

    Feld: You have to be somewhat granular, and you also have to be focused on the specific place that you’re at, whether it is local, state, or federal or national governments. Interestingly, in the first book in 2012, I basically punted on this issue. I said, “The best government can do is do no harm to the startup community.” And, you know, I would say that was a combination of me not really having a particularly clear view of what government could have along with me kinda punting and being lazy about digging into it—based on my own experience, my own experience in Boulder, for example, is that the local government basically pays no attention to entrepreneurship and doesn’t really understand how to engage it in an effective way.

    The state of Colorado government, actually, has done a pretty good job, and there have been a number of things over the years that the state of Colorado has done around this and then, you know, our federal government in the U.S. ebbs and flows. Sometimes there are some programs that are incredibly helpful and oftentimes, there are things that either get in the way or are counterproductive.

    So, I’ve come to a place where what I think is important for government at any level to start with is to understand what their goal is. And I’m gonna come back to this statement I said earlier, which is, the goal of a startup community is to help entrepreneurs succeed. So, if government wants to engage in the startup community, their goal should be to help entrepreneurs succeed.

    Now, at a local level, that often means that the best way to do it is an instigator—gonna use that word again—who is a person who works for a local government who actively engages as a leader in the startup community. So, they’re not actually bringing government so much to the startup community, but they’re, in their role in government, they may have a full-time job to help with economic development or developing the entrepreneurial ecosystem or whatever it is. Like, their first step should be to become part of the startup community as an instigator rather than show up as government and say, “Hi, I’m from the government, I’m here to help.”

    Shimel: Mm-hmm.

    Feld: One of the things the government really struggles with is allocating capital. Government has a lot of capital, as we’ve just learned from the COVID crisis. You know, overnight, the federal government allocated or deployed $2 trillion, and it looks like it’s gonna allocate another $1 trillion across their society. And a lot of that money went towards helping, quote, small business, where government thinks of small businesses and entrepreneurial businesses as the same.

    If you use that lens, though, and you look at how that money was allocated, it was primarily allocated through two vehicles, PPP loans and EIDL loans. It was incredibly inefficiently allocated, and as a result, some companies got financial support, others didn’t. And it was done in this very, very sort of explosive way that may have had some very powerful short-term impacts, but it’s unclear on whether it has medium or longer-term impacts.

    One last sort of comment on governments, state [Audio skips] governments over and over again. We need more venture capital here, we need more capital here, and we need to do things to get more capital here. In “The Startup Community Way,” we actually defined capital as having seven different flavors, where financial capital was one. Because generally when people talk about capital, they’re talking about money, and this is another place where governments can really help is to think about what capital the startup community already has that’s not financial capital—what kind of intellectual capital, what kind of network capital, what kind of infrastructure capital exists and what more is needed. And then try to figure out how to use the resources of local or state government to amplify those types of capital that ultimately then is a positive reinforcing loop to attract other sources of capital.

    So, unfortunately, it’s—I think, for government, it’s nuanced, and a lot of times government is looking for a playbook and a solution, like, “I just need to do the following four things and then good things will happen.” And this is essential to “The Startup Community Way” where we talk about startup communities now as complex systems.

    Shimel: Yeah.

    Feld: And one of the things that many organizations have a lot of trouble interacting with—especially government, but not exclusively government—is complex systems.

    Shimel: So, let me talk a little bit about complex systems here in South Florida. I know you’ve been down in Miami a few times, you’ve had a chance to see sort of the Miami startup scene and, you know what, in four or five short years, it’s actually come a long way. You know, it’s the gateway to Latin America and they talk about all that, but more importantly, there are some really concrete programs, the Knight Foundation, a few other organizations as well as local government has instituted it, and we’re beginning to see a startup community take hold there, in my opinion. It’s not bolder, it’s not awesome, but it doesn’t have to be, it’s Miami, and it does it in its own unique Miami way.

    But South Florida is more than Miami, right? You basically have a tri-county or three city sort of metro area of Miami, Fort Lauderdale, and West Palm Beach. Taken together, I forget if it’s the six or seventh largest metropolitan area in the U.S., right, between these three counties—Miami-Dade, Fort Broward, and Palm Beach County. A tremendous amount of universities, we haven’t even talked about universities yet, but we have University of Miami and FIU and FAU here. Lots of universities—universities that are, you know, in your first book when you talked about the role, you know, they do serve as anchors.

    I think what holds us back in the South Florida area, though, Brad, is that we have shoguns, right? I remember when your business card used to shogun, remember those days? [Laughter] But we have shoguns here every 10 or 15 miles, each little town or incorporated village is afraid that the next one is gonna do more, better than them.

    Here in my little neck of the woods, Boca Raton and Delray Beach constantly—they’re right next to each other—constantly banging heads. Boca has the universities, maybe a little more capital. Delray has a great sort of startup scene brewing and they do have local economic development and a number of co-working places and stuff like that. But they can’t seem to get their act together to work—and these are just two little, piddling towns, to tell you the truth, right? If they would put it together, they might have something—but they can’t, they’re too busy competing. And it’s the same thing up and down this coast, right?

    So, you have an area with a lot of universities, a lot of capital, a decent amount of tech talent—I mean, not deep enough, by any means—and certainly, many entrepreneurs. But they’re at loggerheads. How do you—in creating this entrepreneurial ecosystem, how do you overcome this sort of petty jealousy, these shoguns fighting for supremacy?

    Feld: Well, you have to start from a perspective of playing a positive-sum game, and what you’re describing is a classic zero-sum game, where there’s winners or losers.

    Shimel: Yep.

    Feld: And, you know, the ones that we’re used to in terms of zero-sum game and election is a zero-sum game, somebody wins, somebody loses. Sports of events, most of them, zero-sum game—winner, loser, sometimes you tie if you play soccer. But, you know, for most games, there’s a definitive winner or loser. You don’t wanna play a zero-sum game

    You wanna play the opposite of that, which is a positive-sum game where the cliché would be a rising tide lifts all boats, right? You’re helping each other over time sort of building something that’s more and more successful. And, in defining startup community, you can define startup community however you want in terms of geography. You can define it in a little town like Boca or Delray. You can draw a bigger circle around it and call it the Greater Miami Metro Area or whatever you wanna call it.

    By the way, you said something earlier that’s really important is that you don’t need to create or emulate somebody else. Boulder is Boulder, Miami is Miami, Greater Miami is Greater Miami, Boca is Boca—like, you already have an identity as a city. But the key is to try to work with the people who are close to you to build a broader and more robust startup community. And, interestingly, if you’re taking this approach and playing a positive-sum game where you help each other versus you compete for resources and you compete to win or lose in sort of an inappropriate way or an unhelpful way, it doesn’t really matter.

    The very specific example I’d give you is that, does it cost anything to travel from Delray to Boca? Do you have to pay—

    Shimel: You could walk.

    Feld: – you could walk, right? You don’t have to pay a tax, you don’t have to have somebody, you know, stamp your passport to get from one place to another. I mean, you really are part of a—

    Shimel: Not yet.

    Feld: – not yet. You’re part of a collaborative collection of people, and the goal should be that you wanna encourage cross-fertilization between these communities and you wanna encourage amplification of what’s going on and get critical mass around it.

    Now, there’s nothing wrong with local pride, and I can use Boulder and Denver as really good examples of that. Boulder and Denver are both very, very vibrant cities. Boulder is 100,000 people, Denver is 2,000,000 people. They’re about a 30- to 45-minute drive apart from each other. They have independent identities, but there’s an enormous amount of collaboration between the two, and that’s very, very, very powerful.

    Shimel: I mean, so, I’ve done Meetup groups in Denver and Boulder. You know, we started one with the Jump Cloud folks called IT as Code. The first meeting was down in LoDo. But we had people from all over, from Boulder and everyone else drive in, and we had a great meeting at one of the breweries there—good times.

    I’ve started a bunch of Meetup groups here in South Florida, and we’re constantly, “Jeez, we have to do this one in Miami for the Miami people. We need to be down near Fort Lauderdale-Hollywood this time, or out at the university out West there to attract that Broward crowd.” There isn’t that sense of community that the rising tide lifts all boats, and I’m hoping that books like “The Startup Community Way” kind of make their way into the stream here, the mainstream of what these people are thinking about.

    We even see it, Brad, with—so, we have the South Florida Technology Association, then we have the Palm Beach Technology Association. There’s several counterparts in Miami. They even compete at such a—and it’s a petty competition, frankly.

    Feld: Well, they could really change the game in the region by deciding to collaborate, and they can have separate organizations with separate memberships and separate goals even if they’re in the same place because there’s no need for there to be one monolithic thing. In fact, you probably want a bunch of different things. But instead of viewing it as an, “I win, you lose,” they’re all trying to help entrepreneurs succeed. And in the context of that—again, the instigators, the leaders of those organizations, right, those organizations, even if they’re comprised of entrepreneurs, they’re still feeder organizations, right? The organization themselves is a feeder supporting entrepreneurs. The people in those organizations who are playing leadership roles can play a leadership role in the startup community, which is separate from their organization. Their organization is not the thing that’s organizing, managing, running the startup community. It’s just another participant in this.

    And so, changing that frame of reference for humans is hard, because we’re used to competing, and you know, we’re—

    Shimel: No, it’s like “The Highlander”—there can be only one. [Laughter] Right? And it’s a problem—I get it.

    Feld: Well, and changing that is important and, you know, it’s one thing to say it’s important to change; it’s another thing for a bunch of leaders in a startup community to say, “You know what? Enough of this. We don’t need the segmentation, we don’t need the competition. Let’s all pull together even though we’re addressing different things, and we have some overlap. We’re trying to do something together that makes our place better.”

    Shimel: Fantastic. Brad, we’re almost out of time. I wanted to leave you a couple minutes at the end here for our audience watching. If you had the three biggest takeaways from the book that you want people to go home with, what would you say they are?

    Feld: The first is the distinction between a startup community and an entrepreneurial ecosystem and the reinforcement that the goal of the startup is to help entrepreneurs succeed, and you can define everything from there.

    The second is that a startup community is a complex system, and in a complex system, there is no deterministic outcome. There is no playbook. There is no set of rules to get from Point A to Point B. A simple system would be making a cup of coffee. You put beans into the machine, you get coffee out. It might not be a good cup of coffee, but it’s a cup of coffee.

    Shimel: Coffee it is.

    Feld: Coffee it is. A complicated system would be manufacturing a Boeing 787 airplane. Once it’s designed, the rule book’s now really big, but you put parts at the beginning and at the end comes out a Boeing 787.

    A complex system would be raising a child—and you’ve raised two. And you know that on day one of the child, what you tell the child to do and what you aspire for the child to do at age 21 is not what’s gonna happen. Every little thing you do, the child evolves and changes and grows and develops and all that stimuli is positive and negative along the way. And at the end, the child is whatever the child is. But it evolves in a way that you can’t predict. That’s what a startup community is—you cannot predict what that outcome is and you can’t control the outcome.

    The last—and we cover this in the book and there’s several examples. I gave one which was the notion of capital not just being money and defining it as the seven capitals instead of just financial capital. Another would be something we could call the measurement trap. Everyone in a startup community feels the need to measure things, and this is especially true for government, this is especially true for nonprofits like the different associations that you probably described.

    They’re measuring constantly—number of companies created, number of unicorns, dollars raised, number of jobs. These are things to measure, but they’re not the important things, they’re the easy things. And the really important thing that happens in the growth and development of a startup community and complex system is not the parts, not creating more pieces, it’s the interaction between the pieces, interaction between the parts. And measuring that interaction is really, really difficult, but that’s where all the power comes from.

    Shimel: Got it. Love it. Hey, Brad, first of all, thank you so much. I know you’re crazy busy with promo-ings on the book and everything, so thanks for taking the time to come join us here on TechStrong TV. Best of luck with the book. We should mention it’s available on Amazon, it’s on all the usual places where one buys books today. Not going to book stores very much, unfortunately, but yes. So, it’s “The Startup Community Way,” Ian Hathaway, Brad Feld—check it out. It’s available in Kindle and hardcover at this point. I don’t think a paperback is out yet, right?

    Feld: No paperback yet, just Kindle.

    Shimel: Yep, hard book and Kindle. I have it on my Kindle here, I was all ready with my notes—but Brad Feld, author, “The Startup Community Way,” Foundry Group, Techstars, tech entrepreneur extraordinaire, and one of my best friends for a long time.

    Feld: Thanks for doing this, it’s so awesome to see you, and congrats on everything you’re doing with your business now. It’s wonderful to see it.

    Shimel: Thank you.

  • Bringing NetOps Up to Speed With DevOps

    Bringing NetOps Up to Speed With DevOps

    Automation can be an unwieldy topic for network operations and DevOps teams who have enough challenges working together cohesively. Networks have been traditionally viewed as the long pole in the tent for emerging DevOps practices.

    But for DevOps practitioners and business leaders alike, there’s good news: NetOps are more prepared than ever to embrace automation and programmability—increasing the likelihood of on-time service delivery, with far less friction between IT teams.

    According to Enterprise Management Associates (EMA), a strong majority (77%) of organizations deem network automation a high priority, and 58% have already implemented or are planning to implement, approved solutions. This is an important and promising shift.

    Traditionally, network leaders have favored an operating model that emphasizes stability and resiliency over agility. Understandably so, as any network interruption can have a cascading impact on the business’ operations and profitability.

    While ensuring five 9s of availability remains a top priority for NetOps, the growing need to support DevOps, containerized infrastructure for applications and cutting-edge digital services—among other initiatives—continues to highlight some of the glaring inefficiencies of traditional network management tools that are too error-prone and bound by scalability issues.

    With the right automation framework, NetOps can play an equal part in enabling DevOps practices by becoming more adaptable to evolving business and application requirements in the cloud and locally.

    Centralizing Management With Cloud-Based Service Delivery

    For decades, improving agility has been a dyed-in-the-wool practice for network teams. Organizations worldwide have now realized enormous benefits by implementing new software-defined management tactics that allow the network to become more centralized, programmatic and dynamic in nature. By disaggregating software from hardware, networking teams now can manage many more services and devices with less effort and resources.

    Among NetOps’ new arsenal of tools and best practices, centralized management has become one of the key ingredients driving toward greater efficiencies. Utilizing a cloud-based approach for provisioning, deploying and managing network services closely mirrors the way IT has spun up cloud storage and compute over the last decade. Now, DevOps teams no longer have to wait days or weeks for the NetOps team to provision the right networking resources so that they can begin designing, testing and deploying new applications.

    Along with the added efficiencies, NetOps teams have greater and more uniform control over device configurations and policies, where security vulnerabilities lie in wait if these do not establish a zero-trust environment. Orchestrating these elements centrally, rather than device by device, places far less burden on individual network operators for protecting high-value corporate assets. Rock-solid network access control also reduces the risk of security or performance degradation that commonly arise from using an ad hoc patchwork of scripts, templates and CLI commands.

    Advancing Network Automation Frameworks

    Because creating a cloud-native network infrastructure does not all happen with the press of a button, network operations won’t become fully automated overnight. Other factors come into play that inhibit broader adoption of automation frameworks, including budget constraints, difficult technology implementations that lack integration with legacy systems and skill gaps for existing staff.

    It’s essential that NetOps teams embrace a network automation framework that aligns to current and future operating models. Through proactive collaboration, NetOps folks can extend the value of automation platforms already used by their DevOps or application counterparts.

    Fortunately for NetOps teams, myriad networking vendors today readily offer pre-built, certified solutions for DevOps platforms, making it easier to get started on a cloud-native journey by automating activities such as device onboarding and configuration changes. This way, network administrators can leverage existing vendor partnerships, in-house knowledge and technology that is already proven within the larger IT environment.

    Additionally, network engineers shouldn’t need—and won’t have the extra time—to become top-notch developers to take advantage of programmability during their cloud-native journey. Developing basic programming skills is advantageous, but network management systems that offer Python scripting, a consistent set of APIs and webhooks can perform the “heavy lifting” when it comes to enabling extensibility with third-party IT platforms.

    Today, this level of extensibility includes being able to integrate with third-party IT service management tools. A common use case that can realize significant time savings and greater network and application availability is to auto-trigger and assign an incident ticket when a performance SLA is breached. It’s very easy to collect and use machine learning-based tools to correlate all of the relevant diagnostics data in order for a network operator to immediately begin a root cause analysis and quickly resolve the issue.

    On the Horizon: AI-Driven Operations

    Another core aspect of DevOps is continuous improvement—both in terms of elevating service levels, as well as enhancing user experiences. But faster rates of change resulting from continuous improvement processes can negatively impact application performance, and the network is often the first to be blamed.

    But there is a huge silver lining within this cloud created by faster rates of change, which also highlights another growth area for NetOps teams to learn and master. That is, the use of AIOps.

    Today’s networks are bound by human scale. When things break, it takes a human to realize it broke, research the issue and then apply the fix. While traditional management and monitoring tools can alleviate some of the burden, alert fatigue often becomes a huge problem—in other words, too many false alarms, false positives or, worse yet, drawing attention away from more critical issues.

    AIOps tools and technologies mitigate these issues and limitations by combining artificial intelligence, machine learning, and advanced network analytics to automate many aspects of traditional monitoring and troubleshooting. Once deployed, IT organizations have the ability to predict and preempt failures,\ or quickly recover from issues when they do occur. This includes being able to:

    • Leverage ML-trained data sets to continuously monitor network performance and detect anomalies.
    • Eliminate guesswork by prioritizing fixes or improvement efforts and validating that those efforts have the desired business impact.
    • Continuously optimize network performance based on benchmarks.

    Put another way, AIOps systems are worth their weight in gold by helping networks move toward a self-healing, self-securing and self-optimizing model. Even in the interim, during the early phases of deployment, such AI-assisted operations can help IT identify and resolve network- or user-impacting issues faster and easier. The results are that dramatic.

    Next Steps: Bring a DevOps Mentality to NetOps

    Contrary to popular belief, the goals of NetOps are not diametrically opposed to DevOps. Both groups want to deliver more value and help the business innovate.

    Equipping NetOps teams to build on existing DevOps-based automation frameworks, paired with AI-driven insights and modern management tools, will go a long way in ensuring frictionless delivery of new services.

    Now is the time for network operations teams to get to know your DevOps team, learn how they operate and come together to create new methods for advancing the organization’s IT mission. The investment in time and effort should be a creative win-win for both groups and produce a big payoff in IT’s strategic position and importance to the organization.

  • SaltStack Looks to Automate DevSecOps Processes

    SaltStack Looks to Automate DevSecOps Processes

    SaltStack announced today it has integrated its automation framework with a variety of third-party security platforms to further the adoption of best DevSecOps processes.

    Mehul Revankar, director of product management for SaltStack, said version 6.3 of SaltStack Enterprise provides integration with offerings from Splunk, Tenable, Qualys, Rapid7 and Kenna Security. Data generated from vulnerability scans conducted using tools from Tenable, Qualys and Rapid7 can be directly imported into SaltStack Enterprise to inform automated DevSecOps processes, while integration with Kenna Security makes it easier to automate and prioritize vulnerability remediation based on the level of risk.

    Revankar said that latter capability is crucial because remediation efforts should not be prioritized based on the severity of a vulnerability alone. For example, a vulnerability may be discovered in an application that sits behind a firewall, but if that application doesn’t provide access to the web an organization may decide to not patch that vulnerability immediately regardless of its severity because the risk of a breach is still relatively low, he said.

    These capabilities will enable SaltStack Enterprise to serve as a foundation for providing security orchestration, automation and response (SOAR) capabilities within the context of a DevSecOps process by making it easier to incorporate cybersecurity within the context of a larger playbook for automating the management of IT, he added.

    Most of those playbooks will be developed by DevOps teams in collaboration with cybersecurity professionals, noted Revankar.

    In addition to improving DevSecOps processes, SaltStack hopes to make it easier for external applications such as Splunk and Datadog to consume data generated by its framework by providing compatibility with Prometheus, an open source IT monitoring tool developed under the auspices of the Cloud Native Computing Foundation (CNCF). A SaltStack Enterprise Splunk add-on tool has been added to the Splunkbase repository.

    SaltStack is also making available a performance and health dashboard to enable DevOps teams to track 25 SaltStack Enterprise metrics that are surfaced using the Prometheus data format.

    The open source Salt framework on which SaltStack Enterprise is based has emerged as a popular option for automating IT processes. Because it is based on Python, the barrier to adoption for Salt in terms of programming expertise is comparatively low to other programming languages. As such, more IT operations teams have been inclined to learn Python to leverage Salt to automate processes.

    Like most vendors that have adopted open source business model, SaltStack extends the capabilities of Salt via an enterprise edition that it both extends and provides commercial support.

    Interest in IT automation is on the rise as organizations of all sizes look to maximize what limited cybersecurity resources they have and cut costs. IT automation in the form of SOAR presents an opportunity to consistently apply cybersecurity policies more broadly without having to increase the size of the IT organization.

    The challenge, of course, is having the expertise required to build a playbook. In the case of open source frameworks, many of those playbooks are shared among the members of a community such as Salt. Regardless of how those playbooks are acquired, it’s clear that as IT becomes increasingly more complex most IT organizations are not going to be to do without them.

  • Report: Debugging Efforts Cost Companies $61B Annually

    Report: Debugging Efforts Cost Companies $61B Annually

    Undo, a provider of a software failure replay platform, this week published a report in collaboration with a Cambridge Judge Business School MBA project that estimates 620 million developer hours a year are wasted on debugging software failures, at a cost of roughly $61 billion.

    The report also notes software engineers spend on average of 13 hours to fix a single software failure.

    According to the report, 41% said identified reproducing a bug as the biggest barrier to finding and fixing bugs faster, followed by wiring tests (23%) and actually fixing the bug (23%). Well over half (56%) said they could release software one to two days faster if reproducing failures were not an issue. Just over a quarter of developer time (26%) is spent reproducing and fixing failing tests.

    On the plus side, 88% of respondents said their organizations have adopted continuous integration (CI) practices, with more than 50% of businesses reporting they can deploy new code changes and updates at least daily. Over a third (35%) said they can make hourly deployments.

    Undo CEO Barry Morris said the report makes it clear organizations need to be able to record software to reduce the amount of time it takes to find bugs. Unfortunately, even then finding a bug is still a labor-intensive process that can involve analyzing millions of lines of code. In the future, software replay systems will be infused with machine learning algorithms to accelerate the bug discovery process, he noted. As software becomes more instrumented, the observability data and metrics that machine learning algorithms require to detect patterns is becoming more accessible.

    In the meantime, while CI has been embraced, the continuous delivery (CD) side of the DevOps equation remains a challenge. Each platform software is deployed on is unique, so most organizations find automating software delivery problematic.

    Regardless of DevOps approach, it’s clear there’s still lots of room for improvement when it comes to developing software. Even the most advanced practitioners of DevOps are limited by the rate at which software bugs, including security flaws, can be discovered and remediated. Of course, there may come a day when machine learning algorithms automate much of that process, including determining which types of tests to run. For now, however, many organizations could streamline the software debugging process by recording instances of applications when they are built and when they are deployed. After all, each platform that software is deployed on has attributes that inevitably impact how software on the platform runs.

    As software continues to become more complex in the years ahead, challenges associated with debugging applications will only continue to grow. In the age of microservices, the issue that software engineers are trying to troubleshoot might not have anything to do with the code they wrote; rather, the issue emanates from a service they invoked via an application programming interface (API). Whatever the source of the problem, it’s apparent to all a lot of time and money is being wasted on debugging software that could be put to far better use.

  • Report Finds Most Cloud Security Issues Left Unaddressed

    Report Finds Most Cloud Security Issues Left Unaddressed

    Accurics, a provider of a platform for assessing the security of cloud computing environments, has published a report that finds that even once discovered, only 4% of issues reported in cloud production environments are addressed.

    Based on research conducted using its platform and other public sources of data, the report also finds 90% of organizations allow privileged users to make configuration changes directly to a cloud infrastructure after it is deployed.

    Issues such as open security groups, overly permissive identity access management (IAM) and exposed cloud storage services make up 67% of the most common cloud security issues being uncovered, according to the report.

    The Accurics report echoes similar findings published by Unit 42, the cybersecurity arm of Palo Alto Networks, which found more than 199,000 templates have medium-to-high vulnerabilities in use on public clouds.

    Accurics CEO Sachin Aggarwal said that as more organizations embrace infrastructure as code using tools such as Terraform, policy guardrails aren’t being put in place. More troubling still, security assessments seem to be few and far between. That’s especially problematic because cybercriminals now routinely probe every layer of the application stack looking vulnerabilities, he noted. In effect, cybercriminals are assessing cloud applications and infrastructure more frequently than IT teams.

    Aggarwal said beyond making sure the appropriate guardrails are in place in terms of overall security posture, organizations need to have confidence in the DevOps processes being adopted. That doesn’t mean cybersecurity teams should put rules in place that slow that application development process down. Rather, tools that surface cybersecurity issues and then provide a method to automate the remediation of any vulnerabilities discovered need to be put in in the hands of IT professionals, he said.

    The challenge organizations face is the processes that are employed to secure on-premises IT environments largely don’t translate well to highly dynamic cloud computing environments that assume a shared responsibility approach to IT. Public clouds are obviously popular with DevOps teams that can programmatically invoke resources on demand. However, those teams generally don’t have much cybersecurity expertise. Too often, DevOps teams assume cybersecurity tasks are being handled by a cloud service provider. Of course, the cloud service provider is only securing the services they provide. Any configuration issue is not their responsibility.

    The result is as more changes are made to the IT environment, the more likely that mistakes will be made. Catching all those issues without the aid of tools is an unreasonable expectation for any IT organization, much less a DevOps team that may be working beyond the purview of the rest of the IT organization.

    No one sets out to create a cybersecurity issue. But in the rush to deploy or update an application it’s easy to overlook a cybersecurity issue. The goal should be to eliminate as many of those mistakes as possible before they are ever made. However, as long as humans are involved, there will be errors. So the next most important thing is to be able to correct those mistakes as quickly as possible without having to disrupt the entire IT environment.

  • Survey Sees Increased Agile Adoption During COVID-19

    Survey Sees Increased Agile Adoption During COVID-19

    A report published by Digital.ai, the parent company of CollabNet VersionOne, finds 43% of organizations have increased their reliance on agile application development methodologies in the wake of the COVID-19 pandemic, with 15% saying it has increased significantly in the last 90 days.

    The report also notes 33% of respondents say they have increased or expanded Agile adoption in the last 90 days to help manage distributed teams, while 55% said their company plans to increase the use of agile in the next 12 to 14 months.

    Based on a pair of surveys conducted prior to and after the pandemic started, the 14th annual “State of Agile” report also finds 60% of respondents credit agile methodologies with having helped increase speed to market, while 58% say it has improved team productivity. Another 41% say they are also better able to manage distributed teams.

    Mike O’Rourke, chief research and development officer for Digital.ai, said there is a clear correlation between the ability to manage distributed application development teams and successfully navigating the pandemic now that most application development and deployment teams are working from home.

    Many of those teams are also seeing application development deadlines being moved up as organizations prioritize digital business transformation initiatives that now are core to any business continuity strategy.

    That shift is also accelerating a shift toward focusing more on business metrics for measuring success as defined by, for example, the Scaled Application Framework (SAFe), said O’Rourke, noting as a result, there’s also a lot more focus on value stream management across the enterprise as business and IT teams work closely together. The survey finds just over half of the respondents report their organization has either already implemented value stream management (VSM) or are planning to do so.

    The survey also finds more focus on risk and compliance, with the number of respondents identifying and measuring technical risk prior to deployment increasing 54%, while the importance of automated audit compliance and governance across control points increased 10% year over year.

    Perhaps most surprising, the survey finds reducing project cost is cited as an important reason for adopting agile by only 26% of the respondents, a 41% drop from the previous year. The number of organizations focused on release planning decreased by 11%; however, organizations focusing on product road mapping increased 9% over the previous year. The survey also finds slightly more respondents are using automated acceptance tools (3%). Another 12% said they plan to adopt agile project management tools in the future.

    It’s not clear whether increased focus on application development might result in bottlenecks when it’s time to deploy those applications. Organizations that have already embraced best DevOps practices alongside agile development methodologies will naturally be in a better position to deploy applications. At the same time, increased focus on digital business transformation is likely to accelerate the adoption of both agile development methodologies and best DevOps practices across the enterprise.

    In fact, it’s arguable that organizations that are not able to build and deploy applications adroitly may soon find they are unable to compete at a time when software development has become critical to their survival.

  • CircleCI Extends Core CI/CD Platform

    CircleCI Extends Core CI/CD Platform

    CircleCI today in partnership with Plandek launched an analytics plugin dubbed Buildtrakr for its namesake continuous integration and continuous delivery (CI/CD) platform. Buildtrakr integrates with CircleCI and Git to synthesize commit and build performance data, with critical metrics being surfaced via a dashboard.

    In addition, CircleCI has revamped its user interface and reconfigured a new fleet of Docker images, also known as CircleCI convenience images, to optimize them for a continuous integration environment.

    CircleCI CEO Jim Rose said Docker images made available by CircleCI are faster, easier to download and provide a more efficient way to build custom images. CircleCI also released a new category of convenience images available for languages such as Python, Ruby, Rust, Go and several others, that come with improved documentation, more stability and more efficient infrastructure. Those convenience images are individual open source projects and can be used in IT environments other than the CI/CD platform from CircleCI.

    Finally, the company also announced that its insights endpoints now offer start and end date parameters for workflows and jobs. These parameters restrict the range of executions returned based on their start times in addition to providing a new filter to use for testing analysis.

    Rose said the new user interface is significant because it makes it possible to view the status of entire pipelines more easily while making it easier for more advanced DevOps teams to leverage workflows.

    The redesigned interface also adds a filterable view with nested workflow and job information, making it easier to scan the status of recent builds. Pages were also overhauled to deliver more digestible job details, full-screen step outputs for easier debugging and a cleaner configuration-as-code view. There’s also been a 65% reduction in page load times, noted Rose.

    In general, Rose said activity on the CircleCI platforms in cloud environments is on the rise in the wake of the COVID-19 pandemic. Organizations that are working remotely due to stay-at-home directives and can’t access a local data center have come to realize that having a build box located under someone’s desk is no longer a viable option.

    Of course, it remains to be seen how much of that initial burst of activity will result in new applications being deployed. However, with more organizations starting to build and deploy digital business applications to engage customers, it may be only a question of when IT operations teams will be able to catch up to a building backlog of applications. In fact, many of those applications are now likely to be deployed on the same cloud where they were constructed.

    Whatever the path forward, there most certainly will be a greater reliance on metrics. Naturally, the hope is that analytics will be used to coach DevOps teams to become more efficient versus simply riding roughshod over developers. After all, the goal isn’t to write more code faster but to deliver better code at the right time.

  • Netlify Makes Build Plugins Available for Jamstack Platform

    Netlify Makes Build Plugins Available for Jamstack Platform

    Netlify, at a Jamstack Conf Virtual event, announced the general availability of open source Netlify Build Plugins that provide IT teams with a set of continuous integration/continuous delivery (CI/CD) workflows for building websites and web applications using JavaScript, application programming interfaces (APIs) and static HTML files without employing web servers, otherwise known as a Jamstack.

    Designed to be launched from within a Netlify platform to enable IT teams to build a website and launch it from a Git repository to a content delivery network (CDN), the Netlify Build Plugins are intended to make it easier to employ DevOps processes using, for example, a plugin to run an end-to-end Cypress test.

    Netlify CEO Mathias Biilmann said DevOps teams also can make use of a Netlify API to create their own plugins. Ultimately, the goal is to foster the development of a wide range of open source Netlify plugins that would be built and vetted by the Jamstack community, he said.

    Other Netlify Build Plugins provide a means to enable Ghost, an open source headless content management system based on Node.js that can be deployed on any framework; launch a Sentry tool to automatically discover, triage and prioritize bugs; or enable a Gatsby tool to create incremental builds on Netlify.

    A survey of more than 3,000 Jamstack developers published today by Netlify finds one-third have worked on sites serving millions of users over the last year. Nearly two-thirds of survey respondents (62%) work outside the tech industry, including advertising and marketing (21%), media and publishing (14%), education (14%), financial services (13%) and business support and logistics (13%). Well over a third (38%) work for a technology company. About a quarter (26%) have more than 10 years of experience.

    Top Jamstack benefits cited by all types of developers are performance, uptime, speed of development, security, compliance and avoiding vendor lock-in, the survey finds.

    Biilmann said Jamstack as a philosophy enables IT teams to separate the development of front- and backend websites and applications in a way that allows organizations to embrace best DevOps processes. That approach is agnostic as far as any specific JavaScript framework is concerned, but it does define a way to automate the build process for a web application or website.

    In the wake of the economic downturn brought on by the COVID-19 pandemic, more organizations are investing time and resources in modernizing their websites and applications. With more employees and end users depending on those websites to drive digital business processes, the quality of the application experience has become a much bigger concern. At the same time, end users have now come to expect those application experiences to be updated regularly, which in many cases will necessitate the adoption of best DevOps processes.

    In fact, it’s arguable that organizations that don’t embrace best DevOps practices to build and deliver web applications at scale will soon discover they have bitten off more than they can chew.