Transcript

Introductions [00:38]

Shane Hastie: Good day folks. This is Shane Hastie for the InfoQ engineer in culture podcast. Today I have the privilege of sitting down across many miles with Kevin Boyle from Gearset.  As has been the case almost all the time over the last couple of years based at home in New Zealand and Kevin is in Cambridge, UK. Kevin, welcome. Thanks for taking the time to talk to us today.

Kevin Boyle: Oh, thanks very much for inviting me on and thanks for me time. So late in your evening to juggle all the time zones and make this work looking forward to the conversation.

Shane Hastie: Indeed. So probably a good starting point. Who's Kevin and what's brought you to where you are today?

Kevin Boyle: I'm Kevin, I'm the CEO here at Gearset DevOps vendor for Salesforce and Low-Code space. I'm a Software Engineer by background. So I built a bunch of Gearset's original technology and platform. And then as we scale the company, I now sort of hold the dual role of CEO and head of sales. What that allows me to do is have a bunch of really interesting conversations with folks bringing DevOps into their companies, what DevOps means to IT organizations, what it can mean for Salesforce or AWS or GCP or what those customers are actually going to do within their businesses by bringing DevOps.

Kevin Boyle: I have that really interesting role means I get to speak to lots of different folks about this topic. And as anyone that has ever worked at a startup or started a startup knows that is pretty much all I've done for the last five or six years. But it's been really, really good fun as we've scaled the company from the original sort of four or five that were there at the beginning up to now 130 something people across multiple continents and multiple offices. And it's been a very fun journey.

Shane Hastie: Let's start and explore. What does it mean when we talk about no-code DevOps?

No-code DevOps? [02:23]

Kevin Boyle: I suppose it's interesting to explore what DevOps really means, which is this mixture of philosophy within a team, how they want to build their solution, the processes they use to go about that building, and then the tools that underpin the whole sort of building then delivery pipeline. So no-code DevOps is really DevOps for those platforms that allow you to build software, not through reams of C-shape or JavaScript or TypeScript, but by doing no-code programming, drag drop programming, or expressing little buildable components like the Lambda functions and things that you stitch together. And the area that we focus on is Salesforce and Salesforce is a, really misunderstood by a lot of folks platform, which I think it's super power is that it allows low-code programmers to software engineering developers to come together and each bring their best to the software you're building and then a no code DevOps solution is one that underpins that. Those folks still have the same collaboration challenges, the same need to use version control and all this effective tooling.

Kevin Boyle: So how do you provide a DevOps process and solution that brings just a traditional software engineering background and low-code programmers? How do you bring those folks together into one coherent process to allow them to build their solution on top of no code platforms?

Shane Hastie: Let's explore that. How do you bring these two quite distinctly different paradigms together?

Kevin Boyle: I think it starts with understanding what you actually want to achieve. What DevOps was started for, which is around that cultural shift that came out of the Agile development software movement, where you didn't want to do massive planning cycles and massively long spec cycles, then big building cycles, all that sort of stuff. So it was around reducing the of length time to get our idea expressed as software and then out to our users so they can test it. And the interesting challenge with bringing together those low-code developers to a classic software engineering persona is just how they come at the problem. So if you take someone that's grown up right in TypeScript and working from the CLI they approach Git and GitHub and Git provider of choice with, I just have totally different lens than someone has come from a BA or business analysis background.

They aren't as comfortable generally generalizing here, but generally they aren't as comfortable with CLI tooling because they haven't been doing it for years and years and years and years. The same with Version control, relatively new concept to a lot of these low-code platforms. So you need to provide a smooth on-ramp for those folks so that they can collaborate through Git, but in a way that's more accessible to the folks that aren't comfortable in CLI then the tendency there is to create a totally bespoke solution, which doesn't use Git. And then that means that you would exclude folks that are really happy with the CLI.

