devopsy.kinsta.cloud

Tag: developer

  • GitHub Extends Scope and Reach of Repository

    GitHub Extends Scope and Reach of Repository

    GitHub today at its GitHub Satellite virtual conference announced it has made it easier for developers to either launch a project or join an existing project on its repository and has added collaboration tools directly within the platform.

    GitHub is also moving to advance DevSecOps by adding code scanning tools and making secret scanning tools available for private repositories, in addition to making available GitHub Private Instances to provide organizations in highly regulated industries access to a more secure managed implementation of the GitHub repository.

    Max Schoening, VP of Product Design, said GitHub Codespaces removes a lot of friction associated with starting or joining a project by enabling developers to spin up a project in seconds. In many cases, he said, developers never launch a project simply because the effort required was too great relative to the value of the effort.

    Available in limited public beta, GitHub Codespaces should not only improve developer productivity but also significantly increase the number of projects being hosted on GitHub, said Schoening.

    GitHub Discussions, meanwhile, will provide a threaded format to organize unstructured conversations without having to leave the GitHub repository. Scheduled to be available in beta shortly, GitHub Discussions should increase developer productivity in addition to providing a place for developers to maintain a frequently asked questions document. Over time, Schoening said GitHub expects millions of communities to be formed around GitHub Discussions.

    GitHub is also moving to make DevSecOps a natural extension of any application development project. GitHub Advanced Security Cloud provides access to native code scanning and secret scanning tools that can be embedded within the developer workflow. Currently in beta, GitHub Advanced Security Cloud is based on security tools it gained via its acquisition of Semmle last year. Every Git push can now be scanned using a CodeQL semantic analysis engine to discover vulnerabilities. GitHub Advanced Security Cloud is designed to be an extension of an existing GitHub Advanced Security service.

    Finally, GitHub Private Instances will provide a fully managed alternative that, among other things, allows for bring-your-own-key encryption, backup, archiving and compliance with various regional data sovereignty requirements. GitHub did not reveal, however, when GitHub Private Instances will be available.

    As GitHub continues to evolve as an arm of Microsoft, there is no doubt more IT teams will be embracing DevOps. The biggest challenge is often making it easy to get started. In fact, many developers may find themselves unconsciously embracing best DevOps and DevSecOps processes as they, for example, employ scanning tools baked into the GitHub repository.

    Of course, no one knows for sure whether organizations will continue the pace of application development projects in the wake of the economic downturn brought on by the COVID-19 pandemic. However, Schoening noted the amount of time between pull requests has declined on the GitHub repository, which he suggests is an indication of increased activity and productivity now that more developers are working away from the office.

  • Handing Your Software’s Source Code to Someone Else: When, Why and How?

    Handing Your Software’s Source Code to Someone Else: When, Why and How?

    While keeping a tight hold on your company’s valuable source code is often seen as the preferred option, there are times when you may be required to hand it over to someone else; there may even be times when handing over your software is actually hugely beneficial to business, too. However, in these scenarios, it’s always important to understand under what conditions this situation may arise, exactly why you may need to do so, and how you can transfer your source code to another party safely.

    When and Why to Transfer Source Code

    Quite simply, source code should never be handed to someone outside of your company unless there is a specific and necessary reason to do so. Here are some situations in which you may need to transfer code:

    Bespoke Development

    As a software company, you may be tasked with creating bespoke solutions to fulfill specific and/or niche business needs. Following development, both the software and its source code will be transferred to the customer, who will, in most cases, then own the intellectual property rights for the software in question.

    When: You will usually be required to provide the source code to the customer at agreed milestones.

    Licensing/Collaborative Development

    If your company (the licensor) opts to partner with another (the licensee) to extend development of one of your products, either with your branding or as a white-label, you will need to provide the licensee with access to the source code for the product they are licensing for the duration of the contract.

    When: Once again, you will usually need to keep providing updated source code at agreed milestones.

    Escrow

    If your customer purchases your software but wants to protect themselves from supplier contractual or business continuity issues, source code can be handed to a third-party software escrow provider. This means that, should the worst happen to your business, your customers can gain access to the code.

    When: Code will usually be transferred at agreed milestones; in many cases, following formal releases.

    Acquisition

    Mergers and acquisitions are somewhat common within many sectors, including the technology industry. Should you enter into an M&A process and are acquired by another business, your source code will be transferred to the new owner, who will then own the intellectual property rights to the software.

    When: Under merger and acquisition conditions, you will only need to hand over your source code once.

    Legal Discovery

    While this situation is very uncommon, there is the possibility that a business may be accused of intellectual property theft by a competitor. In this scenario, source code must be made available to intellectual property experts for analysis to determine if infringement has taken place.

    When: Again, in a legal discovery situation, source code will only need to be transferred once.

    How to Transfer Source Code Safely

    The safest way to hand over code will largely depend on when and how often you need to transfer.

    For a One-Off Delivery …

    … the safest option is usually in person, using multiple, highly durable, solid-state devices and secure, public-key encryption. With the addition of multiple drives, this method also provides the fastest way to exchange a large amount of data. It is important to manage the physical security of the transit and the exchange. However, a face-to-face exchange is often impractical due to scheduling, geography or a whole host of alternative reasons. If you need to undertake a virtual delivery, choose file-hosting services with rich access controls that allow you to explicitly specify who has access to which of the files.

    For a Recurring Delivery …

    … the face-to-face and virtual options of a one-off delivery can also be utilized for recurring deliveries, although a recurring physical delivery is usually not sustainable unless the two parties are geographically close. Therefore, virtual deliveries may be the preferred option and can be undertaken in the same way each time as necessary; either as complete releases of the source code, or alternatively as a delta since the previous delivery. If the data involved in the transfer is particularly large, it is recommended that an initial delivery is completed physically, followed by smaller deltas delivered virtually via servers.

    A Collaborative Approach

    In some instances, particularly when the relationship between the parties is two-way, rather than being a simple client-vendor setup, a collaborative approach to sharing source code may be more appropriate. The easiest way to achieve this would be for one side to host the code, providing the other with access rights to the repository. Alternatively, modern distributed version control systems offer each side the opportunity to have a copy of the repository, with changes synchronized between them, or for a common server to exist between the servers on both sides. A collaborative approach can be useful, but may also introduce complexities relating to reconciliation of changes from both sides of the equation.

    Protecting Your Code

    Depending upon the reason behind your need to hand your software to someone else, you may wish to take measures to protect your intellectual property. Patents can be used to protect the factual aspects of software, while software copyright can be used to protect the “artistic” side of things, including your code. While handing your code to another party is a relatively common behavior in the software world, it never hurts to be prepared, to be aware of the risks and to protect yourself throughout the process.

    — Jorge Sagastume

  • The Secure Developer Podcast: Continuous Security at Chef

    The Secure Developer Podcast: Continuous Security at Chef

    Welcome to The Secure Developer, a podcast about security for developers, covering security tools and practices you can and should adopt into your development workflow. The Secure Developer is hosted by Guy Podjarny, CEO and co-founder of Snyk.

    In this episode of The Secure Developer, Guy talks with Chef CTO Adam Jacob about the role security can play in DevOps and continuous integration/deployment. They cover the differences between baked-in and bolted-on security and how automation with Habitat can change the way developers approach secure coding. Adam Jacob is the co-founder and CTO of Chef, formerly known as Opscode, where he wrote the open-source, automated applications project Habitat.

    This podcast is brought to you by Heavybit, a program that helps developer product companies take their product to market.

    [soundcloud url=”https://api.soundcloud.com/tracks/295763125?secret_token=s-AfcYk” params=”auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false&visual=false” width=”100%” height=”166″ iframe=”true” /]

    Guy Podjarny: Hello, everybody, and welcome back to The Secure Developer. Today we have an awesome guest on the show, Adam Jacob from Chef. Adam, thanks for joining us.

    Adam Jacob: Hi.

    Guy: We’ll talk about various cool topics we teed up, that I think are interesting with the world of security and the world of DevOps and CI/CD, and some very interesting new package management, build system capabilities coming out of Chef that I think are very relevant to the security play.

    Before we dig in, for the few of you that might not know Adam Jacob or Chef, Adam, do you want to give a quick intro of your background?

    Adam: Sure, I think there’s probably more than a few who have no idea who I am. I’m Adam. I wrote Chef, originally. I’m the CTO at Chef, and I wrote a thing called Habitat not that long ago that does application automation. And that’s sort of new stuff.

    Then, mostly what all of that really boils down to is, I spent the last 10 years going around talking to big web companies like Facebook and Google and Yahoo, and I’ve also spent a bunch of time with startups. And then I’ve also gotten to go see really large enterprises ranging from giant banks to insurance companies, retail companies like Nordstrom, Wal-Mart.

    So I get to just travel around and see what everybody is doing and see what they’re worried about and try to help them get better in terms of the time it takes or the speed to deliver, or their organization or their culture. So a bunch of it is software, but a lot of it is just helping people sort of understand how better to build their organization.

    Guy: Yeah, I guess there’s always this conversation about whether DevOps and, well, continuous deployment maybe is a little bit more specific, but DevOps is really more about the tools and more about the people and it tends to be a consensus that it’s more people.

    Adam: It’s both, right? Like, if you have a great culture, it’s really easy to say that you want to have a good culture. It’s really easy to be like, “Oh, I want to empower people,” or, “We want to streamline a process,” or whatever. It takes nothing. It’s just words.

    Usually, it’s the technology that reinforces those cultural behaviors that hold you back.

    So, a good example is, “Oh, I want to do continuous delivery, but we use a terrible source control system that makes it almost impossible to do effective continuous delivery. But because that’s the source control system we use, we’ll never change.”

    Therefore, which one’s true? Do you want to do continuous delivery, or do you love your bad source control system? So there’s this reinforcing circle that hides inside there, and I think you see that all the time in security, too, that same circle and that same behavior.

    Everybody says, “Oh, we want to be secure.” I was working with a bank who I won’t name, and I was on an engagement for a couple weeks.One of my first questions that’s going to help them do continuous delivery, and they wanted to, their first target was, to harden the operating system.

    I asked them, “Okay, do you have the hardening spec? Do you know what you want to harden?” And they were like, “Oh yeah, yeah, of course we do. We’re a global bank.” And I’m like, “That’s amazing, great! I would love to see that.” And they’re like, “Oh, we’ll have it for you on the day you arrive.”

    I left three weeks later, and they had never found it. And what they had realized was it didn’t exist. Everybody thought someone else had built that, and that it was someone else’s job, and no one actually did. It was just this loose conglomeration of stuff that theoretically they were supposed to do, but no one actually could track or knew. And that’s a global bank. It probably should matter.

    Guy: I think sometimes it’s about the mess or the fact that tools can help surface information and hold information in a way that is accessible. And sometimes it’s just the sheer obstacle for many of these more complex topics when you talk about deep ops topics around how containers operate or how some machines are orchestrated.

    Or in the world of security, when you talk about deeper security, understanding about what’s an attack, what’s not, and that sort of a constantly moving landscape. Just fundamentally, you have to have the tools. You cannot overcome those problems by sheer education. And at the same time,

    if you have tools and people don’t know how to use them, or they have no understanding of what they’re for, then you would eventually not achieve what you’re aiming for.

    Adam: Context is everything, right? Tooling is great, but it’s not enough. One of the things that we do at Chef and in the security world, is we have a thing called InSpec, which is a language for letting you describe security posture and code.

    So you can say, “This particular machine should have this particular policy. That policy means that port 25 should be open, you should be able to auth this way, you shouldn’t be able to auth this way.”You should be able to talk about packages being installed, you should be able to talk about all of those things and then relate them back up to the actual security line items and talk about their severity.

    We care about this thing because of this piece of HIPAA, or we care about it because of this piece of CIS, or whatever. And those tools are great because they sort of combine the documentation of, this is what the standard is, with the check that actually is executable that says, “And are we meeting the standard, yes or no?”

    I think whether it’s InSpec or tools like InSpec, when you think about that operational part of security and how it applies to those large enterprises, especially large enterprises, but the big web, too, more and more it’s becoming that policy is executable.

    So that conversation between security and developers and operators becomes a conversation around code as opposed to a conversation around documents, and controls, which I think is really the conversation most people have now.

    Some security guy wrote a control and then here’s the list of people that say that they can validate the control. But is the control any good?

    Guy: Is it actually happening?

    Adam: No. I mean, it’s not, right?

    Guy: Yeah.

    Adam: And that’s true everywhere. We wrote a control. Here’s the list of 10 people that you could go interview that know how to do that control. Okay, what about the other 10 people who could also do that, that aren’t on the interview list that wasn’t updated on the last year? Do they always do the procedure the right way?

    Do they always make that process right? And of course, the answer is no. But we just sort of let it ride because the auditor passed.

    Guy: Yeah, it’s the notion of protecting yourself from audits, not from attacks.

    Adam: Exactly!

    Guy: It becomes sort of increasingly there. I love that notion. So with InSpec or, in general, with security, one of the key challenges is that it’s invisible. So if you’re not doing it, you really have no immediate indicator to the fact that it’s not happening.

    The user experience, if you will, of not monitoring, not watching for a certain vulnerability, and the user experience of watching for it and having nothing happen, is the same thing, which is, nothing happens, right?

    Adam: Yeah, which is nothing.

    Guy: Which is good news. So I think anything that helps define and articulate the controls that are supposed to be happening, giving you some mechanisms to understand that the action has been taken so you know that InSpec, the locking or whatever, say, if we use a simple example, the limiting of ports being open, that has been explicitly articulated and explicitly tracked by the tools here, and you can get informed that it has happened.

    We see this in Snyk a lot. We watch projects for vulnerabilities, for vulnerable dependencies, and then you have really, again, it comes back to the fact that you have the same user experience. If you’re not watching a project, or if you’re watching a project for vulnerabilities and none happened there, and we have a lot of these conversations with users today about, “How do you want to hear about it? How do you want to know that you’re watching it?”

    And today, we remain fairly simple. We just remain in this ongoing report that just sort of shows you, “Hey, you’re monitoring five projects” or something, and they have those things.

    Adam: Right, it shows that it reacts often, or whatever, and we can measure change.

    Guy: But it’s great to sort of increasingly have those and have some requirement, whatever, in your Chef and InSpec, and that defines it as well, project X is being monitored for X, Y, Z, so you know it’s being enforced.

    Adam: Right, and then you stick that in the pipelines.

    When you think about continuous delivery and security, security and the validation of that compliance is part of the process by which software goes into production.

    And it’s part of the way that software gets maintained once it’s there, and it’s part of that build process. You bake it in sort of throughout the SDLC, instead of it being a thing that happens at the end.

    And that’s one of those things that’s obviously a good idea. So, as soon as you hear it, you’re like, “Oh, of course, security should be baked into the process, all through the whole thing.”

    Guy: The whole built-in versus bolt-on.

    Adam: Yeah, right? Sort of, duh. But actually, doing it is actually completely–

    Guy: A whole different ball game.

    Adam: A whole other ball game. And the thing that we really came to realize, especially with InSpec, but just sort of in general, is that if you can’t figure out how to manage that security posture the same way you manage the rest of what you do, it’s really difficult to then tell a software developer that it’s their responsibility to ensure that that posture is good or bad. Because, sure, they can make that they write “good code.” You can’t hear the air quotes, but m I was making little air quotes in my brain, probably.

    Guy: I can attest to that.

    Adam: It’s good, but you can’t really ask them to understand the posture of what it’s going to be like when it’s deployed.

    Because the distance from a software developer making a decision to a software developer talking about how that software should be in production, and what it’s posture ought to be, is so vast. And their ability to influence it is so low that it’s really difficult to come back to them and be like, “Oh, this was your responsibility.” Like, clearly it was on you.

    And when those tools give you the ability to talk about it as code. They allow people to participate, you can code-review them. You can have security people audit the code as opposed to audit your documentation, and then have those things as a living piece of that deployment model, I think everything gets better and it gets a lot more secure.

    One hard part of doing things that way is that it’s very not the way that most security regimes are set up right now. If you go talk to a security officer and you ask them, “Hey, could we remain compliant to whatever the standard is, HIPAA?” If everything we did was continuously delivered, nine times out of 10, the answer is just a flat no.

    And what’s interesting is that there is, one out of 10, where that security officer is like, “I don’t know, maybe. Tell me more about how that would work.” And I think if I roll my clock back three years, it was 10 out of 10 that we’re telling me no and that was crazy. And now it’s like nine of 10. And I predict in six months, it’ll be six of 10. And then in two years, it’ll be like talking about, “Should you be doing continuous delivery or should you be doing Agile?”

    Guy: It comes back actually to the commentations sometimes or even that document or something that big bank did not have. Like, these things eventually come back to the documents and to the guidelines. So at the end of the day, you go down the compliance route and you actually have that in the compliance document that it says, well, if you are using continuous delivery, then to be HIPAA-compliant, you need to ensure that you’re doing these things as opposed to just sort of having the goal in it.

    Many of these regulations have the same flaw, the same notion that says, “Well, you have to do these actions,” as opposed to, “You have to achieve these goals.” So they give the vague goals, but then everybody prescribes to whatever recommended actions that have been prescribed, because that makes passing the audit the easiest.

    Adam: Yeah, and I mean,

    the relationship between the auditor and your security posture is pretty tight.

    Like, the real test of your security posture, in most cases, is the auditor. Not like a pen test, or people actually trying to break you. I mean, they are, but you’re not doing it proactively.

    I think when you think about those CD pipelines, the idea that they’re applied continuously, that as applications change, that you’re reapplying the security posture to see if that application has done something that violates that posture, and that when you change the security posture, you’re re-validating the applications and you’re doing it sort of throughout the whole cycle, it’s super powerful. It’s what people are starting to be able to do. I think you don’t see it a lot yet, but it’s sort of the future.

    Guy: I think that’s interesting to understand, the potential versus what’s happening, right? High-level continuous deployment and your whole infrastructure’s code, the fact that you’ve prescribed it, built it in, allows you to get predictability. You know what’s where, and you know that a certain test or a certain enforcement has been done to the extent of bugs. But at least, not as human error.

    On the flip side, it requires security auditors to change how they behave. It’s not just about that compliance, it’s also the fact that today, many of these security audits, you gave the example of a security auditor reviewing your code, are done as gates.

    They’re done as a way that says ‘stop here,’ which is the antithesis to continuous.

    The whole notion of continuous is just, you roll out. It’s okay to pause for a moment, but you can’t stop. You can’t accumulate a backlog, because otherwise it’ll deteriorate, unless you automate that.

    Adam: Yes and no, right? There’s continuous deployment, and then there’s continuous delivery,and they’re not quite the same. So yes, in continuous deployment, there’s nowhere to pause. I think in continuous delivery, there is.

    In continuous delivery, the idea is you’re shipping when you should be able to ship, any time that the business required shipping or it made sense to ship. And that’s different than saying, “We just ship every time you commit,” right? And so in continuous delivery, I think there’s plenty of space to say that, “Hey, this project, in order to ship, requires a security review.” And that process can still be continuous.

    The question is, that should be the only gate between you and getting to production. So if they say yes, could you ship? And then the question of course is, is that true for every commit? Like, could you ship today, if today was the time? The answer to that is very rarely yes, and so that’s where the difficulty comes in.

    Guy: Yeah, and I think it’s an interesting comment. I accept the delta between continuous delivery and continuous deployment, but it seems to me that from security route, well, first of all, even from a quality perspective, one of the values of continuous, both delivery and deployment, is the fact that you spot errors when they’re small, at any given time.

    So definitely, for continuous deployment, when you ship every small code change, whatever, at some low resolution, when a problem occurs, it’s much easier to pinpoint to what was the issue, the source of the problem.

    That value proposition is pretty compelling in security as well, right? If you are looking for a security flaw, being able to, only looking at it within the range of whatever the 100 lines of code to change versus the 100,000 lines of code or 100 million that existed, is very valuable. If you accumulate those changes and you need to now do the security audit, I would argue you’re not actually ready to deliver in that spot.

    This podcast is brought to you by Heavybit, a program that helps developer-focused companies take their product to market. Throughout the program, founders work on developer traction, product market fit and customer development. If you like what you hear, be sure to subscribe to Heavybit’s Podcast Network on iTunes.

     

    — Malia Powers

  • Don’t Make Me Code Podcast: Onboarding Developers

    Don’t Make Me Code Podcast: Onboarding Developers

    Thanks for listening to Don’t Make Me Code, a podcast that discusses developer experience design and the unique challenges of building developer-facing products. Don’t Make Me Code is hosted by Steve Boak, co-founder and CPO at Opsee, and David Dollar, co-founder and CEO at Convox.

    In this episode of Don’t Make Me Code, Steve and David talk about some of the challenges of onboarding developers, and ways to make that experience better.

    This podcast is brought to you by Heavybit, a program that helps developer-focused companies take their product to market.

    [soundcloud url=”https://api.soundcloud.com/tracks/245152401?secret_token=s-4SUlM” params=”auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false&visual=false” width=”100%” height=”166″ iframe=”true” /]

    Steve: So, today we’re talking about onboarding, and what a pain it is for developer tool companies. It’s weird to me that, in the consumer world, we’ve got products that we can happily onboard into in seconds, and in the dev tools world, we go in the range of minutes, you know, five or 10 minutes feels pretty good.

    David: Yeah, we’re dealing with like, complicated things that people are integrating into these other complicated things that they’ve built, and it’s often not quite as simple as ‘just type in your email address and click a button.’ You know, you have to add some pieces to your code, or add some dependencies, or start instrumenting things—there’s all this stuff you might have to do to get started.

    Steve: And those requirements feel just unreasonable at times, I mean I can’t stand going through it, having to write code to onboard into a product.

    I remember getting stopped using New Relic for the first time, and having to actually write code before I could start using the product, and it’s discouraging, but required. And it’s just this infinite frustration and we, in our product, we’re trying to eliminate that as much as we possibly can, but, it’s a unique frustration of our world.

    David: Definitely, I mean, we’re trying to deploy applications to the Internet and they can be, you know, the variation to those is so huge, and so we spend a lot of time focusing on making it work out of the box without you having to make a whole bunch of changes right out of the gate. I think that’s really important.

    Steve: See, you and I are both at early-stage companies, we’re dealing with our Beta customers now, and that’s a very high-touch scenario, we’re interacting with them very closely and one at a time. But, we often have to deal with things like personal email addresses, where they’re signing up for the product as a company, but using their personal email, so, I spend about 10 or 15 minutes just discovering who the person I’m dealing with even is.

    David: Yeah, I mean, we definitely see that a lot, and it’s actually not just personal email addresses, you know, they’re actually probably trying us out in the context of personal accounts to begin with, or personal, you know, maybe they’re coming to bring a personal project like their blog, or something like that, to begin with, and they want to like, ‘Yeah, is this thing going to work, before I actually start to try and introduce this at work?’

    Steve: Yeah, and you’re trying to demonstrate value in an environment that, one, is not the intended environment, and two, might have totally different requirements around it. And, you know, for us at Amazon for example, we’re dealing with people’s personal accounts that have things like EC2 Classic support, which has been deprecated, and their production environments at work are a lot less likely to have that, but it’s something that we, as the makers of the product, have to consider just because of how people might onboard into it.

    David: Yeah, definitely.

    Steve: And even if we’re lucky enough to get somebody’s work email address, we still have to go through the whole test flow, where they put us in their staging environment, and give us a try. And it’s a tough constraint to be in a place where you’re going to have measurably less value, but still have to prove that you can be valuable to the customer.

    David: Yeah, they want to see, is this tool going to work for me.

    No matter how good your documentation, no matter how good your examples, most people are going to want to actually put their hands on it, and see how it works, and see where it falls down. And any experimentation is sort of like the name of the game for our target customers.

    So I think providing some sort of backdraft for that, and making it really easy to play with your product is pretty important.

    Steve: Yeah, and really considering how you’re going to provide value in these circumstances where you might be restricted is super important. Although, I have to say, this morning, we had a guy sign up for the product, put us in an environment that had literally nothing in it. It was an AWS environment with 0 instances and 0 groups, and we’re a product that health checks other things in the environment, and there was nothing to health check. That was a tough sell.

    David: Now he knows that you’re not going to take down his Amazon account, I guess.

    Steve: Yeah, and that too, the security check, right, like, half of the battle is convincing people that, one, you’re not going to break, two, you’re not going to break their stuff.

    David: Yeah, I think, and that’s certainly another driver for why people try with their personal accounts first, right? It’s like, ‘I’m not going to install this tool into my production account at work that I don’t know anything about.’

    Steve: Yeah, it’s been really funny actually to watch this, ’cause we do a lot of onboards in person over video chat, or even just watching their laptop screens, and we’re dealing with incredibly smart people. They watch, and they can see what our onboarding process is doing to their environment, and they go and audit everything, they’re checking every change to preferences, and they know exactly what’s happening. And they check us on everything, which is, you know, worrying, but also kind of cool to see just how good they are at what they’re doing.

    David: We basically, we get the same thing, people trying to install us into their actual Amazon account, it’s a pretty tough sell, we’ve had a lot of luck getting early users to just either create a new Amazon account and install everything there. Or we actually, we will create a whole bunch of, we pre-create a whole bunch of Amazon accounts, and just hand them out to people to let them start trying stuff. Anything we can do to reduce the amount of stuff that they have to do to get in and get experimenting, I think is really valuable.

    Steve: Yeah, that’s a really good point. Something we’re not doing yet at my current company but we’ve done in the past is create these real demo environments, where, you know, without creds even, people can try the product out online and get a sense for what it will be like without signing up, which has been a really useful tool for me in the past.

    David: Yeah, it can be pretty tough to do that with developer tools, just because, you know, you are talking about complex integrations in a lot of cases, but yeah, I think hugely valuable, when you get that right. If I’m a couple clicks away from actually playing around with the product, and maybe even a couple more clicks from you know, taking what I’ve been playing with and going live with it, any friction you can reduce in that path is going to help.

    Steve: Yeah, that actually raises an interesting point about the transition over the last few years from how enterprise software companies used to sell to how they seem to be selling now, which is the transparency, that now, things like pricing, and a real sense of what the product does. It all sounds pretty basic, but, these were things that you wouldn’t expect to see, five, 10 years ago. That selling a B-to-B product—you would have a button to contact the salesperson, and you might not even know what the product did on the homepage.

    David: Yeah, that’s exactly right, I mean, you still see a lot of that today, and it’s incredibly frustrating as a buyer of software to run into one of those. We try and keep in that in mind a lot when, from the other end of that it’s knowing how much it’s going to cost to knowing exactly the value that it’s going to provide for you, and how it’s going to make your life better, is really important.

    Steve: Yeah, it seems so obvious just to design your marketing at least so that people know what the product does when they come to your website. I can’t imagine a consumer company dealing with some of these issues, like the problem of multiple environments, and that we get people signing up with personal accounts, or with staging environments that are not the intended use of the product at all, but in order to win these customers over, we have to show value in them.

    David: Yeah, it’s tough, I mean, those environments can basically be completely different too, right? Like, my personal IDS account maybe has nothing in common with what my company’s looks like, you know, it’s like almost as if somebody wants to test your iPhone app by installing it on their Android phone at home first. It can be wildly different.

    Steve: Yeah, we were actually talking the other day about having kind of a ‘clean up’ button, where because we know so many people are onboarding this way, putting us in a staging environment or something first, that, they’ll have to kind of decommission some things and remove some things that they created in that first environment before moving to the other one. And so we’re trying to make that process easier for them too, as part of our onboarding. Which just seems ludicrous, but, it’s funny to talk about.

    David: Yeah, it’s almost worth trying to, is there some way that you can, through permission sets or something, like actually introduce them slowly into the production environment in a trusted manner, as opposed to here making them go through this experimentation phase first.

    Maybe if it was very guided, it might be possible to pull that off. So, you mentioned dealing with customers sort of on a one-on-one basis, in kind of a very high-touch manner, and that’s something that we’ve had a lot of success with, and we actually think is really important, you know. We have a public slack channel, we invite people to come in, we talk with people all the time, they ask questions about the product, that ask, you know, if they’re having problems, or if they, you know, even questions about Amazon, sort of things that are not even directly related to us, and kind of get a conversation going about that stuff.

    It’s been hugely valuable to have that kind of real-time, you know, I can just ping somebody and kind of get to know our customers individually, and know what they’re building, kind of the problems that they’re having, and that’s been really helpful.

    Steve: Yeah and, not only that we get to interact with them in real time, but we have a way of reaching out to them, and that, one of the issues we have, I think, as an early-stage company is that people are trying the product, they’re not necessarily engaged with the product, and they may not tell us about that.

    And so, having every possible way to reach out to them, but also then making part of our onboarding process actively reaching out to them during this process, and making sure they’re getting value, and seeing if they’ve found bugs, and just doing everything that we can on our side to make sure that they’re happy and engaged.

    David: Yeah definitely, I think, I mean reaching out, kind of keeping the engagement level high, and reaching out constantly, like, you almost always have to solicit feedback. I mean, you’ll get some really awesome customers that will come and tell you everything that’s wrong with your product, and those are great, but, for most people, you have to actually solicit that feedback. A lot of the best learning we’ve done in our onboarding process, and finding where the friction is, is just talking to somebody and seeing the questions they ask, you know, sometimes they’ll be like, completely off base, or weren’t even in the ballpark of things you were expecting them to ask, you know, you’re expecting them to ask, ‘How does something work,’ and they’re asking, ‘What does this thing even do?’

    Steve: Yeah, I think you raised two really interesting points there: one is like, when I was new to this, both new to startups and new to designing technology products, I used to take offense from that feedback. ‘How dare you criticize my work.’ But, as you were saying,

    The most vocal customers are the best ones. The ones who are going to tell you about every single bug, I cherish that now. That’s what we look for in our Beta customers.

    David: Two reasons: one, it exposes all of the things that you hadn’t seen, and two, those customers are actually your biggest opportunity to make them successful. If they’re engaging with you enough to tell you what’s wrong, they want it to work badly enough that you can just help them a little bit and they’re going to be great.

    Steve: Yeah, totally, if nothing else, if they’re complaining it means they care enough to complain, and like we were talking about earlier, partly because our onboarding processes tend to ask a lot of our customers, and because that can take significant time, it’s really on us to engage with our customers and figure out how we can help through that and how we can make it easier for them, and so, because of the burden on them, it’s a big thing for us to both learn how we can make that better, and also help them help customers through it as best we can.

    David: One of the interesting things that we’ve been seeing is that we get not only really technical people coming through our onboarding process. We get some very technical developers that kind of understand the basics of what’s going on, and they have one set of questions.

    We get other people that are maybe a development manager, or, in a lot of cases, I had one ops guy and he’s now AWOL and I can’t get in touch with him, and I just need help, and they have a completely different set of things that they’re looking for when they come to talk to us. It’s been really enlightening to be able to talk to all of those groups, and kind of see what it is that they’re looking for, because it’s very different.

    Steve:  Yeah, we, in speaking to the different kinds of people using the product, there seems to be a transition happening in that way dev teams are set up. And so, we’re dealing sometimes with developers, sometimes with operations people, sometimes people who identify as DevOps, and it’s almost like we have to learn something about the organization first, how their team is set up, and how they deploy infrastructure to even get a basis for the level of conversation that we’re having. And the level of knowledge—yeah, like you were saying, it could be anyone from a manager, I even had a couple of product people contact me. And so yeah, just establishing how the team is set up has been really important to figuring out how to talk with our customers.

    David: Yeah, understanding who makes decisions about that kind of stuff, understanding how new technology is deployed at their company, you know, it’s different for everybody. Like, some people are very gung ho, they just take new stuff and go crazy with it all the time, and some companies are very conservative, and it’s a lot different to get sort of the new shiny things rolled out for them.

    Steve: I think the contrast of, and we were talking about this a bit earlier, broad vs. deep, and open source vs. SaaS, so I think, Convox’s case is really interesting because you’ve got both an open source product and a SaaS product. Can you talk a little bit about the contrast and the priorities of designing those two products?

    David: Sure, yeah, I mean, so, it starts right at the beginning. Like you mentioned, we have the open source, we have SaaS, our SaaS product is not open source, so, there’s just fundamentally different ways that we work on those projects even, you know, with the open source we work in the open. We do a lot of discussion with the community before we make changes, you know, pull requests, and trying to get a lot of people involved in the changes and make sure we’re taking all kinds of viewpoints into account that is going to be useful for a broad range of people.

    And then, with the SaaS layer we’re basically saying, ‘Okay, we know have this opinionated, this is how you should be using this, and this is we’re going to codify the happy path, the way that you, the easy, couple-of-clicks way into the product that uses all of this crazy technology that we’ve built.’

    Steve: Yeah, and the contrast there is really interesting because open source tools almost by definition have to appeal to a wide audience, you want as many people as possible adopting them and contributing to them. That’s I think a big part of how they develop traction is you get an engaged community of developers who want to help, and SaaS almost seems the opposite, that, a really common startup mantra is this: ‘Make a few customers love you as opposed to a lot of people like you,’ and so, making a great, polished experience for a much smaller number of people seems really important to developing a SaaS business.

    At Opsee we’re dealing with this too, we’re only SaaS, we have no open source component, and so we really are trying to focus on a narrow set of use cases, and then make them as polished and perfect as possible, and we are competing with open source tools. So, sometimes we will see these responses like, ‘Oh, why would I pay for your tool when I can get the open source for free?’ But then there’s this back and forth about the development time required to customize it, and the different nature of those kinds of tools.

    David: And operating it, you know, it may be free, but somebody has to run it, somebody has to write a page up for it, and it’s easy to lose sight of that stuff.

    If you’re interested in being a guest on the show, or if you have a DX topic you’d like us to dive into you can reach us at dmmc@heavybit.com or @dontmakemecode.

  • A Life in Code

    The Lifetime of a Developer
    “There is no single development, in either technology or management technique, which by itself promises even one order-of-magnitude improvement within a decade in productivity, in reliability, in simplicity.” –Frederick P. Brooks, Jr. http://bit.ly/1IOVbPG

    — ROELBOB

  • On beginning software delivery acceleration

    On beginning software delivery acceleration

    Time and time again, we hear of companies achieving rapid acceleration with DevOps. Companies are touting success with the metric of deploys/day, sharing new baselines of 10, 50 or even 100 deploys/day. In more mature organizations the likes of LinkedIn, Netflix, Etsy, Facebook and others, this number is a startling 1,000+ number. But, what does this even mean?

    Unpacking this number is often one IT leaders stumble on, and is the greatest source of pushback when talking about rapid acceleration. How stable is the software being delivered? How many of these deployments are successful? What constitutes a deployment?

    These questions and more often end up creating analysis paralysis, and nothing changes. In fact, the most common response starts with, “There is no way we could implement something like that at my company because…” We know this to be false. Companies who have traditionally delivered in a waterfall fashion with a single, bloated deploy per month or quarter are successfully transitioning to rapid deployment posting similar baseline numbers as other teams.

    How then can you be successful in beginning software delivery? There is no single silver bullet or magic wand, but there is a fairly prescriptive methodology for achieving our goal of rapid delivery. Let’s dive in and take a look on how to get started.

    Ground Rules

    Let’s set the stage with some key principles that will light the path ahead. They are:

    • Embrace failure
    • Blamelessly analyze failures1
    • Quickly repair failures when understood
    • Always be iterating

    In a nutshell, the goal should be to Deploy Fast, Fail Fast, Learn Fast, and Improve Fast. This is a never-ending task, and it is important to consider it as such. Too many times, a project is spun up to start working on these tasks, and inevitably that project ends. Unless continual improvement becomes a core tenant of delivery, any efforts risk falling apart at the seams over time.

    With these rules in mind, let’s continue.

    How is software developed?

    The first stop is incidentally not within the delivery organization, but rather the development organization. This is where the empathy that is so often discussed alongside DevOps will come in; we first need to ensure the developers who are delivering features are equipped for success.

    How is software developed? What does it really mean to get into the flow of production? Ask yourself questions like: how is code introduced into the source tree? What does acceptance of that code look like? (For example: are there code formatting guidelines, are tests needed, etc).

    Once this is understood, the key is the gate that exists to advance code to the next stage of delivery. This is where bottlenecks often exist, and often have valid historic cases for existing. Usually, this is to try and improve quality by introducing checkpoints, but these checkpoints are often human driven, and will invariably contain defects of their own.

    It is important to make the distinction around delivery of code or delivery of features versus the delivery of the software itself. Both are important as illustrated in the next section, but two sides of the same coin that are often separated duties. In the context of the entire system, the need is the same: identify opportunities to reduce friction by either removing steps from process (non-value add unnecessary, vestiges of old days) or introducing automation to move things along.

    These conversations are always enlightening, as it will become pretty apparent where the slowdowns occur after some initial conversations. Keep those brain juices flowing, and let’s continue.

    Keep in mind:

    • Who can write software? Everyone?
    • What is the barrierto entry associated with learning how to write software?
    • How difficult is it to demonstrate working code to a colleague?
    • How difficult is it for a colleague to run your demonstration code?
    • Who can deploy the software?
    • What is the barrier to entry associated with learning how to ship the software?
    • Where is work being assigned?
    • Where are feature discussions happening?

    Kicking things into high gear

    By this point, it is possible that you have a laundry list of things you have already identified as areas to improve. But, where do you focus? The default tendency is to clean up shop first, and then go work with external teams to try and integrate better. However, that is actually the least ideal thing to do, because it ends up creating silos of isolation. Possibly against your better judgment, plan on integrating first.

    Your first steps should be focused on two objectives. The first of which is to embed yourself into the development work stream… get work items from development via their existing process and find yourself an advocate. This advocate will be your “first follower,” and will help you understand what changes are working and which are not, and will provide valuable and honest feedback that may not come from other members not because they don’t care, but as their energy is focused on other things. It is almost a necessity to start small.

    The point of empathy that comes up most times DevOps is mentioned will come into major play here. No matter what efforts that you make to try to improve things, any friction introduced into the life of a developer will dramatically affect your success in any real change. For example: It may be advantageous for you to change the underlying ticketing platform for you all to communicate better, but if you disrupt the existing delivery pipeline, the odds of making new friends may go down a bit.

    Work with your advocate to firm up how development reports issue to your team and vice versa, and run it through the gauntlet. Do not forget to apply ground rules… Deploy Fast, Fail Fast, Learn Fast, and Improve Fast. Fix easy process holes quickly. Do be mindful of the amount of change that is being introduced at any given time, don’t be afraid to make changes, but also be consistent and measured with this change. This will set the appropriate tone for sustained and long-term process improvement.

    Likewise, do a real project via this first process. One early victory can be to ensure that developers have the ability to run any version of code (git checkout, major version, doesn’t matter) with minimal effort.

    This allows me to run other colleagues’ code to test out fixes, confirm bugs, or whatnot. By having the ability to run arbitrary code, collaboration speeds up closest to the code, and the number of problems that bubble up to later phases of deployment are cleaned up much earlier. This may mean staging environments; this may mean local development environments. But, solving the smaller task of how developers can run code becomes a test bed for how a production delivery pipeline may behave.

    When you find failures in both process and tooling, it is essential to be blameless while analyzing and working through failures. Early on, there will be many, and it is essential to set tone early on. John Allspaw talks about this in his article when he discusses incentives.

    Because an engineer who thinks they’re going to be reprimanded are disincentivized to give the details necessary to get an understanding of the mechanism, pathology, and operation of the failure. This lack of understanding of how the accident occurred all but guarantees that it will repeat. If not with the original engineer, another one in the future. – Allspaw

    Another often-overlooked concern is how these solutions are implemented. Repair of these processes cannot be driven by a single person or in a top-down fashion. Rather, all members of the team must be a part of owning the solution. Time and encouragement will go a tremendous length.

    Finally, deploy. The entire point of this project is to deploy code. The work done up to this point largely will focus on the interaction between Development and Operations, but assuredly there is work to be done on both sides. Until you are able to deploy daily without any breakage, that should be your target. Every day, attempt a code deploy regardless if you know the outcome already. Pick one of two things to fix daily: a failure in the process, or a manual step. Repeat this until you can deploy each day with a minimal number of commands (best case: single command).

    The Path Ahead is Dangerous, Take These!

    As you go along this path, there will be two themes that appear to come up time and time again. The first has to do with communication. Processes to deploy may get faster or more streamlined over time, but there are always ways that communication roadblocks cause challenges for the best of teams.

    The second always has to do with tool disparity. Once engineers get wind that tools need to be implemented, all people and process concerns become secondary. This typically becomes a quagmire, as these tools need to actually participate in the communication streams within the organization to facilitate software delivery.

    To this end, there are two tools that are very beneficial to keep in mind as you go down this path: ChatOps2 and Workflow3,4. Both of these topics deserve entire sections dedicated to their own right, but in a nutshell, here are the two things that should whet your palette.

    ChatOps brings the context of the work you are already doing into the conversations you are already having. – James Fryman

    Human readable, machine scriptable language for declaring workflow is not just convenience. It’s a necessity for dynamic creation, uploading and updating workflows on a live system, and for treating “infrastructure-as-code.” – Dmitri Zimine

    Just remember: it’s not about one tool. These tools are a means to an end. The people and process have to be part of this conversation. ChatOps enables the communication and collaboration that creates and drives the development. Workflow enables collaboration around infrastructure process. Both of these will become essential.

    Closing

    To succeed, we as technologists need to know what’s going on in our organization, how technology efforts are helping delivery, and how the technology being deployed is being consumed and by whom. Without this understanding, we’re just throwing tools at a problem and often wind up complicating matters. These tools can jam things up or become shelf ware because nobody is ready to implement them. And in the rapidly moving, lean businesses of today, there is no time for breakdowns.

    Do you know how your teams deliver and collaborate around software? Do you have a tight feedback loop established between your teams and those you provide services to? Are you moving fast, and fixing even faster?

    How teams deliver software today is quickly being recognized as a market differentiator. This journey is neither easy nor quick, but will enable your organization to be prepared for the next phase of rapid growth in the industry.

    ###

    1https://codeascraft.com/2012/05/22/blameless-postmortems/

    2https://speakerdeck.com/jfryman/chatops-technology-and-philosophy

    3http://stackstorm.com/2015/04/10/the-return-of-workflows

    4https://www.slideshare.net/slideshow/embed_code/key/cHCIlAlU4Xb1Lw

    About the Author/James Fryman

    ph-james-2015-05-12James Fryman is an Information Technologist who builds, designs, curates, and evangelizes automation in all layers of the IT stack. Over the last decade, he has held roles in Information Technology that include the domains of Information Security, Service Delivery, IT Operations, Development, and IT Management. He has learned through these experiences the importance of automation in all facets of Information Technology to accelerate delivery, reduce human errors throughout an application lifecycle.

    James most recently worked at GitHub assisting in the development and curation of systems scaling within the Operations group. He is also a frequent speaker on the topic of automation at conferences throughout the world.

    James holds a BS in Information Technology from the University of Phoenix.   Twitter: http://www.twitter.com/jfryman

  • Part Dev, Part Ops

    Part Dev, Part Ops