[INTERVIEW]
[00:01:34] Guy Podjarny: Hello, everyone. Welcome back to The Secure Developer. Thanks for tuning back in. Today, we’re going to take a walk more in the developer’s shoes, and to help us do that is Daniel Bryant, who is the Director of Dev Rel at Ambassador Labs. Daniel, thanks for coming on to the show.
[00:01:49] Daniel Bryant: Thanks for the invite, guy. Always great to chat with you.
[00:01:52] Guy Podjarny: Daniel, before we dig in, we’ll talk a lot about the new reality of developers, and specifically as it comes to security, tell us a bit about what it is that you do and your journey coming into it?
[00:02:02] Daniel Bryant: Yeah. At the moment, Guy, I’m Director of Dev Rel at Ambassador Labs, so working on a lot of strategy around how we engage with communities, how we talk about our tools, how we help developers. We also listen a lot to developers and the challenges they have with developing microservices on Kubernetes in particular. Learning a lot from a lot of very interesting folks across all range of communities; Java, Go, Node, Python. Many commonalities, many differences, right? It’s very interesting, like learning from different folks.
My background, I like to say, my native programming language is Java. I’ve done Go and JavaScript over the years, but I cut my teeth at college, at the university, on Java and it was the first commercial language I used. I actually started as an academic, I did a PhD. I don’t talk about this as much, but I did a PhD in AI. I wanted to be lecturer, but I discovered.
[00:02:49] Guy Podjarny: I didn’t know that.
[00:02:49] Daniel Bryant: Yeah. It’s one of my random facts. But I discovered halfway through the studies that, I was doing some moonlighting Java development and web development, and I really joined the practical side of the work. So I finished the PhD, but I’ve moved into more software engineering. I’ve worked from everything from the UK government, to small startups. I was consulting in London for a while with an awesome company called OpenCredo, still going strong. And I got to see all sort of walks of life. I worked for financial companies, worked with e-commerce companies and I worked with some amazing people, both at the company there and also all the engineers I got to see on my consulting travels.
One of my strengths I sort of understood over the years was the ability to bridge between the super techy folks and the other folks; stakeholders, customers, developers, end users. That’s led me more into the role I’m doing at Ambassador Labs now. Being the bridge, we are very much engaging with developers but perhaps, they don’t know Kubernetes super-well, perhaps they don’t think about security, they don’t think about observability, they don’t think about testability. My role is partly sort of meeting them where they’re at and bringing them along on the journey with all the experience I’ve had doing all the stuff in the past.
[00:03:58] Guy Podjarny: Super interesting and a problem that is more relevant than ever. Just for context for folks, can you tell us a bit about Ambassador Labs, just to, again, relate what you’re talking about. Stuff that you do in your day-to-day. What’s the context there?
[00:04:11] Daniel Bryant: Yeah. We are focused on minimizing friction for developers to deliver value – a bold statement, but we recognize that a lot of folks are modularizing their architecture these days. They’re moving into microservices, all these good things. They’re moving to platforms or foundations of platforms like Kubernetes. Kubernetes is a fantastic foundation. I chose that word deliberately there. It’s not a fully functioning platform, like you may see with Heroku or Cloud Foundry. We give people the tools, the practices and processes to create a platform experience they need on top of Kubernetes. It’s all about being able to find what’s going on, fix problems and maybe actually fixing in a production like environment or staging like environment, like our Telepresence tool. We use that a lot, CNCF tool.
We also talk a lot about releasing. We’re really interested in things like progressive delivery, which is sort of an extension to a continuous delivery, and observability. Even things like security come into this. We’re really keen to enable developers to close that loop. You have the business idea, you develop, you test, you release, you observe, you understand, then you kind of close the loop with your next steps. You’re always looking at things like SNIs from a more lower-level infrastructure kind of vibe. Security definitely falls into that as well. And you’re also looking at kind of KPIs, more of the high-level business goals as well. We enable folks to kind of understand and close the feedback loop on that.
[00:05:35] Guy Podjarny: Got it. Thanks for the overview here. The real kind of topic that we want to dig in here is really this reality of developers. We talk a lot in security about shift left, or top to bottom, or dev for security and how we want to move security into development. But we kind of take this lens saying, “Hey! Developers should pick up security,” and we kind of put aside or oftentimes forget or choose to ignore the fact that there are many other words other than security that complete that sentence that developers should also care about. That’s a bit of a tough load to move to developers in this reality.
Maybe let’s unpack what that means a little bit. First of all, what do you see as the key umbrella terms, big ticket items that are moving to the responsibility of developers above and beyond security. What are the other things they need to battle with?
[00:06:32] Daniel Bryant: A lot of it boils down to the ‘-ilities’. We used to call them non-functional requirements, now cross-functional requirements because non-functional requirements is a bad choice of words on those, right? They’re very much impacting the function of —
[00:06:43] Guy Podjarny: Part of the functioning, yeah.
[00:06:44] Daniel Bryant: Yeah, 100%, right? For me, a lot of it starts with observability, whether you’re looking at it from a security lens, from a testability lens, even from an understandability lens, because we are building these complex adaptive systems there, right? Being able to think about and bake in observability early on is really key. A lot of developers, myself included, when I started my journey, it was more about — you look at the functional spec, you code it up, you test it from that angle, and you ship it and you’re kind of good to go.
But now, we need to understand, how is it performing? Is it costing us a lot in the cloud? Would the algorithm be better to be tuned to a certain way to give you more performance? And what are we exposing in the application?
Without having metrics, quality things like logs, traces, sort of the three pillars, as a lot of folks talk about, of observability. Without baking them in on day zero, it’s really hard, I find, to retrofit those things in. So for me, it often starts with observability. If you can’t understand your system, if you can’t ask these kinds of ad hoc questions, it’s really hard to do all the other things, in terms of layering on security, layering on resilience. If something breaks, you don’t want it to take down your entire system. But if you don’t understand what’s breaking and what the impact is, it’s really hard to do that. Then you lay on even things like maintainability, extensibility. Again, the ability to observe, to understand, is foundational for that. In order to actually successfully expand your system, you have to understand the pain points, the friction points.
If you think about things like no value streams from a business context, it’s the same in engineering, right? Definitely, I worked in a few systems where we were tweaking the system to be more performance, and we didn’t actually know if we were tackling the bottleneck, right? It’s really ironic looking back at it while we did it but now, I would say, “Best run lots of tests, understand where the bottlenecks are, understand where the problems are and fix that thing first.” But I’ve definitely worked on a few teams where we guessed where the problems were and we dove in and we sometimes fixed it and we sometimes didn’t.
[00:08:46] Guy Podjarny: Yeah. It creates flashbacks to the world of purify and quantify from the early days, where I spent a decent amount of time there trying to understand memory allocation or speed. I never really kind of applied the term observability to it, but really, that’s what was lacking there, which is, we had these tools and we just didn’t know where the time was going or where the memory was going.
I guess if I echo back and I think I’ll add a couple to your items is, there’s kind of the testing or testability. Arguably, that’s been the original requirement, or maybe the original requirement was to build functionality and then testing is moving more and more into dev. Presumably, they were already responsible developers or already responsible for building something that functions correctly. But the process of testing it is probably the first thing to sort of move. Maybe that’s an agile movement shift, so maybe it kind of predates. Then you’re adding observability as an underpinning to — we talked about resilience and we mentioned performance. I think those are good ones. They’re all related to security, but they’re not the same, so security is clearly on the list.
I guess two others that I would add. One is probably a bit more niche but it’s accessibility.
[00:09:58] Daniel Bryant: Yeah, interesting. Yes.
[00:10:00] Guy Podjarny: I guess it shouldn’t be niche, but it’s just not as big an industry, so probably it doesn’t come up. But maybe an interesting one is privacy. We didn’t touch on this too much, but you also played a role in InfoQ and QCon.
[00:10:12] Daniel Bryant: Yeah.
[00:10:12] Guy Podjarny: So I’m kind of tapping a bit also into your view of what you see submitted there and what you see discussed. How much have you sort of seen privacy rise in terms of like a developer oriented or developer first privacy, or the requirement for developers to care about privacy needs?
[00:10:29] Daniel Bryant: Yeah. It’s a great question, Guy. I’ve definitely seen it sort of a couple of angles with the QCon conferences for sure. In Europe we have the GDPR regulation that came in recently. There’s the California version, there’s various global implementations as well, sort of a very similar approach. That has definitely raised that topic with developers. Now, the team leads and stakeholders are saying, “Make sure you store the data in a GDPR-compliant way.” We’ve always had perhaps PCI DSS with financials, but now things like GDPR are really sort of raising the stakes. We’re seeing a lot more folks pay attention to those kinds of things.
I think the second thing I’d say is, well, is more from an ethics standpoint. We’re seeing increasingly with machine learning in particular, right? In coding bias and algorithms, these kinds of things and just how you’re exposing data and whether folks can actually join the dots on some of the data. We’ve seen an increased rise at QCon and an interest of ethics. Just because you can do it, should you do it, right? There are those kinds of angles that are becoming quite interesting.
[00:11:32] Guy Podjarny: I actually wrote ethics right after privacy here, in my notes, which I agree, it’s a hot topic that is largely driven just by the power of tech versus necessarily the development processes. But again, decisions are being made at development time, and so that’s the time to consider it. Because later on, just like any one of the problems we talked about, it is more expensive to address it.
[00:11:54] Daniel Bryant: Hundred percent.
[00:11:55] Guy Podjarny: We have this sort of long list of requirements if you will, or sort of full-on spaces. How do we start? What would you say are the building stones to allow a dev team to be able to tackle any one of these? What do we need to provide a dev team to do so successfully?
[00:12:14] Daniel Bryant: Yeah. Another great question, Guy. I think it’s often two-pronged. There’s the education piece. We need to work with our engineering teams or anyone, just to up-skill and raise awareness. It’s the unknown unknowns that always get you kind of thing. Some education really helps with that.
Then it’s providing tooling to support this. I think a lot of what we see around modern tooling is this notion of self-service. Developers are, as we said already, becoming increasingly responsible end to end. You mentioned, testing, observability. And developers like to engage with tools in a certain way. The self-service, I want to plug my thing into GitHub. I want to make it a GitHub action. I want to put something in a Jenkins pipeline that automates these things. Or I want to run the tool locally, but I want to do it by the CLI. You need to meet, I think, the engineers where they’re at.
Because the temptation, back when I was doing a lot more engineering, is we sort of got delivered these tools, you’re going to run the security scanner using this web UI or this swing —
[00:13:11] Guy Podjarny: Like it or not, yeah.
[00:13:12] Daniel Bryant: Yeah, exactly. It was horrible, right? As in, it was typically clunky. You had to run it on Windows and we were all using Linux machines to do our developments. Just a nightmare. I think it is meeting folks where they’re at and giving them that self-service tooling to facilitate that smooth, frictionless experience of coding, testing, releasing.
[00:13:29] Guy Podjarny: I think those are really, really good kind of guidelines around meeting them where they are. I think meeting them where they are is not just a technical statement, right? It’s also almost a mindset element. Meet them where they are also means acknowledging, for starters, what we just talked about, which is, they have a bunch of these other requirements in front of them. But one of the questions that I keep debating in my head, and I don’t know if I’m sounding a bit more looney than I, or maybe like precisely as looney as I am. But it’s really the combination of them.
When you think about education, then presumably, education is it’s own topic related, right? When you talk about how to build an accessible application, or a secure application, or an observable application, there’s some overlap. But they’re probably 80% unique to their, sort of, subject matter.
But from a tooling perspective, we’ve sort of been seeing more merging of things. I can say that in Snyk, for example, we came into it with a dependency management, right? The security risk that we’re tackling, that we tackled in sort of the original product, is really one of the vulnerable libraries. But from a developer perspective, you also had the problem of maintainability, of being able to just like keep up to date with these dependencies. It made sense to make it a part of this new product from a developer lens.
Do you think these would end up with more disparate tools? What’s your view on how to balance the sort of single purpose, because it’s already observability, for instance, you know, it already gives you visibility versus the kind of purpose-built for security and it’s masterful at security or it’s masterful at something else?
[00:15:13] Daniel Bryant: I think it’s a pendulum swing, Guy. There’s a temptation to want one tool to do it all, and then there’s a swing to the other way, like we have a very specific tool to do a very specific job. I spent a lot of time in the CNCF ecosystem. At the moment, there’s a tool for everything basically and it almost leads to the paradox of choice as a developer, “Should I use X, Y or Z to do the same thing?”
When I look at the industries [inaudible 0:15:36] consolidation is happening now and there’s this notion to observability tools as also offering remediation, or security fixes. I think that’s a good thing, because developers, there’s only so much room for us — it is a cognitive load. We often talk about cognitive load. There’s only so much room for us to understand all these different tools and if we’re having to, as part of our regular tool chain, use 10 or more tools to accomplish our job, that’s a lot of context switching. That’s a lot of cognitive load. This tool does it this way. This tool does it this way.
I would imagine over the coming years, there’s going to be a balance. We’re definitely seeing consolidation. But I think some tools will be specific to the job. You know what I mean? They’re just so niche perhaps or they need to have a certain UX for them to be functional. But I think we haven’t as an industry fully find that sweet spot yet. A lot of the things that we’ve been talking about today, you kind of have to think about them in terms of security, and observability and testability. You have to think about them. The tooling should nudge you in that way as well.
I think we’re definitely going to see some sort of tooling popping up that just either encourages the developers to think about all these things or actually verifies how they’re doing and then suggests, perhaps other tools, other practices that can help them think a bit more about what they’re doing.
[00:16:54] Guy Podjarny: Yeah, definitely. I guess it’s the assisted versus — I don’t know what the end of that sentence is. It’s about surfacing a problem to you and then it’s about assisting or helping you to actually address it. Then I guess the end of that road for a chunk of problems is to actually do it for you, right? The sort of the problems like with serverless, things moving into the platform and maybe just removing, going the other way or maybe completing the circle, which is just removing it from your [inaudible 00:17:20]. Do you see that as the path? I kind of wonder whether that path to no code is just the inevitable journey of all development processes? Is that how you see it as well?
[00:17:31] Daniel Bryant: That’s a very thought-provoking question. You mentioned InfoQ earlier on. We’re seeing a lot of interest in low code and no code platforms now. So called citizen developer, community developer. I’m personally fascinated by it. I’ve seen low code, no code tools throughout my 20-year career, if I’m being honest, business process modeling tools and other things, which I’ve still got the cigars for some of those, right?
I do think we’re going to see a lot more adoption of those low code and no code tools. But I also think there’s going to be a whole long tail of different options. I don’t see VMs disappearing overnight in the classic software development process, even kind of classic scrum type processes or even waterfall processes.
I don’t see serverless being the panacea for everything. I don’t see no code being the panacea. I think we will get clear abstractions and also clearer value props for each of those things. At the moment, there’s a temptation to say, “serverless solves all the ills of having to run Kubernetes,” for example. But you’re making that tradeoff, right? As in, if you’re running on a serverless platform, you’re sort of trading off the running and the configurability of that platform to the vendor. You’re happy to say, “Hey! You run it as good as you can for me. I’ll just put the code on top and run that.” That’s a nice tradeoff, right? Because often, the vendors do look after all the -ilities we talked about doing that. Low code is even more, right? It’s just kind of we’re knitting things together from preconfigured options and all the -ilities are done for us. We assume the platform’s going to do those.
But you always have this long tail of existing systems. Some folks, rightly or wrongly, think they’re unique so they want to build their own bespoke solutions. Sometimes this is true, right? Perhaps some governmental organizations do have specific requirements around data security, around privacy. The data cannot ever leave their geo, for example, is a classic thing. So therefore, they may have specific requirements that do mean they’re going to build systems a different way. I think we’re always going to see that gamut, and I think the end of the spectrum around low code and serverless is still quite young, and it’s going to get a bit more refined. But I think the career you and I have, in the future, we’ll always be dealing with some form of Kubernetes or VMs or whatever, even though they may be extracted, there will be something like that running in the background.
[00:19:45] Guy Podjarny: Yeah. I think technologies just never die. They take a long time to support. I mean, it’s interesting. What you’re describing is the pros and cons of constraints. The more constrain to the system, the more the system or the platform can do stuff for you. Assuming it does it well, then it removes a need from you. But the more freedom you have, then the more opportunities you have to shoot yourself in the foot.
Serverless is an interesting one, because I talk a lot about serverless security and serverless is on one hand, it takes something simple like server patching, incorporating system patching. That problem goes away. You’re running a serverless system, someone else is managing the servers for you, including the patching of them. It literally is a full security concern layer just to get to move on to the platform. At the same time, serverless didn’t constrain your use of libraries, so the same risk exists within the libraries. Lo and behold, it’s been multiplied. Because with serverless now, you’re going to deploy ten times as many functions as you would have containers. So suddenly, the risk of a binary in your operating system is being unpatched and being vulnerable. That went away. But the risk of an unpatched library in your code is now multiplied tenfold. The likelihood that you would have it because nothing else helps you. You still need to build a process around it. Every one of these things kind of closes one door and opens another.
But I do think I guess my view of the low code is, that it is a trajectory and that it will be helpful for us. Increasingly, I think there are lessons to learn from the no code/low code coming from the other side of the continuum about how to simplify developers’ lives,I believe. Take practices that they have over there. I’ll give a tactical example. There is a company, pretty cool startup called Salto, which is trying to apply development practices to BizOps systems. What Salto does for instance, they have this little fun — I’m not affiliated with Salto, it’s sort of just something I liked with their tweak. They have a thing where you can actually go to the BizOps systems [inaudible 00:21:45] Sandbox, you can modify things live in that surrounding, then you can pull those into code. Because in that surrounding, you can modify this.
Now, I think in the cloud world for instance, we don’t really do that. In the cloud world, we say, “Well, you have to go back and code it, and then it would be applied to the cloud.” Does it make sense for you to be able to go to a console and modify something in the AWS console or whatever, then pull that back into code. Now, I can argue you for and against it, but I’m just saying, it’s the types of conversations of innovations happening in the world of BizOps that might actually even apply to us further back when you think about easing the lives of developers.
[00:22:22] Daniel Bryant: That is interesting. But definitely something I’ve seen a lot in my career was the use of Excel as the kind of the original low code platform, right? I’ve worked with some amazing people that could do incredible things with Excel. I am thinking a few times like, “Oh! I could code up in a couple of days,” and they literally do a macro and ten minutes later, it’d be done, right? So I’m just thinking that that’s an interesting kind of tradeoff there. If I could design it in Excel or in a cell like UX and then pull it out to code, I get the best of both worlds, right? I can understand, I can maintain the thing a bit better. But that’s a very interesting thinking point, yeah.
[00:22:53] Guy Podjarny: Let’s maybe talk a little bit about removing obstacles. We have developers. We need to educate them about these challenges, and we need to equip them with relevant tools. But what have you seen worked the other way around or what primarily prevents development teams from picking things up? What do you see as the key blockers? Feel free. I don’t know. You can live in the world of Kubernetes and complexities. So maybe if we even use that as a case study and say, when you look at developers needing to understand Kubernetes, needing to adapt their work to work in a Kubernetes surrounding. What are the biggest obstacles, and problems, things developers are having a hard time embracing and why?
[00:23:33] Daniel Bryant: Yeah. I think in the Kubernetes space specifically, and these are sort of personal views I’ve had because really, the community in Kubernetes is just fantastic. It is quite an ops-focused community though, so a lot of tooling being built. It’s fantastic, but I noticed when I’m learning it and I pop along to GitHub or I install something, I have to switch my offspring on. I’m like, “Ah! What was this thing doing? Oh! It’s doing this. How is it doing that?” Then I find myself, when I’m chatting to my developer friends, sort of reverse engineering what I understood through the ops lens to say, “Here’s the problem space it’s operating in. Here’s the benefits and here’s how you use it.” I definitely see a lot of companies, this is what we’re doing in Ambassadors Labs – shameless plug – but we are making it easy for developers to get all the advantage of a platform like Kubernetes.
I think that is one of the key blockers. It’s a fair blocker, because Kubernetes has come from the ops perspective. You are orchestrating containers, you are doing a fantastic job on ephemeral hardware and all these kind of good things. But developers have different goals in mind, “I want to deploy my app super easy. I want to give some rough specifications of CPU, memory, Sandbox capabilities, that kind of thing. And I want it to be informed of what’s going on there.” Well, those are very different goals than like — you can almost imagine the ops responsibilities behind them. But if you’re a developer sort of Googling around, you’re on Stack Overflow, it’s quite hard to find what you’re looking for because you’re phrasing it in your language, development language, “I want to specify CPU, I want to specify memory”, and then the actual steps you need to be quite ops focused, “I want to specify policies. I want to do resource constraints, quotas.”
I think we are seeing this sort of bleed through of language now. Whereas, the more ops-focused developers are taking the stuff on board, but it’s a whole — 95% of developers just want to write code and deliver value in a safe and effective way. I think that one of the key blockers in the cloud space in general is there’s so much to learn before you can do that, right?
[00:25:32] Guy Podjarny: It’s fascinating to hear you say that, because oftentimes in security, we talk about DevOps as the role model of somewhere that it’s been done right. But I agree with you, which is, a lot of elements in ops are still very opsy in this kind of world of DevOps. So they are probably more developer-friendly than most of their security peers, but there’s still sort of a long way to go around really kind of re-thinking. I guess, at any one of these problems, maybe if I generalize a bit the sort of the practice in how we can tackle these concerns, that we need to kind of go back to first principles and say, “Well, if I’m a developer and I’m now being tasked with a new field of responsibility, can we start by saying, ‘What is a developer first X here? What do we need to do?’
In Snyk land, when we talked about open source security and we talked about dev for security, some of the kind of core examples of what that manifested were the Git integrations. So being able to just like move to Gitflows. The automated fixed poll request because the developer’s job isn’t to find issues, it’s to fix issues. We had the dependency tree for libraries. Historically, most tools kind of give you a list. As a developer, I included these 10 ones and they pulled in these hundreds, and they pulled this 500. What are some examples that you’ve seen or maybe they’re even doing at Ambassador that are different? Are there a couple of examples that come to mind of how to rethink, I guess, kind of Kubernetes development with that developer lens?
[00:27:02] Daniel Bryant: Yeah, it’s all about the abstractions I think for us, and sort of, we’re doing a lot of work around service catalog at the moment, so Ambassador cloud product. Recently, we added the service catalog. That’s the jumping off point for understanding the system. Can I understanding all the various components over and above a kubectl describer, or whatever or kubectl services. That again is quite an opsy focused perspective. We’re saying, “Hey! Here’s all your services. You can add metadata to them so you can easily understand who owns what, what the service does. From there, it’s all about making it easy to do your core tasks, “Can I very easily roll out a new version of this service?”
To your point, Guy, around connecting up to Git, we do integrations with GitHub and so forth. We can just say, “New version of the service has been deployed, can you progressively roll this out?” Argo is a fantastic project, CNCF project. It is somewhat ops focused. It gives you excellent config options, and you can use all your standard Kubernetes’ approaches to configure Argo. But we’re trying to abstract some of the key things away for that, so developers can just pop along to their portal, see their service, commit some new code, press this button. Can you roll it out? Ten percent of traffic for the next 10 minutes. Do some tests, make sure is it, from an SLI, from a service level indicator perspective, from a KPI business level perspective, is that new service performing well? If so, roll out the traffic to 30%. So 30% of our users are hitting backend. Do some more tests and so forth.
The abstraction points there, rather than having to learn lots of Kubernetes YAML, if you’re in the Kubernetes space, you know to love and hate YAML, right? Not all developers like to do that.
[00:28:39] Guy Podjarny: Lots of it. Lots and lots of it.
[00:28:40] Daniel Bryant: Yeah. Yes, you always pop the escape hatch GitHub and have a look at some of the Kubernetes config. But your core task, such as releasing — and even things like debugging. We’re doing a lot of integrations with CNCF tools, telepresence. Making it easy for folks to go, “Ah! Here’s the problem service. We’re going to quickly fix the problem, quickly test it, get those fast feedback loops going on and then release in a controlled fashion.” That is the key thing back from my early Java monolith days, it was a binary release, right? You simply deploy and release it at one time, and it’s very tempting to do that into the Kubernetes land. We’re making it easy to folks as possible.
I think you’ll see that just in general, there is a big push towards providing these key platform abstractions that every developer wants on top of Kubernetes and we’re trying to make it as easy for folks to adopt, understand and use those abstractions.
[00:29:37] Guy Podjarny: Yeah, definitely interesting. It’s almost, I’m probably overstretching it a little bit, but you can separate the notion of DevOps as in operators working as developers, which implies a lot of the tools in the space have become development tools that are softer driven. They work off Git and they do all of those, from saying, “Can I have a non-ops developer, not a DevOps person, not a person that ops is their primary identity, be able to operate successfully on their own?” In some areas, we’ve successfully done so, right? With pager duty and the whole — being on call, many aspects of observability, I think New Relic was probably more designed for developers, at least —
[00:30:18] Daniel Bryant: Agreed, yeah.
[00:30:19] Guy Podjarny: — was for operators. So while it’s [inaudible 00:30:22] and I think a lot of the industry that followed, maybe Datadog was even better for ops. New Relic actually jumped a couple of steps too far ahead.
[00:30:30] Daniel Bryant: Interesting. Yeah.
[00:30:32] Guy Podjarny: It’s interesting to think about it, but it’s just that separation between dev tooling and an app developer. We almost need a different name for it, right? We need an app developer versus an ops developer,
[00:30:42] Daniel Bryant: But now you mentioned it, Guy. There is some interesting work going on at the OAM spec. I don’t know if you’ve bumped into that. I think open application model. Microsoft is doing a lot of work in this space. It’s cross plane. I bump into cross plane folks a lot, and they are talking about three core personas. Off the top of my head, I can’t think of the exact names, but they are talking more about sort of app developers, platform folks and then infrastructure folks. It’s a delineation between — infrastructure is kind of literally assembling the platform. The platform folks are tailoring the platform to the development experience. Then the app developers, to your point, simply care about releasing their apps.
I’m following the OAM spec quite closely. There’s a lot of interesting work in that space. I think, just the conversation we’ve had, we’re leaning in towards that. I think many other folks are coming together on that terminology too.
[00:31:25] Guy Podjarny: Yeah, of course. Always, there are smarter people around thinking about these things long before you raise them. Maybe let’s spend a couple of minutes on indeed, community. I’ll use this a bit as a good segue. A part of having developers tackle any new space is really around having the community around them, start educating, right? You can’t expect developers to start going to a security conference, and an ops conference, and a privacy conference, et cetera. How much of that type of change have you seen when you look at, if we use QCon as an example, and you contrast five years back versus today? Are you seeing a significant difference in the topics that come up? Do you see these new areas of responsibility rising in prominence in the talks and the conversations in those events in communities?
[00:32:11] Daniel Bryant: I’m seeing sort of two broadly interesting things. The security track — we always run a security track at QCon because we realize the importance of these things. But the popularity is increasing. We had to move it to bigger rooms. When we’re doing in-person events, we had to move security to bigger rooms. The level of engagement around this has gotten better. More folks provide comments and generally the security track attracts a certain kind of person, and they give very constructive feedback. Often, the security talks perform very well. A lot of the speakers sort of know the audience, and vice versa. They listen to the feedback from the audience. And each year, it gets better and better.
I’d say that from a pure security track point of view, it’s becoming more popular. There’s definitely a dive into the deeper level of security now. We’re definitely seeing that in security tracks. The interesting kind of counter balance to that is we’re seeing security mentioned in all the other tracks. So the architecture you’ve always wondered about is our [inaudible 00:33:09] track, where we look at the architecture of Netflix, we look at the architecture of a lot of the unicorns; Google, Amazon, whatever.
Now, you always hear a reference to security. You hear a reference to observability too. To your point, you often reference for testability too. The Amazon folks, they’ve got their builders library that they’re talking about at the moment. They’ve got a fantastic resource online. We’ve seen them talk in conferences too. But if you look now, it’s not just about the boxes and arrows when they talk about architecture. It’s not just like, “We design the system like this.” They’re saying, “These are the constraints. These are the requirements. We had a zero-trust architecture, because we recognized that threats are coming from everywhere. We’ve baked observability in from day zero because we realized we need to understand these kinds of things.”
It’s popping up even in the other tracks. There’s the microservices track, often mentions security. Even the culture and methods type tracks, they are historically more human-focused tracks. How you integrate DevSecOps. We’ve had some fantastic talks around, is it really DevOps and security? Is it DevSecOps, it’s all together? And how do you encourage leaders to think about these things? How do you sort of like — the agile coaches are getting people to think a lot more holistically now. Thinking holistically, thinking in terms of systems, a lot of system-level thinking. Security is a big part of that, right? Observability, testability are big parts of these things. I think there’s a notion of, some of the tracks are going more specialized, but a lot of these things we’ve been talking about today are bleeding into all the other tracks too.
[00:34:38] Guy Podjarny: Yeah. I think probably that latter, like the security track is important, but it’s almost the conference organizer’s decision. You can be mindful of it versus a community indicator. And the presence of a topic as part of the existing tracks is probably even more of an indicator of true community engagement and appetite to say the [inaudible 00:34:56] when I’m talking about this. I need to address this.
This has been a conversation I really enjoyed, about the new reality for developers and maybe some of the things we can do as an ecosystem. I’ll ask you as a final question here to take out the crystal ball and look five years forward, not backwards, like I said before. And say, what do you think if you’re in your position, trying to lead the community towards, I guess dev first understandability, I think you called it, as such, what’s your reality today? Someone in your position, in your type of job in five years’ time, what would be most different about their reality?
[00:35:33] Daniel Bryant: It’s a great question, Guy. I think riffing off some of the things we’ve talked around low code, no code and citizen developers, I think more and more people are going to be “developers,” if that makes sense. That brings fantastic opportunities, but it also brings challenges. We’ve talked about meeting folks where they’re at, and that’s going to be a big challenge. For a lot of us with a lot of engineering background, we’re very comfortable with fellow engineers. But when you start getting what we would historically call business folks involved in the mix, and let’s be honest, we’re all business folks, right, to some degree. But when you start getting folks that are coming up with fantastic ideas, doing POCs, or even bigger systems with these low-code, no-code approaches, you do have to think that level deeper as those systems get more adoption. You do have to think about sustainability, you have to think about cost, you have to think about security, all these things.
Imagine, part of my job in the community is going to be really taking the time to meet folks where they’re at. Now, it’s some degree of, “Are you a Go developer? Are you a Node developer? Are you a JavaScript developer?” I think now it’s going to be — I’m sorry, five years in the future, it’s more around this goal-oriented idea that we talked about earlier in the podcast. It’s that, what are you trying to achieve? It doesn’t really matter whether you’re a Go developer, a low code developer or whatever. What are you trying to achieve and what are your constraints? I imagine the job [inaudible 00:36:52] DevRel is going to pivot a lot more to even more thinking about empathy, meeting folks where they’re at and then understanding of the problem space before then, guiding folks, “Here are your options, here are your tools, here are your practices, here are your platforms.”
I’m super excited. I think the whole developer education space is going to be super interesting over the next five years. I think software is eating the world as the cliché goes and the Kubernetes and the Internet is eating software. There’s just more and more opportunity for us, and I think it’s just really paying attention to the folks going on board on their goals.
[00:37:27] Guy Podjarny: That’s a, I feel a fairly fair description. I would subscribe to that crystal ball of the reality changing and now, it’s just the question of timeline. Is it five or ten?
[00:37:36] Daniel Bryant: That’s it.
[00:37:36] Guy Podjarny: Yeah, cool. Daniel, thanks for coming onto the show. This has been great.
[00:37:40] Daniel Bryant: Thanks, Guy. I appreciate it.
[00:37:41] Guy Podjarny: Thanks everybody for tuning in and I hope you join us for the next one.
[END OF INTERVIEW]
[00:37:49] ANNOUNCER: Thanks for listening to The Secure Developer. That’s all we have time for today. To find additional episodes and full transcriptions, visit thesecuredeveloper.com. If you’d like to be a guest on the show, or get involved in the community, find us on Twitter at @DevSecCon. Don’t forget to leave us a review on iTunes if you enjoyed today’s episode. Bye for now.
[END]