And so what we do here at Gearset is try to provide a solution that is incredibly accessible to folks that aren't comfortable with the CLI or don't come from that background, but also is still built on all the great foundation of continuous integration, continuous delivery, version control, so that anyone coming at it from the classical software engineering process can still take part. So I guess it all comes down to simplicity, accessibility, and allowing folks to have the tools they need to take part in a really mature process without all the complexity of the tooling that would normally go alongside, Git, EKS, AWS, all these CLI tools, all these YAML files get rid of all that sort of stuff, hide all that complexity, which can be really off putting to people and has a very steep learning curve if you're not from that world.

Shane Hastie: How, and this touches on one of the reasons that we got together at all, was to talk about training needs in this space. What is it that DevOps engineers from either of those perspectives need to be learning about today?

What DevOps engineers need to learn [06:35]

Kevin Boyle: For technical leaders bringing DevOps into their organization? I think one of the really misunderstood things is that folks think it's bringing a piece of software to solve whatever software delivery problem they've got. A really successful DevOps process requires that you critically evaluate what your software delivery looks like, where the bottlenecks are, and then put in place the process and tools to fix that. And then that's true for training needs as well, right? If you had a learning development budget at your company and you were going to do some courses on DevOps or training on DevOps or cert on DevOps, you might be inclined to go out and get some AWS or kubernetes certs or whatever it is. But I think it's more important to properly understand what the challenges within your software delivery and make sure you're training for the right thing that could be collaboration and how folks actually decide what's being built.

It could be just, Hey, we need to modernize how we do things, get certification on Kubernetes or container or whatever it is like, how all this stuff hangs together. It could be as simple as that depending on what you're building. And then for the folks that use Gearset in particular, the sort of low-code and Salesforce users, it's all about bringing the benefits that other platforms have seen through DevOps to this low code and Salesforce world. So for them, it's very much understanding how source control works, how to engage with it as a team, how to make sure that your software developers and your Low-code developers can all work effectively together.

So those training needs are very different, which is why we started DevOps launchpad, which is a training and certification site for folks coming from the Low-code world so that they can see how DevOps can be applied to their sphere specifically, and then provide training around it, but tailored to that audience. And without the assumption that how to use Git really effectively or all the other things that most DevOps training needs will sort put on you, they have a bunch of a certain knowledge, which isn't there for a lot of folks.

Shane Hastie: You touched on DevOps as a culture, as opposed to buy me a DevOps and just install it. When we drill down into that, what is that culture? And what are the cultural shifts that organizations need to make?

DevOps as culture [08:54]

Kevin Boyle: There's a bunch of cultural prongs to it. And as I said, I think they all came out of the Agile Software Movement, I think it almost starts from a position of humility, where we don't know if what we're building is the right thing. We've done our research, we've spoken to our users, it's a good educated guess. But ultimately, we don't know for sure. And if you operate from that starting position, then you want to get your software out to your users, be they internal business users, or if you're building a product or whatever it is you want to get the thing that you're building out to folks as quickly as possible and not through crunch or unsustainable practices, but by really understanding what's the smallest piece of work that we can deliver, that usefully moves us in the right direction and then allows the users to give us feedback that would influence the next thing that we built.

And then you start to iterate and iterate and iterate and you get that nice momentum and feedback cycle. So Agile software did that very effectively for the building phase of software, but then with the rise of SAS and hosted services, a whole new bottleneck arose of how to get that software that you've built that nice small slice that you're really ready to get to users.

How do you actually deliver that to users? How do you get it out there? Make sure that it's working well, make sure that if there's bug reports, they're coming in and correctly, if you're operating a Google scale, or the canary builds stuff, how do you do that? How do you get that next little bit and so DevOps for me is that it's about widening that lens, the software development lifecycle doesn't finish when you have that nice compiled artifact ready to go, it's when your users are using it. And bringing together those two distinct teams that used to be responsible for that the folks that build it, got the nice compile an artifact, and then handed it to some ops folks to get out to the users and stairs said, Hey, we're one team, we're responsible for taking this from idea through spec through to build through to deployment through monitoring, because all of that is getting it from idea to our users, which is ultimately the cultural shift.

