The Python Podcast.__init__

Share on social media:

[00:00:14] Unknown:

Hello, and welcome to podcast dot in it, the podcast about Python and the people who make it great. When you're ready to launch your next app or want to try a project you hear about on the show, you'll need somewhere to deploy it. So check out our friends over at Linode.   With their managed Kubernetes platform, it's easy to get started with the next generation of deployment and scaling powered by the battle tested Linode platform,   including simple pricing, node balancers, 40 gigabit networking, and dedicated CPU and GPU instances.   And now you can launch a managed MySQL, Postgres, or Mongo database cluster in minutes to keep your critical data safe with automated backups and failover. Go to python podcast dotcom/linode   today to get a $100 credit to try out their new database service. And don't forget to thank them for their continued support of this show. Your host as usual is Tobias Macy. And today, I'm interviewing Ronak Rahman about how automating the path to production helps to build and maintain development velocity. So, Ronak, can you start by introducing yourself? I would love to, Tobias. My name is Ronak, as Tobias mentioned, and I am the developer relations manager at Quali.  



[00:01:15] Unknown:

I am also   a Python  

[00:01:18] Unknown:

enthusiast and happy to be here. And do you remember how you first got introduced to Python?  

[00:01:23] Unknown:

Oh,   yeah.   I do.   So I've always been interested in programming languages. Like, my kids make fun of me. Like, I would just read programming books, you know, learn the basics of the language in in a week. And I came across Python   while working at a company that was syncing   separate instances   of subversion   repositories,   and they didn't wanna buy I forgot what the software was called. It it's like   a play on the word subversion, but it's very expensive, and they think this is before Git just blew all of that away. And I had a multiprocess   Python script synced the repos from the US to our offices in India, and I used a couple of libraries that were fascinating. There were cryptography   to have a secure pipe, you know, to communicate.  

And that's how I totally got in love with Python. Just on a side note, Python is just my type of language because   I'm sort of a hacker at heart. You know? I never had the patience for object oriented.   And Python kind of feels, like, powerful enough,   you know,   but accessible enough. It's like someone speaking, like, real talk instead of, like, professorial   talk. I mean, that's how I I think of it. So, yeah, that's I started and that was years ago. It was, like, I wanna say,   2010 was when I first got into it and never looked back. If I have my own choice   on   a scripting language or something that I need to get out real quick, it'll it'll usually be Python.  



[00:02:58] Unknown:

In terms of   what you're building at Quali, to your point of being able to get things out, I'm wondering if you can describe a bit about what it is that you're building there and some of the story behind how it came to be and why you decided that this was where you wanted to spend your time and energy?  

[00:03:11] Unknown:

So I've been with Quali for, you know, about a year and a half. Quali's mission is my leaders say they wanna democratize access to the infrastructure.   What does that really mean? You know, Quali's mission is basically to bring infrastructure   provisioning   and life cycle management to the masses, you know, much in the same way that GitHub brought Git usage to all. Git existed before,   you know, GitHub.   And we started our life, and our first product was a lab as a service,   and we quickly saw that provisioning out infrastructure wasn't just something needed by lab managers.   And back then, we were just it was bare metal and we were managing, you know, hypervisors   here. But   now, we've evolved we grew up from that to be forget about hypervisor, where we now accept   infrastructure   as code, like think Terraform and Helm or whatnot.  

We accept a Git repository   and auto discover all of those scripts   and present it to you in a catalog where you can then   run them and provision out whole systems.   And what's different here is, like, okay. So developers have been doing that with their IAC for a little bit. Now what's the big deal? The developers aren't thinking about the full life cycle, but, unfortunately,   we do need to think about that. We do need to think about tear down, patching,   and the evolving of how your infrastructure looks. And that becomes sort of chaos   to manage   with, like, little IAC code flying around everywhere between repositories. So we're trying to,   if you will, be the GitHub   for infrastructure life cycle management.  



[00:04:53] Unknown:

Definitely some interesting things to dig into there. And to your point of democratizing access to the infrastructure, on the 1 hand, it definitely sounds very useful and empowering.   And as somebody who works in infrastructure   and systems management, equally terrifying.  

[00:05:09] Unknown:

Yeah. Like, do we give the well and that's what Qualys torque that's what it is there for because it is super terrifying. Even in my own organization at Quali, you know, IT is very resistant as they should be to give what we call, like, the keys to the kingdom. You know, giving your employees, like, access to your cloud account, Azure, AWS, GCP, whatever, it can be crazy. I remember 1 time I got, you know, sort of an email and some Slack messages on the weekend. I left a a perf environment that was very expensive running, you know, as I was heading out the door, Friday. So these are the types of things you don't wanna just give the keys to the kingdom, if you will, to but at the same time, we're here talking about velocity   and which I think, in general, DevOps   I personally believe DevOps is sort of a corporate term for   but, you know, us DevOps engineers have owned it, but it's really our corporate goal to get software out faster, and we're trying to do that safely. We don't want people just, playing with knives. We want them to do it safely, much in the same way. And I hate going back to the GitHub example, but, you know, it would be insane managing your permission files and whatnot   in just regular Git repos.  

We all use GitHub or GitLab or something like that now, and that's what we're   trying to educate and show people   that there is a safe way   and a cool way, I think, to use your infrastructure script   and still get business outcomes that they care about. And there are 3   actors here. We're talking about developers, but   shared services, DevOps, they're the ones who are providing this platform to their internal teams. And then, of course, there's, like, the economic buyer who cares about   cost   and tracking,   compliance and whatnot. And we provide all of that for those 3 different   certain roles.  



[00:07:05] Unknown:

The   an interesting   aspect of managing infrastructure and particularly infrastructure as code is that it provides a lot of power. And   as somebody who's been working in the space for a while, there's always the initial step of, I just need to get something out there that works and then I need to make sure that I can do this repeatedly   and then it's, okay, I need to do this repeatedly and safely in a way that there are guardrails so that if I make a mistake or if somebody new is coming on and makes a mistake, they're not going to accidentally destroy production or, you know,   basically providing a way to keep that foot gun away from your feet.  



[00:07:40] Unknown:

Yeah. You should totally come work for Qualit Device. You nailed it. That's exactly what we're trying to do. And Torq is the only product that I've seen we started by you asking, like, why am I on this mission? You know, I go to the conferences and whatnot, and I talk to a lot of people about infrastructure.   And I'm, you know, big into automation, but we gotta do it safely.   And if you'll allow me to give a completely cheesy example, the work is actually challenging because   a lot of developers don't really care. You know? They don't care. They're like you mentioned they're just like, that iteration 1 is like, you know, I just want my infrastructure up so that I can deploy out to. And the way I think of this, I was thinking about it and practicing, trying to explain to my kids what I do, and I said, okay. Alright. Imagine,   kiddos, if I came over to, you know, some random family's house and I said, hey. You guys need to eat organic food.  

Alright? Organic food. The kids would be sort of like the developers. They want what they want. They don't care about the health benefits or whatever. They just want something tasty and to and to fill themselves up. Right? And then, you know, and definitely don't want to assign gender roles to these roles, but you have then the primary cook. You know? They're like the DevOps shared services. Right? They actually can be resistant to this. You know? Like, you're telling me I have to buy organic vegetables, but now I have to change my 1, I have to do work. I have to change what I'm doing. That's always a big deal. And then you're telling me, like, maybe I have to also change my whole recipe catalog.   Some vegetables, some fruits aren't available in organic selection, so that sucks. That's worked for me. And then you have the financial   head. You know, in a family, it could be the cooktop person, but let's just say that's a different role. The financial head here would be sort of like our economic buyer that cares about the cost of the organic food. Like, is it worth it? You know, is there really a benefit to that? And can I track   how my money is actually helping? And I'm also balancing a lot of things as the as the economic buyer. I don't wanna piss my   shared services cook off. You know? And I definitely don't wanna put morale in the house. That's just gonna make all the other initiatives that I have to do. I'm coming into,   like, companies, and I'm trying to tell them   something that I genuinely believe is good for them, but I have a tall mountain to climb with them. And so I got to show value as fast as possible   before they'll even be willing to to to humor it. And I think 1 of the coolest thing that Torq does is when you point it to a git repo that has your IAC assets, like, let's say you have it sprinkled out, like Terraform or Helm or whatever in it, it'll auto discover it. You know?  

So, you know, maybe now my developer slash kids in this example will be like, oh, I can get the foods I want. Self-service, no problem. So   that's the example I'm trying to, you know, communicate of the total uphill battles I'm facing trying to help. But that makes the job interesting and and why I'm here and why I'm with Quali.  

[00:10:40] Unknown:

To your point earlier about the kind of DevOps being the term that everybody has agreed upon to encapsulate this idea of we just need to be able to get things out in front of people.   And 1 of the key metrics that everybody wants to talk about, not necessarily measure or measure effectively, but this idea of velocity of how long does it take from me as a developer to get a feature request and then out into production in front of people to decide, okay, is this the feature that people actually want or do I need to do something differently?   Because if it's too long, then people forget about why they asked for it in the first place or Yeah. You you get it out into production and then it doesn't do what you want it to do and then you either have to figure out, okay, now I need to roll it back, or how do I get an improvement back out in front of people and is it going to take equally long and everybody's gonna be grumpy in the meantime?  

And   to that question of velocity,   I'm curious what you have   seen as some of the main points of friction that increase delay or increase latency in that path where it says, okay, I've got this idea, I've got this feature request,   I've written it, now I'm hitting roadblocks of actually getting it out the door. And just like, how do you see people addressing those points of friction   and some of the challenges that are introduced when you do hit stumbling blocks on the path to building and maintaining velocity?  

[00:12:00] Unknown:

Oh, boy.   I see this comment, and this is actually super good that you brought this up because it reminds me about the 1 thing that,   like, does resonate when I talk to developers about this.   And even in the shared services, you know, I don't wanna paint them all with 1 brush. You know? I worked many years in shared services   in DevOps, and I did care about the services that I'm   providing, but, you know, I could only care so much because I'm also managing a whole bunch of other platforms.   Here's 1 thing I'll say to   developers and DevOps practitioners.  

They're frustrated. They're trying to get, you know,   software out,   and you'll have some request. The traditional way is you request infrastructure from, you know, a shared services team, and then you get it. Right? When   ever in your life, it has never happened for me, that my   request for infrastructure was right the first time. It's just never happened in my entire life. And I'll tell you what, Duys, and I'm, you know, talking to also our crowd out here. I'd like to ask them. How many times has when you have been provisioned, supposedly, the ticket is completed and you've provisioned out your infrastructure, like, how often are you even able to connect it? I'd say 50% of the time, I can't even SSH into you know, or connect into my infrastructure.   So, you know, you asked about   stumbling blocks and, you know, frustrations. I would say that's my top frustration. That happens to me, like, I don't know, more than once, and I start thinking and really just   don't wanna be in this spot. You start thinking about workarounds.  

You start thinking about porting environments, you know, like over speccing and ordering it early. And then   you remember, we are here, and this is kind of an aside. We're here in the world of cloud   as an evolution. We used to have bare metal. Right? I remember running cables in a raised coal room.   We had our servers that were mostly idle. And so now we had hypervisors that provided the compute and storage in a way that I could now make my machines not be idle, and I'm getting more out of it. And then Cloud took that on steroids.   If I am   now making my development teams   and consumers of infrastructure   hoard and, you know, over spec and provision out too early by infrastructure  

[00:14:23] Unknown:

feels like a step backwards, you know, to me. Yeah. The question of, does everything come up right the first time is definitely a persistent problem and 1 that every time you have to try and work with a new platform or a new framework or new components, you always have to go through that process of, okay, how does this actually work, and what are the things that are not going to work the first time and how do I either work around them or build an additional automation or a bit additional logic to be able to account for that? And that's another question that often comes up is, how much time and energy is this actually worth? So I can't Oh, my goodness. Build this up and then it doesn't quite work, and then I can click 3 buttons and then it does, but I have to do that every time, or I can spend the next 2 and a half weeks writing code that makes it so I don't have to click those 3 buttons. How many times am I actually going to have to do this in figuring out what that calculus is?  

[00:15:16] Unknown:

Sorry. I was about to talk over you because it's so, emotionally   triggering what you're describing because, you know, you also asked what bad habits happen because of this, and so people start getting into workaround mode, and I'm not sure if this is a quali term. I imagine it's not, but I first heard it in quali while trying to solve this problem.   You have something called,   shadow IT. Sounds like something from a spy movie or something. But you have shadow IT and what that is, and, Tobias,   I've been guilty of this myself. Okay. This is so frustrating. I put my own credit card down, and I open up my own AWS account. Now that is nuts. That bypasses   every   security   and safety   mechanism of your corporation.  

I like to think I did it safely, but I'm being put in a   a rock and a hard place here. I'm on the hook to deliver. We're talking about Velocity,   super fast. And I've had developers,   you know, at shows come and just tell me, it's like, yeah. I just I really don't give a, you know, insert an expletive about,   you know, doing it the right way. I have a feature that I have to get out here, and that's what I'm being, if you will, graded on. That's what my bonus structure   is based on. And developers are hardworking, smart, creative people. Even if it weren't all of those pressures,   the want to do something fast in an elegant way is just kinda built into our DNA   in tech, and you don't wanna give them   a reason to to start in the workaround. And just sort of as a meta topic, Tobias, this is like how I   sort of I think I alluded it to it, but I'm a parent. I'm a father.  

And I see this as it's very much like a family too. I I don't wanna give my   kids a reason   to work around our rules, And the rules aren't there just for me to power trip, they're to keep them safe and happy, and us to complete our objectives. But at the same time, pretty sure my 15 year old son doesn't   doesn't care when I'm harping on him about how, like, maybe screens affect him. You know, he's just he wants what he wants. And, you know, let's not give   folks a reason to go the work around, because these people are super smart, and they will find that workaround, and then you will subvert your process. And also, to wrap up that story about the AWS account that I opened on my own,   Boy, did I get in so much trouble for that. I mean, it was just, you know but I was honest. I was like, I'm not so sure what I could've done. And it got escalated all the way to the top, and they acknowledged that it's like, don't do this again, but   we're not gonna fire you.  

Yep.  

[00:18:02] Unknown:

And to that point of   when you have points of friction or when you have roadblocks on the path to production, it's going to lead people to, you know, do things that   are not   supported or are not desirable for whatever the reasons, whether it's security, corporate policy, regulations,   etcetera.   And once you do hit that point where somebody says, okay, I just need to do this workaround because this has to get into production for whatever reason it might be,   how does the persistence of those roadblocks or of those points of friction contribute to some of those negative feedback loops? And   what are some of the ways that development teams can identify when people are falling into those bad habits and start to identify and work to address them?  



[00:18:45] Unknown:

Yeah. I love it. Alright. So you asked, you know, how do those habits contribute to a negative feedback loop? And we kinda alluded to it this way, but I'll sort of give my, like, canned response, and I I really hope it sort of resonates here. I think we can all agree, I believe, like,   I don't think anybody   loves process, you know, necessarily,   but process was put in place for a good reason. Right? Downstream effects of work around culture will subvert those processes   and risk   delivering on all those reasons the processes were put in place in the first place. And now we're going to go from a place where processes   help keep things in the rails and safe and predictable, but now we're gonna be managing by crisis. Kinda wanna go down that way. You want to address that, and I'm gonna totally say something that sounds trite, but I'll go into it. It'll be more expensive   in the long run if you don't manage this proactively   and really address the reasons   the developers feel the need to work around. Sometimes it's like, hey. Is the process overbearing?  

Maybe. Is it at direct odds with, developer objectives and responsibilities? I mean, you gotta, like, really look at that hard. And that's hard to do because, you know, in an organization, like I mentioned, you know, with shared services and develop, our objectives are different, and rightfully so. And I think,   you know, then you ask, like, hey. What are those signs and stuff? I think the signs need to be monitored by the leaders. I mentioned before, like, for instance, like, the people I deal with, I call them the economic buyers, but our tech leadership   should look out for these signs, and don't get us to   a crisis to try and fix this. We need to address it beforehand. I'll give an example. I have a friend that is a big diver,   you know, and I was complaining 1 time, you know, that my ears, like, needed to pop. And he told me, in diving, what you do is, by the time you need to your ears to pop, you know, and you're down, like, 90 meters in the water, It's like, he used more colorful language than I'm gonna use, but he said, you're already screwed by that time. You know, 2 tough tough noogies there. You're going to and just like in a plane, when your ears need to pop, it's too late that   he says the typical diver, what they'll do is they'll pump their internal sinuses the whole way down, and you'll never get to that. So why am I saying that example? It's because we have to pump the whole way down. The first sign of friction, the first sign of work around, and to my company's credit, in addition to not firing, they really did escalate. You know, I actually literally sat with the CIO and the IT leadership,   and just they really cared about that experience. And and we did solve that problem. I got the access I needed, not just the workaround because Ronak was the trouble kid, you know, we changed that process for everyone. And so that's the canary in the coal mine, when somebody's, like, working on but it's a little kinda late for that. So hopefully, the leaders are saying, like, how long does it take you to finish a ticket? And if the ticket to deliver,   you know, infrastructure is, like, 2 weeks,   but your sprints are 2 weeks,   that's probably a pretty sure sign that   you're going to have friction. You know? And then I'm hoping every tech leader   will just like when we were talking, it easily resonated. That no ticket is totally satisfactory the first time around.  

So I think they should also look at reopen tickets, you know, as an indicator. These are boring metrics, but, I mean, that's why I'm not a leader. I think a lot of that is boring too. But that's their job. Right? They're the they're the head of the family, and and they should be proactively,   you know, pumping the system   and watching out for that. To the point too of,  

[00:22:30] Unknown:

you know, the developer gets the feature written and then it needs to get into production, another problem that I've encountered and seen in a few places is   understanding what is the definition of done because a lot of people say, Oh, I wrote the feature. That means I'm done. I'll move on to the next thing. And, No, it's not in production yet. It's not done yet. So what are some of the useful ways that you've seen to   either come to a   useful definition of done or working with the numbers to   kind of give a sense of ownership to that and, you know, owning the feature all the way into production and just   be Alright. For the contribute to some of those negative feedback cycles.  



[00:23:09] Unknown:

For those listening, I beg your patience and apology, but I'm gonna say the thing that's, like, totally popular, that's totally worked   in in my life. It's like, alright. So we have full stack developers. Right? Full stack developers is it's like the new black dress, you know, everybody's a full stack developer. If you release a feature,   I think until   documentation   and   forget it. Oh, documentation. I think, like, you know, as you release a feature, the full stack developer is is on the call chain.   If your feature breaks, you know, you have to suffer it with and I'm not just trying to be, like, a tongue in cheek jerk. There's, like, very little way to gain that empathy.   We're creating a systems of motivation that creates these sort of problems. Right? The velocity has to be faster. The releases have to, be faster, but then that'll create a bad habit of just, like, throwing the spaghetti against the wall and saying, what sticks? If we're gonna be full stack developers, we also have to own all the way through the life cycle, all the way out to post production and support.  



[00:24:08] Unknown:

And so in terms of the work that you're doing at Quali, you mentioned the Torq product a few times and we've identified a few of the   challenges and points of friction that developers will experience, whether it's problems with how their feature goes from point A to point B or maybe lack of understanding about what is involved in those steps. And I'm just wondering   how you are addressing that challenge of being able to   build velocity, maintain velocity, and   let everybody share visibility and ownership throughout the entire process?  

[00:24:42] Unknown:

So   the problem that we're trying to solve for for the software teams is, you know, we're just trying to release software faster. Right? And like we mentioned before, I think that's the point of DevOps. I mean,   there's some argument, and and I don't fully believe that's true. I think DevOps practitioners, we now have also owned that term, and it's like a community too, but I really think the folks who are employed because   and the DevOps practice   exists is to get   software out faster. Right? That's the point. Then   these tools and just like with Torq, the point is   all the tools in a DevOps pipeline,   Qualys' torque is no different. It's to release   our software faster. And I'm trying to get folks aware. The challenge is now the infrastructure. We figured out how to do CI. We know how to build code, like, without any delay. We have continuous deployment. We're pretty mature on that process. We're starting to do continuous testing   as well. But all of that is predicated on that infrastructure   exists.  

That's sort of the rickety leg on this chair,   you know? Think Think about it. It's like tuning a car. We've been tuning the car for a while, but we're like, okay. We we cleaned out the, you know, replaced the spark plugs and the spark plug wires, and it's like, oh, that works well. Like, what's now the next thing in the engine that needs tuning? It's like, oh, okay. I'm I'm gonna change the exhaust out or whatever. And I think at this part, in time of our   DevOps   CICD pipeline process, I think infrastructure is that next big challenge. And I would love to solve this, and I would love us to solve this.   Of course, I think Torq is the answer to that, but I would love us to just, as a practitioner in DevOps, love to solve this so that we can find what that next thing is in the line that we need to automate and fix. You know? Ideally, I think our businesses would love to get to a day when we're thinking of a feature, like a developer's thinking of a feature, and it goes from thought to production,   like, as fast as possible, you know?  



[00:26:46] Unknown:

Yeah. So 1 of the interesting   elements of the interaction between developers and the infrastructure engineers   is helping the developers understand what infrastructure is even necessary for their feature to be able to actually run once it's in production.   Because if you're doing something locally, there are certain workarounds or certain shortcuts you can make or assumptions that you can make about what do I need to actually get this functional,   1 of the most common ones being file system access, where particularly if you're in a cloud environment,   you're gonna be running across multiple machines, so you can't assume that any given file is going to be able to be written and then read from in the same process or on the same machine. And so then you have to say, okay, well, actually, now I need to push this into object storage or now I need to assume that there's some shared file system, whether it's NFS or whatever it might be. So just making sure that developers   understand as they're working on features, okay, this is actually going to need some additional cloud resource or infrastructure resource or I'm going to have to start this conversation early with the infrastructure engineers to say, this is what I'm going to need in this future to work. How long will that take? Or what else do I need to do? Or what are the solutions that we already have in place to be able to solve this kind of a problem?  

And I'm wondering how you've seen teams start to tackle that challenge of the sort of education and awareness among developers about what infrastructure resources are already in place or what additional resources might need to be created to support what they're working on. What a great, you know, comment and, you know, defining of a problem to your question. So when I talk about this with  

[00:28:19] Unknown:

users   and, you   know, developers and DevOps practitioners,   you know, we call this in quality, it's called the skills gap. You know, we have a cloud engineer. Okay? And the amount of people that are gonna use infrastructure,   if you think about it in a funnel, like all the developers, it's a great amount of people. Right? And then there's the folks with expertise on knowing how to build things out in the cloud. Alright? That's less people. Then you have, like, the people that are   knowledgeable enough in development   and have those cloud skills and have the interest   to do it, and those are a few people. You can't hire, like, an army of cloud engineers. That doesn't scale well.  

And so   1 thing that we had decided to do with Torq is, you know, we talked about how long it takes those tickets to complete in DevOps, and you hit the nail on the head. 1 of those is the discussion.   Like, what is possible? You know? You mentioned, like, file storage,   and, you know, another 1 is, what's the proper security group? What are those called? Like, the CDNs and what pieces? That looks totally different from your local environment, even if you're Docker and containerizing it. It looks totally different. So in your organization, there's, like, a small percentage   of people   that can do that, and delays come from these are complex topics that they have to go through and talk about with teams, and that contributes to the delay of getting their infrastructure out. 1 of the things that Torq does is, alright. So you have Cloud Architect building these   environments.  

What if they were able to do the thing 1 time   and codify   it into a we call them blueprints personally, or but you can codify it in a terraform or whatever.   But you have to be knowledgeable. Not not 1 person now can codify it, put it in Tor, and now it's in a self-service catalog   for everyone.   So you've basically now scaled your cloud architect.   And I think that's I didn't mention it before, but, Tobias, you opened the door totally. I think, definitely, our cloud architects, and they're called, you know, many things in different companies, but just generally speaking, our cloud architects,   very necessary position, only folks knowledgeable on not   just, you know, the product, but how to get that out there safely. And a lot of delays if they have to do that for the whole company and they have to do that over and over again   again. We should codify and   take their   learnings and say, okay. Well, we discussed it. Here it is. Here's the blueprint you used, and from now on, you can extend it. So parts that you don't know about, fine. You know, we can talk about that and whatnot, but the parts that you do need to know, you could just click a button and then, boom, your infrastructure is there. To the question of blueprints, that brings up a pain point that I've experienced a number of times where you have all of these, you know, pre existing  

[00:31:09] Unknown:

repositories, so Terraform modules or Pulumi libraries or CloudFormation stacks where   it says, oh, this is the thing you need. Here, just click this button. It'll do everything you want. And it's like, okay, that's great. That's 80% of what I need, but these pieces are actually a little bit different in my environment, so I need to do this differently. Yes. And I'm curious how you've addressed some of that problem of   Here's the general pattern.   This will do everything you want, but then making it so, Okay. These are the pieces that you need to swap out. We'll let you do that differently without having to just throw away the whole thing or Yeah. Fork the repository and rewrite half of it to make it fit your environment and just some of those challenges of, you know, making a solution fit the environment that you need to deploy it into?  

[00:31:49] Unknown:

Yeah. Good question. And, yes, that is a you know, the cloud architect's not gonna be able to write a blueprint that'll work a 100%   for everyone. And and part of what I'm proud of in Torq is that, alright, we have now taken these complicated   items   and codified it in, like, human readable ways, you know. And   if I need to   alter it, and we also alluded to it this way, all of those catalog   blueprints, and all the infrastructure   code scripts that,   you know, Torque is managing   is discovered and made presented to you via a Git repo.   You know? Not just a single 1. We have a concept of spaces. So, like, a space would be, like, for a development team. Right? So Ronak's space would be for the Ronak app, and I have developed a set of blueprints, and I backed it up with our Git repository.  

From there, I can sort   of update I can work with the cloud architect   and update it to a 100%,   and it'll be much faster because I might not be an expert,   for instance, in security group creation.   But I do see it in English. Oh, here it is, and here's my problem. I can't connect.   My service is up the way I need to. And we'll just alter it from there. Your space now gets that learning, and you can move forward to a 100% of your solution that doesn't affect somebody in someone else's space.  

[00:33:15] Unknown:

Another interesting   element of the challenge is that while there might be a general   pattern or   kind of abstract architectural set of requirements of, I need a web server, a database,   and   a CDN,   but there might be differences in terms of which implementations there are or what APIs they each support or what feature set they have. But then even beyond that, there's the question of, okay. Well, what is my actual deployment environment? Because that'll introduce different constraints. You mentioned containers, so, you know, that's obviously a hot topic right now. So I've been running this on a VM where I can actually have multiple processes and multiple different, you know, applications   cooperating.  

Am I going to put this into a container where I can actually only have PID 1 and it that's the expectation is that there's 1 process running. Am I gonna run this in a Kubernetes container where I have to be able to handle   fault tolerance and restarts and distribution of my application? You know, is this going to be, you know, globally replicated? You know, what's the replication factor?   I'm curious how you've seen the   proliferation and evolution of available   deployment targets influence the   challenges and points of friction that development teams run into in figuring out what is that path from development to production and,   you know, how flexible or, you know, what are the supported deploy targets that I want to manage in my environment and how do I make that selection?  



[00:34:36] Unknown:

Folks should be able to deploy wherever they want to. I shouldn't come in with a product   of Torq and say, well, I only support, you know, AWS and this where, you know, then why not just use, like, CloudFormation. Right? 1 of the the cool things, and I haven't mentioned it, you know, yet, but we're not only multi cloud, you know, we support multi cloud like Azure, AWS, you know, GCP,   Oracle's offering.   But we also support   not just, you know, containers,   you know, Kubernetes clusters in those separate   clouds. But also, we support the target of a Kubernetes cluster, like, just locally, like, outside of all that. So I think 1 of the big advantages here   is I don't wanna tell them. You know? I want them to be able to use what they want to use. I want them to use it easily, and I want it human readable.  

That's all. And and so Torq supports that. I think, for instance, nothing's wrong with, you know, for example, CloudFormation.   I think it's cool. You know? But I just don't think it's enough with the needs of all of my software development teams. I think you can't convince everybody,   nor should you, you know, maybe   I work best in   containers, and I've nailed this deployment process on, you know, a Kubernetes cluster, you   know, using my Helm and Terraform scripts. I want to say yes to that. But then maybe a bunch of people only want to create, you know, a traditional compute   resources in Azure. I wanna support that too, and we do. So I guess my answer is, you gotta support all the deployment methods.  



[00:36:12] Unknown:

In terms of what you're building, I'm wondering if you can talk through some of the implementation   of how you've approached the product and the user experience around how it operates and how people work with it, and just some of the ways that the design and goals of the platform have shifted or evolved from when you first started working with it? Alright. Are you ready for some boilerplate,  

[00:36:33] Unknown:

Tobias? Yes. No. I'm gonna try it. I'm gonna try and make it interesting.   Yes. I would love to describe what we have built with Qualia and how our designs have, you know, evolved, if you will. But then I'd have to kill you. No, I'm just kidding. I'm just kidding. Okay. So as we talked about, we created a product called Torq, which is, you know, a control plane for managing your infrastructure life cycle.   The inputs,   as mentioned before, are IAC, infrastructure as code. So for folks listening, think Terraform, think Helm. But there are others, you know, including our own YAML based blueprints. And I mentioned this before, but I just wanna underline it. We accept   a Git repo with all that IAC   in it, and in no special format. We're not telling you how to do it because we auto discover these assets. As soon as you point to a repo,   you know, it does its, hey, I'm thinking for a second, and it auto discovers all of your assets and then presents it to you. And it gives you a choice on which ones you wanna import. I just import them all, usually.  

Then our outputs   are basically going to be, you know, once you select that,   now you have all of your infrastructure presented to you in a list, sort of like an application catalog, like that's, like, 1 of the things IT does. They put all your applications in your catalog consult service. Well, we're doing that with infrastructure,   and the outputs are infrastructure created   and the ability to manage them. And so here's the big part that I haven't talked about yet. The outputs   are not just created. Those are, like, day 1 problems. Sometime   day 2 and day n problems. So our outputs are the infrastructure created and the ability to manage them from creation,   maintenance and patching,   cost tracking,   auditing for compliances,   and all the way to end of life and decommission.  

We implemented   our SaaS   solution by accepting Git repos, identify the IAC assets, present it to you as a catalog   that you may self serve from.   The things that now you get free   with it, that maybe as a developer you don't care about are cost tracking, ability to audit, self serve from those with like I said, we break it down into   spaces, and we implement a role based access control.   So only people you want will see   the catalog. You know? Not everybody will be able to go to the Ronak space and launch anything. We fine grain control those permissions,   much in the same way that GitHub   controls fine grain access to, you know, repos.  

