devopsy.kinsta.cloud

Tag: startup

  • Jit Emerges to Address Cybersecurity Policy-as-Code Orchestration

    Jit Emerges to Address Cybersecurity Policy-as-Code Orchestration

    Jit today emerged from stealth with a free namesake orchestration platform beta that automatically implements security plans as code.

    Aviram Shmueli, chief product officer for Jit, said the company will both make security plans it developed available as code within GitHub. In addition, Jit will make available a service through which customers can submit documents and spreadsheets that Jit will convert into a custom security plan that can be executed as code.

    Fresh from raising $38.5 million in seed funding, Jit is aiming to advance the adoption of DevSecOps best practices by enabling cybersecurity policies to be more easily implemented as code via its orchestration platform, said Shmueli. The Jit platform enables developers and DevOps teams to take advantage of a graphical tool to automatically implement security policies within a DevOps workflow with a single click, he noted.

    The goal is to eliminate the need for separate DevOps teams to create security policies that each would need to individually manage, added Shmueli.

    In theory, DevSecOps best practices require shifting left the responsibility for security toward application development teams. The challenge is that development teams generally don’t have the expertise required to craft effective cybersecurity policies. Jit is making a case for a platform that makes it simpler to automatically implement vetted cybersecurity policies.

    Exactly how far responsibility for application security will shift left remains to be seen. Developers generally prefer to spend as much time as possible creating business logic rather than implementing cybersecurity policies. As such, it’s frequently left to a DevOps team to find a way to consistently implement cybersecurity policies across multiple applications. Each DevOps team will need to decide how much they can rely on the policies defined by Jit versus opting to implement a set of policies defined by their internal cybersecurity teams. The issue that often arises is cybersecurity teams lack programming skills; the only means available to define cybersecurity policies is some type of document or spreadsheet that, one way or another, needs to be converted into code.

    Given the ongoing chronic shortage of cybersecurity expertise, it’s apparent that more efficient methods for sharing cybersecurity best practices are required at a time when application environments continue to both rapidly expand and increase in overall complexity.

    Regardless of the DevSecOps approach, the pressure to address application security is mounting in the wake of a series of high-profile cybersecurity breaches. Organizations of all sizes are now reviewing software supply chains that are increasingly being targeted by cybercriminals. Security policy-as-code tools make it possible to ensure that applications don’t, for example, communicate with an external system without express permission.

    One way or another, the level of application security currently being attained will improve in the months ahead as more mandates are enforced. The only real issue remaining is the amount of disruption to existing processes that will be required to achieve that goal.

  • 3xFAIL: IPv6 Fails | Fintech Fails | Firefox Fails

    3xFAIL: IPv6 Fails | Fintech Fails | Firefox Fails

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: IPv6 gets stabbed in the back, Fintech firms’ valuations are falling, and the latest browser war seems to be over—Firefox lost. (more…)

  • Dagger: Standardizing CI/CD is the Holy Grail of DevOps

    Dagger: Standardizing CI/CD is the Holy Grail of DevOps

    Continuous integration and continuous delivery (CI/CD) has become a hallmark of quick software release life cycles. Nowadays, many teams support CI/CD pipelines for their software, offering a repeatable pathway to build, test and deploy code. A CI/CD pipeline is necessary to support an iterative, rapid deployment approach—yet, maintaining one is not an easy task.

    Enter Dagger. Dagger is a utility that aims to streamline how developers create and manage their CI/CD pipelines. Dagger, led by founders of Docker, recently unveiled their public beta launch along with a Series A $20 million funding raise led by Redpoint Ventures. While many open source CI/CD projects already exist on the market, Dagger is unique in offering easier configurations, pre-built components and more reusable actions.

    Akin to traditional supply chain management, software supply chain management is an increasingly complex endeavor involving many third-party dependencies. Development teams truly require a set of standard building blocks to piece it all together. For this reason, Solomon Hykes, co-founder and chief executive of Dagger, told SiliconANGLE that “solving this problem is the holy grail of DevOps.”

    Below, we’ll look at the common stressors inherent in creating and managing modern software delivery chains. We’ll also take a peek into the Dagger beta to see what it’s attempting to accomplish.

    Issues Facing CI/CD

    Software development supply chains are growing larger and larger to support a complex network of software architectures. But DevOps engineers, who must automate this chain, are drowning in tool sprawl—and stitching these components together to make custom pipelines can become a big bottleneck.

    Especially as an organization expands its distributed microservices architecture into the cloud, it can be tricky to scale a repeatable CI/CD pipeline across various department and disparate tech stacks. This often results in many bespoke CI/CD pipelines. Even within the same team, nuances between codebases can complicate each CI/CD process and require engineers to rewrite scripts.

    Simultaneously, organizations are under intense pressure to deliver to meet new digital innovation demands. But, until DevOps can make the release process more efficient, software development automation risks introducing more toil than it takes away.

    Diving Into Dagger

    So, how is Dagger alleviating these concerns? Well, Dagger creators described it as a “portable devkit for CI/CD pipelines.” Using Dagger, DevOps engineers can use a standard set of building blocks to assemble their CI/CD pipelines and then run them on their chosen cloud. It’s like a better developer experience for CI/CD pipeline creation.

    So, how does Dagger work under the hood? Dagger is powered by Buildkit, the Dockerfile-agnostic builder toolkit. Developers then use Cue to specify how their code is run in a container and to link up actions. Cue is an open source configuration language developed at Google.

    According to the docs, it takes about five minutes to install Dagger and the necessary dependencies. Dagger also provides boilerplate code to integrate with pre-existing CI environments. In essence, Dagger doesn’t need to replace your CI tool—it adds “a portable development layer on top of it.”

    Then, there are the actions themselves. Dagger supports a growing library of actions that it calls Universe. At the time of writing, the Universe of actions is limited and is being staged in the main Dagger repository. These actions are reusable Cue packages. For example, this package details how to run and deploy the Nginx web server in Cue:

    package nginx