I think that's the big thing that I end up speaking to users about a lot is how to start from a position of, well, we don't know if what we've done is 100% correct. So how do we get to the smallest core of what we can build, get it out to our users, get the feedback, and make sure we're taking that from one end right to the other.

Shane Hastie: You mentioned that you spend a lot of time talking to clients across the industry. What are some of the trends that you're hearing about?

Trends from the marketplace [11:29]

Kevin Boyle: The biggest trend for us and the space that we operate in is the desire for the digital transformation to really impact all businesses and all back office systems. And then how DevOps underpins that. So that need to do small slices delivered iteratively, incrementally to allow users to give feedback that has been fairly commonplace in good product organizations. For a long time, there's been like a market imperative to make sure that you as a product company, are doing enough to stay ahead of your competitors. I think we're now seeing how to play internal IP, in much the same way that perhaps didn't have that focus a couple of years ago. But businesses now understand that those back office systems and IT systems are just as important, if not even more important to their success in the marketplace and their competitiveness in the marketplace than any product that they build.

If they can't connect with their customer, engage with their customer, if they can't service their customer, our whole expectation of what it means to interact with businesses has just increased. We as an audience are much more demanding of the companies that we interact with than we ever were before. The piece that those companies have to move at has no changed, just step changed in terms of what we expect from them. And all of those internal systems that power that, that maybe previously didn't get the love and investment that they were really entitled to all along, that has now changed, I think there's been a shift since we started Gearset, in terms of the ambition of what those teams want to accomplish. That's what it starts with. And they want to accomplish it because well, because they're good engineers, and good developers, and they'll want to build great software, they've always had that desire, now businesses understand that digital transformation, and DevOps is gonna be key to their success.

And so they're finally been given the space to go and build up those platforms, build up those teams and then how DevOps can impact that. So that's one of the biggest shifts we're seeing. Gearsets in a really interesting position because we are very, very easy to get started with, so we're all about what we call our DevOps maturity model. We make it really, really easy to get going and solve the immediate tactical problem that you have in front of you. And then we'll work with you to increase the sophistication of your process as you're ready for it, and then give you the software and tools to underpin that more sophisticated process. So start off with just the fact that we're using version control for a lot of teams, that's a pretty big shift for them, then bring in CI, bring in monitoring, reduce your kind of recycles a lot of stuff. Because we're so accessible to get going with we work with a lot of small companies that are just getting going. We also work with lots of this sort of Fortune 10 and fortune 100.

And it's interesting just across the entire spectrum of all of these businesses, they're all saying the same thing, which is this digital transformation to transform their back-office systems, to allow them to move faster and be more agile for their customers. I don't think it's anything sort of new or novel because some of it was coming from product companies four or five years ago. But I think that big shift is that it's now been applied to internal IT and they have all of the same expectation ambition of technology that was exclusive to Google and Facebook a decade ago.

Shane Hastie: How does an organization know how well they're doing? There's things like the accelerate metrics that are out there, but how do we know how well we're doing?

Using metrics wisely [14:57]

Kevin Boyle: I think there's a bunch of ways you can look at this and it probably does require a broad lens across a few of them. As you mentioned, there's the kinds of quantitative metric driven stuff you can take a look at and Gearset does that we do a state of DevOps report say the state of Salesforce develops reports every year to try and gather quantitative data. And then there's also the quality of data of what's your business trying to achieve and how well is your software teams actually did everyone against that. I guess crudely metrics are always double edged so they're definitely a double-edged sword where you can game every metric, right? Put it up on a board and tell me you want to increase the number of releases that I do to production and I'll start releasing every day, but it won't be very valuable.

I think you need to always couple the quantitative stuff with the qualitative stuff of what were we actually trying to achieve as a team. How was that going to roll up to what our business is trying to and do we feel like we've got the process and tools to actually make that happen? I think for the teams that we interact with, for sure, probably the most impactful one is that release velocity though, as long as you come at it, not gaming it as long as you come at it, just like an honest broker, that release velocity, how long does stuff sit on the shelf? What's your inventory look like? How quickly can we get from we cut the branch and we start doing work until that branch is merged with our users and we're getting feedback on it.