And finally, and I think this is pretty cool, a part of that life cycle is to be able to observe and connect to the created infrastructure and diagnose and troubleshoot as well. You also asked, have our design goals shifted and evolved from when we started working on? And that's pretty cool question because that sort of gives an idea of our headspace.   And I think we saw a problem,   and we solved for that problem. And that first problem that we solved for was sort of lab as a service, I mentioned, and that was bare metal, and we were helping folks   provision out infrastructure   for that bare metal. But with all successful PLG, you know, product led growth offerings and SaaS offerings,   you have to   listen to your users,   refine, rinse, and repeat. So the original problem we solved for was managing   automated infrastructure   in SoftwareLabs, But now we took that concept   and made it for any environments, any cloud, and any deployment target,   targeting VMs, multi cloud, Kubernetes.  

And we still do physical labs with virtual hypervisors too. So that was our evolution.  

[00:40:09] Unknown:

To the point of kind of lab environments or preproduction test environments being able to give developers a space to actually prove out their features and prove out their general approach,   that can be very challenging to be able to actually   get the automation in a place where you can spin up an entire stack, particularly when you have particular   data that needs to be in place for the function to work the way that it was designed. And I'm wondering what are some of the useful patterns that you've seen folks build up once they start to adopt quality and have the ability to say, okay, here's our infrastructure as code. This is what runs runs in production.   Now you can self serve and spin up this environment for being able to deploy your test feature to,   but how do you actually write that infrastructure as code or the out automation to be able to get that environment to a point where you can test it without having to do a bunch of manual work after the fact, harking back to earlier in our conversation?  



[00:41:00] Unknown:

Well, I think the first step, you know, I wish we could and I'm sure we'll evolve to even do more, but that subject is a very interesting 1. You know, what we're doing is we're trying to speed up velocity by as mentioned, we automate the release of the infrastructure stack. Great. I think the key method   and I saw this when I was started working with Torq myself. 1 of the things that helped me   evolve and get my production system,   and I'll describe that production system that I started with here in a second.   1 of the things that helped me most that Torq did was the ability to spin it up and tear it down, and I had the observability   and the, you know, connectability   to my environments to iterate fast through this. So I was the 1 who was the expert in, like,   creating   the infrastructure, but I didn't have to go through all the rigmarole of running, you know, this I had 1 place   that showed me my code that was imported in from my Git repo, and I could run it and observe it, and then it's like, oh, that's not good enough. I just update my git repo, and I just rinse and repeat again. So your typical development methodology, now we're doing it for infrastructure.  

We give that sort of rinse and repeat and iterate   over it   with something that's backed by source control. And the kind of cool or funny example that I did, I was trying to get   sort of my son interested, and he asked me, what do I do? And I started talking to him, you know, like, we're talking.   And he's like, yeah, dad. I just don't   understand any of those words that are coming out of your mouth. They just sound like a bunch of, you know, tech garbage talk. And I was like, okay. Fine. We're gonna create a Minecraft server,   okay, together.  

And it was a simple YAML. We just created the compute and, you know, crawled, downloaded the server binaries and, you know, launched you know, with   we reinstalled Java and launched Minecraft. And I forgot to mention this when you asked how I got into Python. 1 of my favorite libraries in Python,   I'm sure you're familiar with it way more than I, is, Flask.   Have you I love Flask. Flask is, like, my I mean, if it were a person, it would be my best friend. So I could spin up, like, cool actual websites. So I was able to I mean, I don't know. It's like half a   page of Python script. I also   created   a helper website   that on a different compute that took my   Minecraft state, it's just a copy of the file, copied   it, zipped it, and allowed me   to import it back in. So then when my son and I were done playing, I was like, look, I'm gonna shut this down. And I killed it, and the compute was reserved and dead. I said, Now we can go out, and next weekend we can come back, and we can start just where we left it. And he's like, Okay, why do I care about that? I can do that no matter what. I was like, Yeah, but now I'm not paying for the compute   for the whole week. You know, he's like,   Oh, I get it now. So,   I was able to iterate through that real quick, and I held the interest of a then 14, 14, you know, now 15 year old. So I think, personally,   pretty amazing   that I was able to hold their interest. So to answer your question, I think it's this speed of iteration   has increased so fast that allows me to keep making changes and learn and improve it. Oh, you know what? We actually do. I don't use this, but we have IDE   plugins,   of course, yeah, for Microsoft Visual Studio.  

And when you're creating your infrastructure, we have, what is it, syntax,   you know, syntax completion and   syntax checking. I'm old school, I copy and paste and change it, but, yeah, we actually do it. So that's another way we help folks create their and I think that's a big lift. I just I don't like Visual Studio, so I don't use it. Uh-huh. So but, yeah, we have that plug in too to help folks create their IAC faster in Tor. When are you gonna make the plug in for Emax?   Oh, man. I'm telling you. Hell yes.   Emax and and VI, I've just totally that's my love language.  

Yeah. Some nano, some pico, some vi. Love that. I really do. I love those. And that's why I like Python. I mentioned it. My hat's off   to developers that   can think abstractly with their object oriented, you know, development,   you know, large complicated projects. But I love Python. I can understand it. And yeah. So I'll suggest it, but I wouldn't hold my breath on the EMAX plug in,   but a good 1.  

[00:45:34] Unknown:

I think that that's 1 of the great things about the introduction of the language server protocol is that it reduces the   amount of friction and time and investment required to be able to support editors like Emax that aren't the kind   of the big names that everybody's talking about right now. Right now, everything is, oh, here's a Versus code plugin for you. It's like, okay, great. That's fine for some people, but not me.  

[00:45:56] Unknown:

Yeah. But you could see why we went that direction. Right? That's what our users are. It's not for me personally, but it is for a lot of people. It's so not for me, I forgot to, but there's a ton of folks that that like it and have provided feedback. And we've actually gone through a few iterations, and I've seen it recently. And it's I mean,   I'll make an admission. I have installed Versus Code on my system. It's my job and and to do it. And   I'm not gonna lie. It wasn't terrible.  

[00:46:23] Unknown:

Yeah. I hear you. There have been a few features that have been compelling enough to make a stab at trying to adopt Versus Code or some of these other editors that it's like, okay. Maybe this will be worth it. And then I spend a couple of days with it and I just can't get anything done. It's I spend more time fighting against it than doing anything else, so then I just retreat back to e max, which is where I've been for the past few years. So  

[00:46:45] Unknown:

Tobias, you and me both had to struggle with I'm gonna I'm gonna mention it, and it might cause pain for folks listening in, but Eclipse can be the bane of my existence sometimes. I mean, the load time on it is incredible. I think as you can tell, I'm I'm not a huge IDE guy, but my favorite 1 so far has been IntelliJ's.   I mean, that's still not my first choice for editing, but it's the least frustrating for me. Yeah. Absolutely.  

[00:47:13] Unknown:

And so   for teams that they've built their path to production, they have established velocity, they're working to be able to build and ship features and,   you know, manage those feedback cycles. What are some of the potential disruptions that they should be guarding against or keeping an eye out for that can,   you know, throw a wrench in the works and actually start to introduce some of these negative feedback cycles where maybe you have a path to production but it's become too rigid because you have built too many assumptions in along the way and just some of those types of issues that folks need to be aware of as they're building velocity and iterating on, you know, the path to production and making sure that developers can get things in front of users.  

[00:47:54] Unknown:

The top thing that I've seen is,   environments like lower environments, for example,   or actually can happen the other way too, but,   environments getting stale, as in not matching prod. Right? Perhaps hotfixes were applied. I don't know. Environment stacks require   upgrades to depend on software, OS, compute, storage, you name it. That's 1. So so environment's,   getting stale. And because before,   we haven't   codified it, or if we did, like, Terraform scripts on some random person's repo, it's like, alright.   Am I disciplined enough to take what changed in production and   if   by a Git repo. And if it's not how you like it, the cost is pretty low, and you can get into the habit of updating it and then tear down the environment and build it right back on. So that's, you know, how we address that. But environment's going stale. I see that all the time. Another thing is, and, Tobias, you mentioned this, architecture changes.  

Example, for instance, moving from Postgres to a NoSQL attack. So, you know, like I said, this is the reason we created Torq. A full stack developer usually won't be looking out for the life cycle of the infrastructure. It's just I want that deployment environment.   And if we don't have a process set in place for all the phases of the infrastructure   life cycle, for example, like tear down or like forward patching, we will have these disruptions   and unexpected costs and   worse thing, defects that escape out to production. So what I'm hoping people are getting from this, you know, of course, I like Torq, and I would like people to give that a try. But the problem that Torq is solving and the methodology that we're pushing is   you have to codify this whole life cycle and manage this whole life cycle. And we   are motivating,   you know, our tech first class citizens, which, you know, are developers,   to   move super fast with velocity.  

But I have yet to see really good processes for updating your infrastructure, and I believe that Torq gives an opportunity. It gives them a framework through which they can iterate on their infrastructure and avoid these disruptions. But like anything, like any change, like when people first went to CICD,   a culture shift has to also happen too. And they have to believe and understand   that, oh, okay.   Things broke down, and I have a second to think about it. And the reason it broke down is because I really   did just forget part of what my infrastructure needed, how it needed changed. And   we're a tech, and I'm hoping developers would agree the right way to do this is is iterate through   code, just like they do with their software.  



[00:50:42] Unknown:

In your experience of working with the Torq product and helping developers  

[00:50:47] Unknown:

building and maintaining velocity by simplifying their interaction with infrastructure. What are some of the most interesting or innovative or unexpected ways that you've seen the product used? You know, I gave that earlier example. I was just messing around, but, you know, I used it to codify my Minecraft server, you know, for my but that's not a work use. I'd say, you know, well, let's start first with the most interesting challenge that I've learned while working with teams and, you know, folks that are considering Torq. And we talked about it. It's creating awareness of what that problem is. Like, I kinda you know, with this speed of velocity,   I'm kind of left in a point as a developer where I don't really care about this full life cycle, but we're trying to create awareness that this is something you should care about, and this will affect your velocity.  

So the 1 big challenge is creating   awareness   of an infrastructure life cycle. It's not just day 1 problems.   As the folks in Terraform say, we're talking about day 2   and day n problems of your infrastructure. It's trying to get us. That's my biggest challenge   with talking to folks is to get people to consider   that   I work,   you know, in parallel with Qualys product and r and d teams. And while we're building out this infrastructure   control plan, creating that awareness of the bottlenecks that your infrastructure life cycle management,   or lack thereof, will cause. So that's an uphill battle. It's made further challenging   by folks that this could help, don't have the same goals regarding infrastructure.  

Developers may want an easy way to provision out infra, they might just think, why not Terraform scripts? DevOps and shared services is trying to keep service levels up to provision infrastructure, and not be the bottleneck   to the software pipeline.   And leadership wants   the software to be really fast, I don't care how it's done, While being safe, you know, compliance and corporate standards, and minimizing cost. Yeah. They want it all. Right? That is the most interesting and unexpected challenge, and it caused me to come up with that cheesy example of trying to convince a family to, like, say, switch to organic.   So it's like I have to convince   disparate group of people with   disparate   goals   on a greater good   that will help them solution,   but they're drowning right now. The tech I've used is, gotta show value quick. It's like, hey, this is cool and it doesn't cost you a lot of time when you provision software. And so once they see the value, then, like, start bringing them along the way of, hey, this is for the greater good of the company. We haven't even talked about it, but Torq is able to because we connect to multi cloud, we know the cost structure   of their infrastructure,   so we have a cost tab. And, you know, I think it's pretty cool that your application, we can say we can slice it up any way you want, month by month or whatever, and say, this is how much your application   has spent in infrastructure. And I think that's interesting. So,   yeah, challenges at this stage   of our product is awareness of the problem.  



[00:53:46] Unknown:

In your own experience   of working in this space and working at Quali, what are some of the most interesting or unexpected or challenging lessons that you've learned? Let's  

[00:53:55] Unknown:

see.   1, not everybody thinks the geek cool thing that I'm pushing is cool. What I'm talking to you about comes after a year and a half of talking to people, and it's like,   oh, right.   You don't care about this because   this is not what you're motivated   by. You're just trying to bang out a feature real quick, or shared services like, ah, right. How could you care about this platform   when you're managing   your Atlassian stack, for example?   You know? And   I've learned,   or   I think I have a tendency for this too, but I've learned, like, just again and again, you gotta empathize   with people and really understand. I think I have a cool solution, but I think any successful PLG and SaaS company has to listen to their users. It can be I could think it's as cool as I want, but I don't matter, really. It's like I have to solve   the problems for the people I'm trying to help. That's a huge learning, and it's actually affected other parts of my life. It's informed now. I think I'm a better listener with just my family and friends. It's, like, not my agenda. It's not about me. It's about them, and it's taken me. I'm not gonna say how old I am, but many decades to get to this, point. And that's another reason I love it. If we're gonna talk meta topic, you know, because I've worked as an IT engineer, and that was before it was called DevOps, before DevOps. And so then I was DevOps. I did   SCM engineer,   and I now this is a unique role   of developer relations. It's sort of this   really   understanding   who I'm trying to help, And I think it's been a real cool thing at this is why I love it to increase my empathy just on a meta level. And I hate the sound just I know it's gonna it get emotional here, but I really think it's been  

[00:55:44] Unknown:

good for me in that way, and good for the folks in my life. For folks who are interested in being able to reduce some of these points of friction that we discussed, what are the case where quali is the wrong choice?  

[00:55:56] Unknown:

That's a good question. I was trying to think about this.   And, I mean, you know, I think of it like sort of like, hey. When is, like, in a company, when is, like, having your own email server, for example, like, the wrong choice? You know? There are going to be, like, certain, like, startup, like, 2 people in a garage type of situations where   this might be, you know, too much. But then I was thinking,   but is it? We have a free trial. You know? I think the only reason it would be, you know, too much or overkill is if you're 2 people in a garage developing software, you've probably got more work than you do time. And so you probably don't want 1 more abstraction layer. To them, I would say, you know, yes, I agree. That maybe bringing in quali you know, bringing in Confluence and Atlassian and everything there would be a bad choice. But you're gonna wanna scale 1 day. We have a risk free way of trying it out. There's a free tier. You know, a small team can use Qualify forever,   and Qualys Torque forever, and try it out, and we'll grow with you. You know? That would be whatever be a wrong choice. I would say be a choice you should consider in the horizon.  



[00:57:03] Unknown:

As you continue to build and iterate on the quality product, what are some of the things you have planned for the near to medium term, or any particular projects or problem areas that excited to explore?  

[00:57:13] Unknown:

Well, our North Star has always been, as I've said before and my leaders like to say, it's to democratize   infrastructure creation, access, life cycle management to all who need it. Remember we came from lab as a service, right, loss, and now we're multi cloud. Think of, you know, this should not be left   like, infrastructure   provisioning and design should not be left to the domain of the few overworked cloud architects,   overworked and overloaded DevOps team. It should be self-service and easy, because   it's all just in service to do their real work, which is to release awesome software in a way that makes 1 feel fulfilled and not burned out. So future would be lots of cool things. I talked about the auto discovery feature   of Torq where we can just point a repo and we look at all your IAC   assets. It's to support   more IAC   types, more cloud   backing, and whatever   tech that comes out for deployment technology. And that's always been we have a backlog and we're trying to support all of it. We don't wanna tell you how to do it. We wanna just be that sort of 1 place that   you can use to   make some sanity of this of your infrastructure life cycle. That's the future, supporting   more cloud,   more infrastructure as code technologies,   and, you know, all the things.  



[00:58:36] Unknown:

Are there any other aspects of the work that you're doing at Quali or this overall question of building and maintaining velocity and development teams that we didn't discuss yet that you'd like to cover before we close out the show?  

[00:58:46] Unknown:

Thank you for asking, Bryce. This has been a wonderful conversation. I would just say, you know, don't take my word for it. I'm just some guy that thinks what I do is cool and wants to share it with everyone. But you have to assess that for yourself.   And, you know, I love   this world that we're in and the whole idea of PLG   and SaaS offerings because it's so low risk to try something. Try it out, and, you know, go to our, quality towards the website,   sign up for the free tier. You know, if you run into any problems, you can always get help from us directly   within the product   as well. And my only wish  

[00:59:22] Unknown:

is for folks to try it out. Alright. Well, for anybody who wants to get in touch with you and follow along with the work that you're doing, I'll have you add your preferred contact information to the show notes. And so with that, we'll move us into the picks. This week, I'm going to choose a miniseries that I watched recently on Amazon called The Terminal List with Chris Pratt. It's definitely a very different role to see him in after watching him in Guardians of the Galaxy, but very well done show. Definitely recommend that. So, with that, I'll pass it to you, Ronak. Do you have any picks this week? I'm a bit of a old school, and I  

[00:59:54] Unknown:

really enjoyed out I think it was called Midnight.   It's an animated series on Netflix. Midnight gospel.   Okay?   And it's not for everyone. Okay? It's an animated   feature, and it really talks about and, you know, I talked about empathy and stuff. It's a miniseries, and it's animated, and it talks about,   you know, sort of   expanding your mind's consciousness,   dealing with death, and I found it very   thought provoking,   and sometimes very touching   to watch, and actually sometimes pretty gross. So Midnight Gospel,   maybe it'll do something for you the way it did for me.  



[01:00:32] Unknown:

Alright. Well, thank you very much for taking the time today to join me and share your thoughts and insights on the question of developer velocity and the challenges that infrastructure   introduces into that flow and how you're addressing that at Qualley. It's definitely a very interesting area to explore and glad that you and your team are working to simplify some of the aspects of that. So I appreciate that, and, hope you enjoy the rest of your day. My pleasure, Tobias, and thank you for putting on such an interesting podcast. I've listened to a few episodes, and I really like what you're doing. So thank you very much.   Thank you for listening. Don't forget to check out our other shows, the Data Engineering Podcast, which covers the latest on modern data management, and the Machine Learning Podcast, which helps you go from idea to production with machine learning. Visit the site at pythonpodcast.com   to subscribe to the show, sign up for the mailing list, and read the show notes. And if you learned something or tried out a project from the show, then tell us about it. Email hosts@pythonpodcast.com with your story.  

And to help other people find the show, please leave a review on Apple Podcasts and tell your friends and coworkers.