import (
    "universe.dagger.io/docker"
)

    And then,

    #Build: {
    output: docker.#Image & _pull.image

    _pull: docker.#Pull
    *{
        flavor: "alpine"
        _pull: source: "index.docker.io/nginx:stable-alpine"
    } | {
        flavor: "debian"
        _pull: source: "index.docker.io/nginx:stable"
    }
}

    Benefits

    CI/CD can certainly benefit from standard building blocks and more fluid wiring between tools. There are several potential benefits from Dagger’s proposition:

    • Unification: Unifying developer and CI environments could avoid headaches.
    • Localization: Dagger enables testing a closed-loop pipeline locally. This helps for debugging.
    • Reusability: Building blocks help avoid rewriting automation scripts repeatedly.
    • Multi-cloud: Easier ability to migrate a pipeline from one cloud to the other, thus avoiding vendor lock-in.
    • Compatability: Dagger can run in any environment compatible with Docker, meaning it’s probably workable with your current toolset.

    Final Thoughts: Lego Blocks For CI/CD

    Docker revolutionized the software industry by easing the process of managing containerized applications. And now, Docker founders Solomon Hykes, Sam Alba, Andrea Luzzardi and others at Dagger are tackling another meaningful problem within today’s complex software ecosystem. Given the success of their previous endeavors, it’s not too difficult to imagine a network of reusable CI configurations emerging with an excitement similar to Docker Hub.

    Of course, Dagger is still in its early stages and there’s much development ahead. It will undoubtedly be an interesting project to follow in the years to come. Dagger is being built as an open source project on GitHub. The company has also opened a Discord channel to engage with the community.

  • 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.

  • Blockchain Startup RNDR Surpasses GPU Capacity of Public Cloud Tech Giants with World’s Largest GPU Cloud Rendering Network

    Blockchain-based graphics rendering platform beta surpasses the cumulative on-demand GPU rendering power on the public cloud; Offers partners unlimited, scalable GPU rendering, AI, and compute on the cloud

    LOS ANGELES, October 17, 2018 – Blockchain-based rendering platform RNDR has revealed data from its Q2 beta testing survey, supporting the conclusion that its global decentralized network of graphics processing units (GPUs) is powering is the world’s largest cloud network of its kind. Topping the cumulative capacity of all GPU instances from major public cloud providers, this discovery came as a result of a survey taken by over 1,200 individuals during beta testing for the RNDR platform with regard to their contribution to the network and the amount of processing power they are collectively lending from their devices.

    Survey results showed that in total, the RNDR network is harnessing the power of over 14,000 GPUs, with 11,000 GPUs currently compatible with the platform, and a combined GPU rendering power of 1.5 million OctaneBench (OB). OctaneBench is a GPU benchmarking utility created by OTOY for its application, OctaneRender. For comparison, a .60 cents/hour G2 instance on Amazon Web Services (AWS) delivers around 37 OB, and a centralized version of the RNDR service, which launched in 2013 on Amazon G2 instances in partnership with AWS, Autodesk, and later, Google and other major cloud providers, is capacity limited  at under 1 million OB. RNDR’s decentralized technology allows the network to utilize the computing power of everyday GPU owners distributed across the world, eliminating ceilings related to capacity and network speed that exist within systems currently offered by the biggest cloud players.

    RNDR is an advancement of established cloud-based rendering company OTOY, which leverages blockchain technology and a distributed network of idle GPUs to render graphics more quickly and efficiently. The project has received early support from industry luminaries such as Hollywood producer JJ Abrams, and famed talent agent Ari Emanuel.

    Jules Urbach, CEO of OTOY, said “We have been working for quite some time now to build the RNDR network and have reached unprecedented levels in cloud computing, putting us at the top with the largest tech companies in the world. Our vision when we first began this journey was to scale and democratize rendering, creating more efficient processes and to reach not only high-power Hollywood studios, but also everyday content creators who might not otherwise have access to this technology. RNDR is the key to ushering in the increasingly virtual future of entertainment – from AR to VR to video games to film. This significant milestone further demonstrates that we are that much closer to reaching our goal, and we can’t wait to show the world what our platform can do in the near future.”

    OTOY’s sophisticated cloud-rendering technology has been used to create visuals in some of the past decade’s most notable works including Westworld, Star Wars, Avatar, AntMan and the Wasp, and many other films and tv shows, along with four out of five Emmy Nominees in this year’s Outstanding Title Design category. OTOY has also partnered with Facebook to provide post-processing tools for projects created with The Manifold camera, and Unity to enable game developers to create advanced cinematic graphics. As the entertainment space continues to evolve, applications requiring high-quality renderings in real-time will require more computing power than what is currently available. RNDR’s platform will enable the acceleration of this graphics creation, providing speed, massive data storage, instant software updates, and heavy-duty processing without the massive hardware or infrastructure costs that come with other current options.

    RNDR’s distributed blockchain GPU compute network provides the scale to make the rendering of stunning content displays widely available for the first time. The RNDR platform is currently in beta testing, with a full release set to go live later this year.

    For more information, visit www.rendertoken.com, read the whitepaper here, and join RNDR’s Telegram channel here.

  • DevOps Chat: Startup Playbook, Founder to Founder Advice w/ Rajat Bhargava

    DevOps Chat: Startup Playbook, Founder to Founder Advice w/ Rajat Bhargava

    Two old, good friends of mine published a book yesterday called Startup Playbook. The book is “founder-to-founder advice on how to create and build your startup.” In this DevOps Chat, I sat down with my friend and co-founder Rajat Bhargava. We talked about why he and Will Herman wrote this book, what he hopes others can learn from it and Raj gives us 3 tips on what every first time founder should know.

    Between them, Will and Raj have started more than a dozen venture backed companies and have had multiple 8 and even 9 figure exists. If you have ever thought about starting your own company, had a great idea but weren’t sure what to do with it or just thought you could do a better job than the people you work for now, this book could be what you are looking for.

    For this week (Feb 19) the book is available on Kindle for just 99 cents! Here is the link for the kindle download.  Also a few times at the end of our conversation I referred to the book as the “Founders Playbook”. I tried to dub in the correct name, the “Startup Playbook” but my feeble interviewing skills are far superior to my sound engineering ability. Apologies.

    As usual the streaming media of our chat is immediately below, followed by the transcript of our conversation.

    Audio

    Transcript

    Alan Shimel:              Hey everyone, it’s Alan Shimel, devopsy.kinsta.cloud, DevOps Chat. We’re here with another great DevOps Chat. Today’s chat is a little different for a couple of reasons. First of all, my guest is a very long-time – did I say long-time? – friend of mine, Rajat Bhargava. Raj, welcome to DevOps Chat.

    Rajat Bhargava:         Thanks for having me, Alan.

    Alan Shimel:               Hey man, thanks. Secondly, our chat today is a little different. Rather than talking nuts and bolts of DevOps and that kind of stuff, we’re gonna talk about Raj’s new book, along with his co-author, another friend of mine, Will Herman, called The Startup Playbook.

    Raj, I’ve known about the project for some time, but tell our audience, share with them what is The Startup Playbook. Why did you write it?

    Rajat Bhargava:         Well, The Startup Playbook is really our founder-to-founder conversation with other entrepreneurs. We’ve seen so many books out there that are from DCs, they might be from analysts, they might be from other folks out there, but we felt that founders out there needed a book from us, from other founders. Whether we wrote it, Will and I, or somebody else, we just felt like somebody had to talk about the tips, the secrets, the tribal knowledge, the stuff that we get by getting together and talking to other founders. We just felt like that was missing.

    We have these conversations with so many other founders on a daily basis because we mentor and advise and help support other founders, we just felt like we needed to write it down. It’s like around the campfire, we have so many of these conversations, we felt like we needed to write it down so that there was a place that other founders could go to to learn quickly.

    Alan Shimel:               Just in the way of full disclosure, you know, Raj, you and I have worked together on at least two or three companies, maybe more. But in the way of background, you’ve actually founded, what, about eight companies now, starting when you were still back at university at MIT, correct?

    Rajat Bhargava:         Yeah, that’s right. So, it’s probably now close to 10 that I’ve helped start, or started myself. There’s just a lot of mistakes that I’ve made and a lot of challenges that I’ve faced, and I wanted to share those. On the same, Will has probably started five different businesses and he’s got tremendous experience, tremendous knowledge. We’ve both been through so many different things that we wanted to share those so that other people didn’t have to go through the same pain that we went through.

    Alan Shimel:               As we used to call it, the idiot tax, right?

    Rajat Bhargava:         That’s right.

    Alan Shimel:               Our audience – I don’t know how many “entrepreneurs” we have listening in, though I hope there are some – is made up of a lot of technical people. People, Raj, not that different, frankly, than you, right? Who have a great engineering background, live, breathe and die in today’s technology.

    I’m sure there’s a big subset of them out there who maybe have a great idea, who see a hole in the market, who see a need in the market, have something that they say can really maybe change the world and make a great company. But they just don’t, they’ve never done it. They don’t know where to start. I know that’s who you are aiming for a lot in this book. Talk to us a little bit about that persona, that kind of person. What’s in the book for them?

    Rajat Bhargava:         Well, this book is absolutely targeted directly at them. In general, the book is a founder-to-founder conversation. The founders we’re really trying to target are those first-time founders, the folks that haven’t been through it before. Like you said, they may not know all the steps that they need to go through. They may not even know if founding a business is the right thing for them.

    So, we actually start before you start a business in the book. We start about whether this is the right thing for you to do for you, for your family, for you as a person. Is founding a company the right thing for you? We start there. So, it’s from the ground up and we build up from there.

    I think our belief is – we’re biased because both Will and I were engineers by educational background – we think some of the greatest businesses are started by engineers, by technical folks. We love when technical folks bring ideas forward, and we think they can change the world. The challenge is that the idea is just not good enough. Ideas are, unfortunately or fortunately, either way you look at it, they’re a dime a dozen. It isn’t the idea that’s so differentiating; it’s all of the other work that you do around the idea that makes it differentiating, that makes the successful business.

    That’s a lot of what we talk about in the book is that the idea really just isn’t enough. It’s a seed. It’s a kernel. It’s where you start, but it’s just the beginning. It’s a long, long journey, but a great idea is a wonderful place to start.

    Even an okay idea is a great place to start because you can iterate on it and you can improve it. You can make it much better. Then, a lot of the stuff that you do around that idea is what differentiates you and helps make you successful.

    So, for your audience, for technical folks who have an idea, we think that’s fantastic. That’s a wonderful, wonderful base to start with, to build a business.

    Alan Shimel:               You know, there’s a lot in there, Raj. I want to highlight a few things. First of all, it’s true, whether you have a job or you’re starting your own company, but don’t underestimate that when you go to start, become a founder, that it doesn’t just affect you, right? It affects your family, your loved ones, your significant others and what have you. Because I’ve never met anyone who is successful with a half-hearted attempt to start a company, or to start a business, or to nurture an idea like that, to nurture a business. To me, it’s either you’re all in or you’re out.

    Rajat Bhargava:         Absolutely, yeah.

    Alan Shimel:               That’s one thing I think people need to think. Let me also hit on one other thing and that is when you speak to people, and you’ve spoken to more than me, but I’ve spoken to my share, what’s the biggest thing holding people back? If I took a poll, Raj, and said, “Hey, who would like to start their own company, be their own boss, and make a lot of money and be successful?” Very few people are gonna keep their hands down; everyone wants to do that.

    What stops people from doing that? Well, number one, it’s a little bit of fear of the unknown, having never done it. But number two, the biggest thing I hear from people is, “My god, I don’t have the money to get there. What am I gonna do until my company makes enough money? How do I bridge from having a job with a steady income that keeps the lights on to the time where my startup is enough for me to support myself?”

    That’s probably the single most scariest thing for first-time founders. What do you think?

    Rajat Bhargava:         You know, I think you’re right. I think there’s absolutely the fear of the unknown and fear of failure which, by the way, 9 out of 10 startups, according to the research, fail, which we actually think is low. We probably think it’s closer to 95 out of 100, maybe even 97 out of 100. Very few companies succeed long-term. The ones that are breakout successes that we hear about in the media are few and far between. It’s so few of the ones that start.

    I think the second point is such an important point, which is how do I go start this business when I need money to live on, and there’s no cash coming in at the beginning? Well, that is a very, very hard problem. The good news is there are so many solutions to it, but some of it is a leap of faith, too.

    The thing I would start with is there is so much prep work that needs to happen before you launch a business. That is where we spent a tremendous amount of time in the book talking about how do you vet your idea? That doesn’t have to happen only with you quitting your day job, and going and working on it. Some portions of that at some point you may need to do full time, but you can do a tremendous amount of research, of vetting your idea, of building your plans, of figuring out whether this concept that you have can be really, truly built into a business.

    We encourage people to spend an inordinate amount of time at the beginning going and doing that. Because if you can build the right foundation at the beginning, you’ve got a shot at making it successful. If you start with a very shaky foundation, those cracks are gonna get exposed very fast and the chances of you succeeding go down dramatically. So, even if you need that job, even if you need that income coming in, there’s still a lot you can do to build out your concept and build out your business, even before you take the plunge.

    Alan Shimel:               Fair enough. So, Raj, if we take that as okay, that’s one tip for prospective first-time entrepreneur founders, ’cause we’re running low on time, give me three or four others, if you can. Maybe a top five of what a first-time founder should…really idiot tax saving tips here that they can really rely on.

    Rajat Bhargava:         Sure. I’ll give you three. The first one is the one we just talked about, but I’ll expand it.

    I think completely vetting your idea before you really go all-in is so critical. That includes things like the value prop, the target customer. How can you build a team, or who is the team? Can you actually build the product or service that you’re proposing?

    Can you differentiate it in the market? How are you gonna go get customers? How can you make money? Can you raise money to support yourself? All those things are the art of what we call vetting your idea. The more you can vet the idea from the beginning, the more solid of a foundation you have. That’s tip number one is completely vet your idea.

    Tip number two is build a team around you. People think that starting a company could be just a single founder. Especially as an engineer or a technical person you might say hey, I’ve got this great idea. Why do I need to have another co-founder until later?

    Well, we encourage you to get other co-founders right out of the gate. At least one, if not two. It’s critical that you have some people who are side-by-side with you as you go through this journey. Find people who have different perspectives, but that you can really work with. It’s one of the most important relationships that you’ll have in the business.

    The third thing is find mentors, advisors, board members, people that have done it before that you can learn from. There is nothing like saving yourself time, mistakes, challenges, problems by hearing advice from others. You have to be open to it, but if you’re open to it, you can really accelerate the progress of the business.

    Those are three quick tips that I would say are things a first-time founder ought to think about really hard.

    Alan Shimel:               Yeah, and those are three good ones, too. I’m sure the book is chock full of more of them.

    Raj, let me throw you a little bit of a curveball. In addition to wanting to start businesses because they see needs in the market, I can’t tell you how many engineers and technical folks I speak to that would like to write a book. Again, I don’t know what stops them. Many do cross that chasm, right, and write a book; many don’t.

    For people who maybe don’t want to start a business today, but do want to write a book…and most of them are not novels. They’re much like Founders Playbook, non-fiction kind of books. What advice can you give to budding or prospective authors out there?

    Rajat Bhargava:         You know, It’s different for everybody, but the thing that I think helped Will and I the most was we just broke it down into a little bit of time every single day. When I initially wrote the first draft of the book, I had a target of 1,000 words a day, which isn’t a lot, as you know, Alan. You can write 1,000 words probably in about 30 minutes, so it’s really not that much time. But if you plug away at that for 90 days, for just one quarter [break in audio]. The typical book is really more like 45,000 words. If you did it for 90 days, you’ve got 1,000 words, and you can throw away half of those words because –

    Alan Shimel:               And still have a book.

    Rajat Bhargava:         And still have a book. Or you could have two books, right? I think that’s the biggest thing is just don’t try and do it all in one sitting ’cause you can’t. That’s not the way it happens. You need to just chunk it up and do a little bit at a time. In my case, what I did was I just started writing. I didn’t even really have too much of an outline. I just started writing 1,000 words a day.

    Then, we took that and we started formulating that into a book. So, we threw out tons of it, we rewrote it a couple of times. There’s just a tremendous amount of editing work. But the editing work turns out to be a lot easier – at least it feels easier; it probably isn’t easier – because you already have something down. It’s the blank sheet of paper that’s really daunting. But if you say, “I have a blank sheet of paper today and I only need to write 1,000 words,” that’s not that bad. You can get there.

    Alan Shimel:               Sounds like an agile methodology to authoring a book. Doing it in sprints.

    Rajat Bhargava:         Exactly. Yeah, exactly. Do a sprint a day.

    Alan Shimel:               Yeah, that sounds cool. A little scrum meeting in the morning.

    Well Raj, we’re about out of time here, but for our audience who maybe are interested in taking a look at Founders Playbook, I know you guys are offering sort of an introductory launch as the book goes to launch special. Where can we get some information here?

    Rajat Bhargava:         You can go to startup-playbook.com and you can also go to Amazon and just search The Startup Playbook. It is 99 cents for the Kindle version for the first week or so; that’ll come up on Monday the 19th of February. It’ll be 99 cents for a week. We’ve tried to make it really accessible for everybody. We really just want to get the knowledge and the content out into the founders’ hands.

    Startup-playbook.com, or look on Amazon, The Startup Playbook.

    Alan Shimel:               Raj, beyond the book itself, I know you and Will have plans to try to nurture a community here with that. If people have questions, are there places on the website where maybe they could ask and stuff?

    Rajat Bhargava:         Yeah, absolutely. You can reach us on Facebook, on Twitter, on LinkedIn. If you go to the website, there’s links to all of that. You can reach out to us pretty easily. You can find us, and we’d be happy to engage and chat with you.

    Alan Shimel:               Sounds great. Hey Raj, I know this was a labor of love, but it was nevertheless a labor, and a long time coming for both you and Will. So, congratulations on the launch of the book, The Founders Playbook. You know what? We’ll keep an eye on it and watch it. I hope some of our listeners out here go check it out. The only thing you have to fear is fear itself. If you’ve got a great idea, the world’s waiting and you can make it happen.

    Rajat Bhargava, my friend as well as author of The Founders Playbook, thanks for being this episode’s guest on DevOps Chat.

    Rajat Bhargava:         Thanks for having me, Alan.

    Alan Shimel:               All righty. This is Alan Shimel. We’ll see you soon on the next DevOps Chat.

    — Alan Shimel

  • Startup

     

    — ROELBOB

  • Technology is All About the Business

    Technology is All About the Business

    In 2011 I joined a company as their fifth employee. They had been in business a little over a year. They had a product. They had customers. Oh, and the other four people? They were rockstars.

    Customers, however, were unhappy. The system was frequently down. Rebooting a machine was often necessary and lead to poor performance for hours.

    I was hired to fix “the database problem” in a multi-tenant SaaS system. On my first day I was given a tour of the technology by the engineer. The code was immaculate, but the database had some core issues. We had the database in good working order in a couple of weeks. We lost our first customer about two weeks after that.

    Why did this customer leave? Ultimately because we were not working on the problem that mattered. We created a local optima in the database and another in code quality. It turned out that there were more fundamental problems.

    Achieving local optima is a false economy. (1) We needed to think outside our core skill sets. Systems thinking pointed the way.

    The Reaction that Mattered

    We had three months cash left. We had two months until our make-or-break event. The business closed a sale for two months operating capital! The customer was a very big brand whose needs would stress the existing software beyond its limits.

    At this point the problem that mattered was immediate and clear. How do we guarantee this customer’s success? As with many things, the answer was obvious once we thought of it: We stood up a duplicate of the production software just for them.

    The Patterns we Recognized

    Standing up a second production environment was no easy task. Over 200 bash commands lovingly executed across five hand-crafted cloud servers. It took days to get our bespoke second system stitched together.

    While it was ideal that we landed such a big contract, the truth of the matter was the business was not confident in our product’s technology. For each potential sale after landing the big one, I would get a call, “Are you sure we can handle this next customer?” The answer was already apparent. We, the tech team, were not confident either.

    Changing the Software

    We needed to improve the software so one customer’s activity had no possibility of impacting performance for another. This would localize problems to a single customer and increase the business’ confidence. We needed to do it quick. We needed to do it with a single engineer and DBA.

    Each customer would get their own full copy (share nothing) of the software. Deployment of the software would be reduced to the simplicity of stamping out parts in a factory. With this model we rewrote the system and closed three new customers on it for our big event.

    Moving to this “share nothing” paradigm is likely the single biggest contributor to the company staying in business, thriving and eventually being acquired. The confidence of the sales force increased dramatically. Sales increased dramatically. Our runway moved out past the six month mark.

    Why Share Nothing

    We recognized our system was a B2B offering, not B2C. This a type of pivot know as a business architecture pivot. (2)

    Trying to build all of the infrastructure for a self service system that scales to unknown demand, while really cool, was not the problem we needed to be solving. Yes, there are inefficiencies in such a share nothing system. No, none of them impacted our bottom line.

    For example, we didn’t care that we were wasting compute. The price of the compute was built into the product. The customer was not paying for compute. They were paying for the product and they were willing to pay so much that this cost didn’t matter.

    Powerful Consequences

    We effectively rewrote the original system in two months. This still seems miraculous, and to some extent it is a testament to the amazing quality of the business logic code. There were, however, other consequences to the “share nothing” model that gave us a significant, if temporary, market advantage.

    • We had no need to spend engineering cycles on plumbing such as user management.
    • We had no need for a billing system. Human-time invoicing in a B2B world was plenty effective.
    • We had no massive scale of data or load. We used familiar technologies.
    • When an instance went down, only one customer called. We learned most of these things were training issues.

    For each item above, the need for engineering was eliminated or dramatically decreased. This means the engineer used that time to create new features. More features means more revenue if you are building the right things. Our CEO and founder was a genius; we were building the right things.

    And it Broke

    Sales trusted the system. New customers were coming in. Existing customers were happy. Infrastructure costs decreased.

    It was short lived. The tools and technology used to implement the repeatable, “share nothing” software were not up to the task. The success of sales was creating a new problem, though a much nicer one to have! We needed more systems thinking.

    Did DevOps Fail

    We did not initially choose the right tool. Is this story a DevOps failure? If you subscribe to the idea that process informs tool choice, then the answer is a surprising, “No.” The DevOps thinking was sound, we simply need to choose better tools to support the model we had chosen to implement. Technology is all about the business at the end of the day.

    Part Two of this case study will highlight some of the evolution of the tools and processes we put in place that lead us to further success.

    References

    (1) The Goal – Eliyahu Goldratt, Jeff Cox
    (2) The Lean Start up Eric Ries

  • 11 DevOps start-ups funded for a busy 2015

    11 DevOps start-ups funded for a busy 2015

     

     Slides

    [seoslides embed_id=”4b8ee43e173e” script_src=”https://devopsy.kinsta.cloud/embed-script/11-devops-start-ups-funded-busy-2015/title/” overview_src=”https://devopsy.kinsta.cloud/slides/11-devops-start-ups-funded-busy-2015/” site_src=”https://devopsy.kinsta.cloud” site_title=”devopsy.kinsta.cloud” title=”11 DevOps start-ups funded for a busy 2015″ /]
    Advance slides with arrow buttons or touchscreen

  • DevOps developers; don’t be a DevGoof

    DevOps developers; don’t be a DevGoof

    There was a lot of brush back last week over Jeff Knupp’s post about how DevOps is killing the developer. Frankly I wasn’t shocked by Knupp’s opinion that developers “are the dentists in the dental office”. In my 30+ years of involvement in the IT industry my experience is that developers often think of themselves as the only smart person in the room. Often times that is the reason they are are the only person in the room, lol. The fact is many developers relate better to code than to people. For me all this talk about DevOps killing the developer is akin to saying power steering killed the driver. Just because you can do more with new technology, does not mean one dies, one just has to pivot and in this case become business social.

    Now the sociable part may be the problem. Sometimes I feel that DevOps is trying to create a love fest between Ops, Developers, QA, security and the rest of the IT stack. While they may not have to love each other, I do think they all need to be nice to each other as opposed to ignoring  or just going around each other, as was all too often done in the past. A common scenario I have seen for example is for developers to rollover Ops by stating this is mission critical for the business. These tactics will no longer work to let developers have their way.

    Developers need to realize they need to become a normal part of the business social structure. They will be required to talk and work with people, not throw tantrums when they don’t get their way. Left unchecked, certain developer personality types can sabotage your project, or worse, make themselves no fun to work with.  I am sure we have all met and unfortunately had to work with people like that. In my career, I’ve encountered virtually every personality type. In fact, I’ve also knowingly hired all of them. They know who they are; they are the developer that if challenged or worse accurately taken to task for lack of being part of the team; quit cause they can’t manage the confrontation, thus interpersonal stress. In the old days they would not come out of their house for weeks continually playing Leisure Suit Larry, if your not familiar with it Google it

    I remember one of my good friends telling me this story that sums this whole developer persona issue perfectly. This company, we will call DevGoof, was a well funded start up. Every quarter they held a meeting with all the employees to let them know how the company was doing. Most employees had some kind of equity play in the company, so everyone was incented and theoretically interested in company performance. Several quarterly meetings came and went and not one developer showed up. Eventually DevGoof management got concerned and called a mandatory meeting for all developers’.

    DevGoof management put out some pastries, juice and coffee for the brain trust. Then proceeded to tell them why these meetings were important to them and their fellow employees. Notably pointing out how it is not just about them but also about the rest of the DevGoof team. This meeting went on for about one hour and not one developer asked a question. So eventually this meeting was over and everyone went back to developing. The next morning,   about 50% of the developers quit and some in a not so professional fashion.

    The moral of this blog is the DevOps is going to force the development community to become more interpersonal within the business environment. This will lead to personal success within the new world of DevOps. The DevOps Developer/Engineer that can demonstrate leadership and compassion for team will be the one leading the DevOps way within the organization. Don’t be a Devgoof!

    If you would like say something; email parker@devops.com and don’t forget to comment here.