What does that end to end cycle look like? What does that look like? Is it 24 hours? Is it 48 hours? Is it two weeks? How quickly can we get that done? Which requires end sophistication in product manage, how you pull apart features, how you get to the nucleus of what the users are actually looking for. There's a whole bunch that goes into that overall metric.

Shane Hastie: There are some new buzzwords coming around, but I'm hearing DevSecOps is one of them. And there's also BizOps, have you come across these, what they really mean?

Building in security [16:52]

Kevin Boyle: DevSecOps for sure is what I've come across, Biz ops I haven't maybe that's sort of like the sort of SassOps or Low-codeOps. DevSecOps is again the idea that software is now one of the primary vectors that you can use to attack organizations, all of the hosted products that we have, our supply chain attacks, you probably struggle outside of certain verticals and industries and things to find any company that isn't using some open source components or if you're using things like NPM or NuGet or Maven or whatever for your platform package managers and open sources is a massive component of modern software delivery. So are we really auditing every single one of those components when we do an NPM update and NPM broadly informs us that we've taken 400 updates and 70,000 changed lines of code.

Kevin Boyle: So that's a really interesting attack factor. We then have more and more hosted products, especially over the last two years. Companies have been forced to embrace remote working the idea that we can use the sort of company network as a defense that's gone. So you sort of move to the Google zero trust model where stuff has to be on the internet, but then has to be secured either through nice authentication authorization mechanisms. But again, you've just got this massive attack factor. Now into companies that didn't exist 20 years ago. And so security has to become part of your thinking, has to become part of how you reliably deliver that software to your end users, the same way that 10 years ago you might have been tracking for defect rate or performance and production. All those sorts of things security now know has to be a part of that conversation so that we have reliable, automated ways to make sure that the software is statically verified as much as we can to make sure that we're not introducing security vulnerabilities.

Kevin Boyle: And that could be through static code analysis, things like PMD or check marks or the 10 million products that exist to do that or it could be through sort of dynamic analysis where you're at runtime, checking for anonymous behavior, all those sorts of things, interest and activity at the network boundary or all those sorts of systems or even architectural stuff where you're checking for layering to make sure that within your system, that there's defense in depth so that somebody breaches that, breaking that outer boundary, you have to assume that's going to happen at some point. So if somebody does break that outer boundary, what are they going to find? What's the blast radius of that failure? So all of that has become part of the DevOps conversation in the same way that performance monitoring or defect monitoring was 10 years ago.

Shane Hastie: And how do we make these systems robust? And for want of a better term secure.

Building robust and secure systems needs cultural shift for many organisations [19:39]

Kevin Boyle: Maybe folks won't like to hear this, but I would say that that's still best effort. Again, it comes back to the culture of whether you look at DevOps or DevSecOps as a piece of tooling, or if you look at as cultural shift. So if you look at it as a piece of tooling and you bring in a great DevSecOps product, whatever it is, you bring in a bunch of products to build that pipeline. And you think that that's going to protect you. Then at some point in the future, you're going to wake up and your cell phone's going to be going off and you're going to be very, very upset with that.

So it is that culture of getting your team to think through that, think through when they take that dependency, when they expose that service to the internet, when they, whatever it is to get that security culture into your whole life cycle. For Gearset, we're a host of product and we connect some of the world's largest companies’ Salesforce instances so we are really interested in the attack factor because if we breached us, we hold a lot of really sensitive things on behalf of our clients.

And so that we have that baked into our cultural mindset from anyone that joins the company. I have this kind of talk where it's like, we might be a small startup, few hundred people, but what we protect on behalf of our clients and what they trust us with, it would be market moving things. So we need to treat that with the care and respect that it deserves. And that does come down to cultural process, having your engineers and folks think about that, then having static verification tools to help them think about that, then having automation through your build pipeline, making sure that you take a security review of everything that's happening. Have you applied defense in depth principles, making sure that folks externally are doing pen testing against things, starting to trip wires and things. So we protect everything. All of our internal systems are also exposed to internet and we use CloudFlare access as that sort of outside gatekeeper.

So we assume that at some point, one of those systems will be breached. We sort of start from that position. We desperately hope it never happens. And we take upmost care to make sure that it doesn't, we start from that position. So we pick CloudFlare access to the outside. So now you have to breach CloudFlare access. Okay. So if you breach CloudFlare, well, there's going to be a lot of upset companies and we'll be one of them. You then hit our next layer of auth, which again we use OAuth, because we were Google workspace customer. So then we have G-Suite auth internally against our own services. And then if you were to breach any of those services, they all have just this idea of use the least possible privilege, the least execution, runtime, the least exposure so that if you do breach any of them, you then can't hop sideways, anything else.

And we still have that only the paranoid survive thing. We still just have that baked into the culture of, we assume that this is going to happen at some point and make sure that our pen testers, we share source code with them. We make sure that they have every tool they have to attack us and make sure that if one of those layers was to fail that it would be harder and harder to get any further. So I think it is a cultural shift for companies to care about this, to care about the data that they hold, to hold the least data that they can - you see with things like GDPR, CCPA, don't hold data. You don't need to.

Then it's very hard to exfiltrate if you don't have it and make sure that that culture is throughout your organization and then tooling to support that. So bring in GitHub Dependabot or Snyk or whatever, like to make sure that you're staying on top of CVS and you're doing those basic Jule, but don't rely on that to see those as purely basic Jule, just like absolute table stakes hygiene factors and the cultural shift is what you're actually trying to get within your organization.

Shane Hastie: That's a great example of how you drink your own champagne. What are some other lessons from what you've done internally that you can share with the audience?

Lessons learned and shared [23:33]

Kevin Boyle: I think one of the big things that I found prior to starting Gearset, I'm just a true believer in the idea that if you can get those feedback cycles on whatever you're doing to as short as possible, then you are in a much better place to succeed that ultimately you can be more effectively guided by your customer to build a thing that they want to solve the problem they have now make you successful in the market. And that can be as true for Google iterating the color of blue on their homepage to check engagement, or it can be true for Gearset, building DevOps product for local professionals, or it can be true for folks on an internal IT team, building out the next Salesforce improvement to help model some internal business process that that's okay of a universal truth that we can get those feedback cycles to as assure as we can.

And that will help us be more successful in whatever we're doing. And then as you say, we drink our own champagne, we're Salesforce customers. And we have built our business on this idea that our internal systems are just as important as our external systems. And so how do we have world class process and world class tooling to support everything across the board. And then it's helped us scale to the market leading DevOps solution for Salesforce professionals. So I mean, made our success down to lots of things, amazing team, bit of luck, time in the market, all that sort of stuff, but definitely that ability to move fast and learn via what we're doing, that we are doing the right thing and pivot when we're not doing the right thing, that has been a massively impactful way to build software.

Shane Hastie: Thank you very much for that. Some great advice and good thoughts in there. If people want to continue the conversation, where do they find you?

Kevin Boyle: I'm @kevfromireland on Twitter, or you can connect with me on LinkedIn as well, where I think I'm @kevfromireland or as @kevinfromireland, depending on character limits. I can quite remember which I am, but if you search Kevin Boyle Gearset, you'll probably find me. And I do love to talk about this stuff. As I said, anyone that has done a startup or worked at a startup or they do become all encompassing. And my last five, six years have been having conversations like this just all the time. I'm very passionate about this subject. I'd love to connect with folks. If you're bringing in a DevOps process for Salesforce low-code systems, obviously Gearset as a whole can help you, if you're bringing in a DevOps process for AWS or Heroku or whatever, then. Yeah, absolutely. I just love having this kind of chat. So please do reach in.

Shane Hastie: Thank you so much.

Kevin Boyle: Thank you very much, Shane.

Mentioned:

• Gearset
• DevOps Launchpad
• Salesforce
• CloudFlare
• Dependabot
• Snyk
• Kevin on LinkedIn