About Regis Wilson
Regis Wilson is the founding engineer at Release, an environments as a service provider. Regis brings more than 25 years of tech experience to this position, having worked as an infrastructure architect and SRE at TrueCar, Inc. and a cloud systems architect at Live Nation, among several other positions.


Links Referenced: 

Announcer: Hello, and welcome to Screaming in the Cloud with your host, Cloud Economist Corey Quinn. This weekly show features conversations with people doing interesting work in the world of Cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.

This episode is sponsored by our friends at New Relic. If you’re like most environments, you probably have an incredibly complicated architecture, which means that monitoring it is going to take a dozen different tools. And then we get into the advanced stuff. We all have been there and know that pain, or will learn it shortly, and New Relic wants to change that. They’ve designed everything you need in one platform with pricing that’s simple and straightforward, and that means no more counting hosts. You also can get one user and a hundred gigabytes a month, totally free. To learn more, visit newrelic.com. Observability made simple.

Corey: This episode is sponsored in part by LaunchDarkly. Take a look at what it takes to get your code into production. I’m going to just guess that it’s awful because it’s always awful. No one loves their deployment process. What if wanting new features didn’t require you to do a full-on code and possibly infrastructure deploy? What if you could test on a small subset of users and then roll it back immediately if results aren’t what you expect? LaunchDarkly does exactly this. To learn more, visit launchdarkly.com and tell them Corey sent you, and watch for the wince.

Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. A recurring theme throughout a number of these episodes over the years has been me complaining about various jackwagon bosses that I've had over the course of my career. Today, as a guest I have one of those jackwagon bosses here to suffer my slings and arrows directly. Regis Wilson, welcome to the show.

Regis: Hey, Corey, how's it going? Glad to talk to you.

Corey: It has been an interesting year. I don't think anyone planned it to go quite this way. But yeah, we've worked together repeatedly over the course of well, many years, just because first, for a long time I lived in Los Angeles where you are and LA tech is not as large as San Francisco tech, where at least here I have the ability to not want to work with people, and I never see them again once we change companies. You keep running into the same faces, the same names in the LA market. And honestly, I kind of miss aspects of that.

Regis: Yeah. I remember the first time that I interviewed you. You asked me a question, like a interview question, and I answered it. And then you were like, “Oh, okay.” It was like, “Why was someone that I was interviewing asking me an interview question.” It's pretty funny.

Corey: Yeah, I always have maintained that people who are going down the path of interviewing for a role forget that it's a two way street at their own peril. And that was sort of weird back then when I didn't have much of a history at all, or track record, of being able to deliver on the technical, but I had a certain way of asking weird questions. Now I just do it on podcasts, and I get my kicks that way. But it was a lot of fun working with you. Again, I joke at the intro here, but you were a great person to work with. 

It was fun; I never felt like you were asking me to do something that you wouldn’t have done yourself. None of it was unreasonable. And it was just a awful lot of fun. But for me, the real validation was a couple years later, after the last time we worked together, I happened to wander into a different company, and the next interviewer was you. And you, “Oh, Corey. Great to see you.” And you turned to the previous interviewer and said, “Yeah, I don't need to speak to him. He's great. Hire him.”

Regis: [laugh]. Yeah.

Corey: And it was awesome. That was the first time getting some aspect of my own reputation. And I could have assumed that oh, as soon as I leave, you said, “Just kidding. For God's sake, no.” But they extended an offer. So, if you did do the whole, “For God's sake, no.” You were nowhere near persuasive enough.

Regis: Yeah. No, I take that seriously. When I meet people that I like to work with, that I enjoy working with, or working for, or you're working for me, I always want to be able to work with you again. Or not you, but the person that I'm talking to? So, yeah, that was great. It’s a great history. And I think it goes back to, like, 2008, or—well no, 2006. [00:04:43 crosstalk]—

Corey: It’s somewhere in that range, yeah. 

Regis: It sounds recent, but it's 14 years ago now.

Corey: Time is speeding up and we're all getting older. 

Regis: Yep. 

Corey: It's fun, though. We agreed that we could tell stories, but never name names of companies to avoid lawsuits and whatnot. But it was fascinating seeing some of the anti-patterns that emerged in running engineering companies. To tie this back to the idea of Cloud, that was one of my first AWS environments and I want to say this was, ehh, I don't know, circa 2010, give or take a couple years in either direction. Well, put some fudge factor in there to avoid lawsuits as well. 

And back in those days, network latency was crap. They didn't have VPCs, or anything like it, or not widely deployed anyway. And I think it was the VP or someone like that had this love affair with this ancient monitoring system. 

Regis: Nagios, yeah. 

Corey: I think it was Big Brother or something like that.

Regis: Big Brother. Yeah. Oh, yeah.

Corey: One of those. And because it was so flaky from network perspective, but AWS was clearly the future, instead of having one of these things, we had three of them. And whenever someone was on-call, you could just ignore the pages unless you got three of them because then if all of those listening posts found the problem, then you had to swing into action to fix it. And I think it was between nine o'clock at night and six in the morning, there was no alerting whatsoever in the entire estate, just because otherwise no one would get a wink asleep when they were on-call. And looking at this, it was, okay, this is certainly a way to wind up architecting these things. And the lesson I took from that was, I don't ever want to be in an on-call rotation where the person who dictates how on-call stuff works isn't themselves on-call because it was terrible.

Regis: Yeah, exactly. The VP that you're talking about, he designed a monitoring system, but he's not really an engineer capable of being able to design this monitoring solution. And it was terrible. And I mean, the good news is that I was able to deploy this thing into three regions in AWS, back in the day, with EC2-classic instances, just like you said. No VPCs, everything's public. But it was a great experience for that Cloud VM. So.

Corey: Oh, yeah. It was my first outing with AWS in any realistic sense. And it was okay, this is kind of awesome. But I was also short-sighted back then, and it was, “Wow, that seems super crappy. So, obviously, I'll never run anything here that's even slightly concerned with latency or jitters because it's clearly not a fit for that.” It's kind of funny of the limitations of a platform like that tend to erode over time.

Regis: Absolutely. And if you fast forward to, like, 2016, and ’17, when they started releasing all these great features in serverless, and the list goes on and on every year; it's more and more, it really shows the difference between then and now and how much it's taken over.

Corey: It really does. The world has evolved in a bunch of different ways. Well, at least I assume it has because part of it is also, I guess, my own tolerance for things. That place that we worked at briefly the first time was so odd to me across so many different axes. 

For example, they were doing this really weird implementation of Scrum meets Agile meets someone's half attempt at an MBA. And throughout the course of the week, there was never more than 45 minutes that any engineer would be able to sit down and work on something for an extended period of time. Which doesn't lead to the best outcomes.

Regis: Right. Yeah, we were planning for meetings, that would be meetings later, and then have meetings to plan for the meetings that we were going to plan things in. It was really bad. Really unfortunate.

Corey: So, time marches on. We're now in the year of our lord 2021. And you're still in Los Angeles. I'm not. But you are the founding engineer at releaseapp.io. Am I pronouncing that correctly?

Regis: Yeah, that's correct. 

Corey: Excellent. So, what do you folks do?

Regis: Yeah, so it's really exciting. We've taken this idea of—basically, for my whole career, I've been building, like we've discussed, nothing but application deployment environments. Usually, it's a production environment and a pre-prod environment. In this case, in this founding company we're saying, “What would happen if that was free?” Because you could just spin up environments today, at a whim. 

What if you could just do that so much and so fast that it was essentially unlimited? So, you had unlimited number of environments. And that's what we're doing.

Corey: So, tell me a little bit more about that. Because, again, the last time we really worked together in any depth, it was, “Oh, you want to provision something new?” Even in the world of AWS, that was, you're going to want to go and pack a lunch for this; it's going to be a little hairy; it's going to take some time. What's changed since we were sitting there beating on the custom bespoke Nagios box by hand?

Regis: Oh, yeah. Well—

Corey: Kind of a lot. But that's a loaded question.

Regis: Yeah. No, absolutely. So, if you remember, we were racking and stacking physical hardware. And I always was ahead of my time, I think. We always tried to use virtualization on that hardware, but even if he didn't, you would use the hardware, it would take weeks to rack. 

Let's say you had a box that was already racked, you needed to provision it. If it was a VM it was a little bit easier, but it was still—as you said, it would take hours— or maybe even days sometimes— to get a system running. Nowadays, you can spin up an EC2 instance—even better, you can spin up a container on Docker, in ECS or EKS, and you can have a running OS with ready to deploy applications in seconds. Minutes. And so what we do now is even built on top of that you have Kubernetes, let's say, EKS clusters, which is what we use under the covers. 

You can define your application topology and then you can just deploy it with the template in Kubernetes. We can spin these up in minutes. And so if it used to take you months to build the QA environment and keep it up to date, originally would take months, now it takes hours. We can spin you up these environments in minutes.

Corey: It seems like there's a lot of companies that are tilting at the windmill of attempting to solve for development workflow. And every time that I've tried to come in as the first DevOps hire, a quote, “Non-developer” with a wink and a nudge because I write an awful lot of YAML for someone who's not a developer.

Regis: Right.

Corey: And they wind up saying, “Great, now go ahead and fix our deployment and development process.” Oh, my God, do you run into the hell that is other people's workflows. Some folks are dyed-in-the-wool fans of local development and you need to make their laptop look exactly like production because they were on a plane once that didn't have wi-fi and ever since then, for the last six years, they insist on being able to do everything locally. And then you have other folks who are basically view, “Oh, my feature branch is called master in Git.” And it's everyone's different approach of, “Ooh, this workflow doesn't work for me at all because my special custom IDE doesn't work well in this type of environment because it's super prescriptive,” and what is that IDE you might ask? I couldn't tell you because I've never seen it before or since. And this was all at the same company. So, it becomes a bit of a problem as far as getting that hell organized into one particular direction. What's your take on it?

Regis: Yeah, I totally agree. And we find that, too. Obviously, like, in my history, working in companies just like you’ve described, what we've taken is sort of the approach that these are all environments. So, excluding the laptop—which we could actually do. You could run a Kubernetes cluster on your laptop. 

I don't recommend it—but excluding the laptop environment, all of the other environments, typically, they're hard to maintain, they're hard to set up, they're hard to configure, they're hard to make the same. And as you move through QAs, typically you move the QA to staging, to production. Those environments could be different, even in the same company, even with different platforms and trying to make everything the same. What we've done is we've said they're all the same environment. 

And it doesn't matter if it's ephemeral, like you use an environment for a PR branch, just like you've said, “Hey, I want to spin up this feature and see what it looks like.” Or if you have a QA place with people running tests against it, or if you have a staging environment where you need to test before you go to production. You have sales demo environments that need to be isolated and pristine so a salesperson can run a demo. We treat them all the same. They're all identical. And, excluding laptop, as I said, you check your code in, if you've got that application topology defined, we spin them up within minutes, and you can start using them. So, it really helps, and it makes it all uniform. 

Corey: I mean, yeah, the idea of having a Kubernetes cluster on your laptop, sure, why not? I've heard dumber things—not lately— and everyone seems to want to do it. Good for them. Back in the day, when I could travel, my laptop that I took with me was increasingly just an iPad, which meant everything I was doing was remote development. And as someone who lived on airlines a couple years ago, back when that was a thing, I never found the wi-fi so bad, I couldn't get work done or, worst case, find something else to do for two hours. 

So, optimizing for that use case is something I was fairly dismissive of. But it forced me to look at everything through a lens of at any moment, you could steal my local terminal, which is really what I was treating this thing as. But my data and the stuff that I care about should always remain safe in the Cloud. That led to a number of excellent habits and a few really strange ones for me. Do you find that what you're doing is taking a driving stance towards improving remote development experiences? Do you think that you're effectively taking an opinionated stance against local dev? Or is it more nuanced than that?

Regis: I think it's much more nuanced than that. I think what you're saying is that people would use our environments like developers would use our environments. What we're more headed toward is adding value to the business by displaying the code in a running condition that theoretically or even—possibly, depending on a workflow— that you could push a button and say, “This is deployed to production now.” So, that's more where we're headed. We generally don't care if you use an iPad or laptop, Macintosh, or Windows.

Corey: Plan 9, it is.

Regis: Right, right. Plan 9 it is. And exactly, the point there is that once that code hits the repository, that's sort of one we take over. We take that repository, we build it up, we show it to you, you share it, you use it, you test it, you burn it to the ground, you do it again. And that's where we make really easy, really fun. 

And then when you're done, we have, even, customers now that we're running and maintaining their production environment. So, once they're done testing, and they've looked at the feature, they can click that button to merge and it goes into production.

Corey: The problem that I've had whenever I've started out with the best of intentions down this path—for example, my ridiculous newsletter has a overly engineered serverless workflow that builds the whole thing—and there are two mistakes I make. One, I tend to hard code things endpoints, which make it super challenging to wind up having this portable between environments, and of course because people ask what my school of thought is, when it comes to development, my answer is, “I'm a pragmatist.” And that means that one of my production tables has the word ‘test’ at the end of it. Another one has ‘dev’ at it because once it's working, well surprise, its production now. 

It seems like in order to get that done correctly, there's a significant level of unwinding that needs to get done of refactoring out hard-coded endpoints and credentials, in some cases. How do you approach that? Or is it something that, I guess, enforces those good behaviors upfront, which is really what I need. Basically, if there's a SaaS that offers adult supervision for developers, I'm extremely interested because Lord knows I need it.

Regis: Right. No, you're absolutely correct. In my experience, the development environment, or the POC is actually what becomes production. And what we do, I think we do a combination of both things of what you mentioned. First of all, we sort of do enforce this idea that your end goal is this production environment. 

It doesn't have to be, but that's sort of what we do from the beginning. This environment that we create based on your code it's deployed into, it's isolated, it's designed to look like production. Because let's be honest, it probably doesn't function well if it isn't very similar, or even exactly the same as production. And the second part that we do is, we templatize all of those variables out for you. So, if you think about it, if you spin up your environment and it has a database, and a back end, and a front end, you need to wire those all together. 

So, all of those variables have to be templatized, and filled in, and formatted. And we do all that for you. So, really, when you start up with this environment and it's the first time you've ever used it, you can play with it until you break it. And then you rebuild it, and you do it again, and you break it. And you mess it and you name the tables ‘test,’ and everything you want to do.

Corey: And then things aren't working and you keep fiddling with something, and one of your fiddling random winds up working suddenly, and, “Oh, my god. Touch nothing. That comment is now load-bearing.”

Regis: Yeah, well, that could happen too. But in any case, the point is you do reach that point where it's stable. And then you save that template—

Corey: Optimist.

Regis: [laugh]. Maybe. And then you're ready to go from there. So, you can make a new version— we version all of your templates; we version all of your application code. So, it's like, you can always go back, you can always move forward, you can feel confident that the one that was working previously, you can always go back to that. And then when you get a new one, you can work from there. And so it really does help and it covers all those bases that you talked about. 

Corey: This episode is sponsored by ExtraHop. ExtraHop provides threat detection and response for the Enterprise (not the starship). On-prem security doesn’t translate well to cloud or multi-cloud environments, and that’s not even counting IoT. ExtraHop automatically discovers everything inside the perimeter, including your cloud workloads and IoT devices, detects these threats up to 35 percent faster, and helps you act immediately. Ask for a free trial of detection and response for AWS today at extrahop.com/trial.

Corey: So, help me understand the career progression here. You went from a sizable environment that was cloud-native that was built out very well because you and the team got to determine that that was the way it was going to be, to go be the founding engineer at a four-person startup. And you did this towards the end of the summer, back when the pandemic was in full swing. At some point, it feels like… what is it? You missed re:Invent and decided, “Well, you know what, I want to go put it all on black somehow.”

Regis: Yeah, exactly.

Corey: What happened?

Regis: It's a huge gamble in the middle of a pandemic to leave a stable, comfortable job that I basically built with my own hands, and as part of a wonderful team of people. And the thing that really drew me to this was, it's sort of a purer software play on what I've already been doing my whole life. So, thinking of going into a data center and building equipment, and racks, and wiring networks, and putting it all together, versus building VMs versus running serverless, versus doing all of these new features with Kubernetes and containers. It's just the natural way of things that are going and being able to write the actual code that makes the code, if you will, or to build the factory that builds the factory, that's really appealing to me. And I just, I couldn't pass it up; it was just the right opportunity at the right time. And in the middle of all this thing, I just— I feel so lucky to have the option to do it at least. And I would have regretted it if I hadn't tried.

Corey: I feel like there's a definite story to be told there, where it's this idea of at some point, people decide to take the gamble, make the leap, and do the startup thing. And I feel like people look at me with starting my own consulting firm aimed AWS bills in that same light. Except it wasn’t. It was, honestly, I am a terrible employee. I mean, all the negative aspects of working with me that you remember or have the good grace to pretend you don't, didn't get better with time in many respects. 

At some point, my core competency really became getting fired. And from there, it was— honestly, I started this place because I didn't feel I had another option left that I could stomach. And from my perspective, it was always this entire world of making sure that well, my answer is, “Or starve,” so I guess I'm going to do this, you were very much not in that position. So, I guess I'm just trying to vicariously see how the other half lives.

Regis: Yeah, I think of this is kind of like opposites but the same, if you will. I'm a team player; I like showing up at nine to five; I like saying, “Yes, sir. No, sir.” And you're totally the opposite. I think that's what makes it great. At the core of it, everybody's different, and everybody has different needs and different wants and all that.

Corey: Yeah, it's a hard problem. But if you take a look across the entire ecosystem of all of the various startup options, I mean, I worked with you before: you are no slouch, even in a pure engineering sense, let alone all the other stuff you bring to the table. There was a lot of options as far as directions to go in. You could attempt to swindle people with cryptocurrency, you could attempt to swindle VCs by just pouring AI and ML on something or, God willing, both. But instead, you decided to focus on the developer tooling aspect. What was it that drew you in?

Regis: Well, like I said, it's a pure software playing, what I've done my whole life. So, I feel like if we can do this right, we can stop building DevOps deployment toolsets. It's like, can we solve that problem and get it over with? If you think of, in terms of thermodynamics, most of the work that we do in DevOps are in the back end. It's sort of waste if you think—not negatively, but it's just leftover heat. 

So, if you spend 99 watts of energy building all this stuff in the background that doesn't really do anything, that 1 watt of useful stuff that comes out in production, it's kind of like, can you just buy that? Can you just pay, Release to do your production environments or your staging environments, any kind of environment you need, can you just pay us to do it, and we'll do it for you and turn it out, and nobody ever has to do this ever again. That's really what I want to do.

Corey: Okay. I am going to do my best to keep a straight face for this question because I'm sure that your company has been asked this by investors. Are you worried [laugh] about Amazon moving into your space? I almost made it.

Regis: [laugh]. Look, you would be foolish to ignore them, right? In point of fact, most of their products are complete garbage, as you know. So, I am not too worried about it at this point.

Corey: Yeah, that's honestly, the fact of it is. And I know it's not a popular opinion to take, but AWS does awesome work at building infrastructure that scales globally, it becomes this amazing world-spanning thing. That's great. They build the bricks that you use to build, effectively, the digital equivalent of houses. They never pay the picture of the houses and every time they attempt to move up the stack into a SaaS offering… maybe I'm just lacking vision, or I'm forgetting something key, but are there any AWS SaaS products that we can point out and say, “That nailed it?”

Regis: No, course not. And like you said, they make the bricks. They have this concept of undifferentiated lifting. They say, like, “Well, everybody builds a data center, and everybody has to rack and stack servers, so let's take that away. Okay, that's undifferentiated.” 

They said, everybody has to write scripts now to make an EC2 instance and a VPC, and, you know, how many CloudFormation templates, and how many Terraform scripts, and all of that stuff that has to be done? So, they've just made it differentiated lifting, I guess, at this point, where everybody does the same but different unicorn lifting. So, we're trying to remove all that. We're trying to actually make it so that you can point-and-click and actually realize that goal of having any kind of environment that you need spun up, and it's isolated and it runs. And it really is that simple. Not like, you start running some scripts and then you copy some things from Git and do all of that.

Corey: It just seems like there's such a lost opportunity here. I worry, honestly, that Azure is going to run away with the cloud world, just because GitHub as an acquisition, in hindsight, was brilliant. And it feels like they are one step away from, “Oh, deploy this thing on to some Azure service with a single click in the GitHub interface.” And at that point, well, wow, that becomes a story that I don't think any other cloud provider can touch.

Regis: Yeah. And what you've just described is what we're trying to do, and we're running like mad to get there.

Corey: Yeah, I really wish you well on it. As you're looking across the entire landscape now, what's the hard part? What are you focusing on? What's your area of, now it's time to do this piece of it? I mean, there's always the chop wood, carry water aspect of it, but there's also the question of in a world of infinite work—welcome to startup life—what do you focus on?

Regis: The main focus for me has always been the same during my entire career is to add business value. But for whom? The business value that I'm now trying to offer is for our customers. So, typically, try to go to a company and say, “Hey, you need to deploy this software, I can make a deploy.” 

Well, now I'm saying to all my other customers, you know, all the customers who come to us for this product, I'm saying, “You want to deploy this, I can make a deploy.” The hard part is onboarding. How do we take every unicorn and put them into a box? It's really difficult to say, like—

Corey: Believe they're called ‘paddocks’ for one.

Regis: [laugh]. Yeah. Well, it's like, how do you corral them? How do you box them? How do you ship them?

Corey: Flattery works well.

Regis: Yeah. We really have to get focused on getting these customers onboarded. And once they use the product, it’s wonderful, but I think we just need to get that little ramp-up going nicely.

Corey: So, I have to ask, given my position in the cloud industry, what's your monetization strategy?

Regis: It's really simple actually. We charge basically, based on environments. We're working on the model, so it's, do we charge per our users? Do we charge our users who use the environments? Right now we just charge by the environment. So, if we manage a pack of ten environments for you, we charge monthly for that. And then you scale up, we'll deal with it at an enterprise level at that point.

Corey: Gotcha. It's always challenging to talk to the developer tools folks, just because on some level— I don't know how to put this politely so I'm not going to even bother. Some of the worst customers in the world are engineers—

Regis: Yeah.

Corey: —because you talked about a tool that makes their workflow better, and they look at that and they say something moronic, like, “$2999 a month? Please. That's serious money. I'm going to spend eight weeks building my own crappy version instead.” 

And sure, okay, great, I get it. But if that's not the core competency of what their company does, there needs to be a correction story there. On some level, they're challenging to sell to on a variety of different levels. When I was first starting out with my consulting work, talking to engineers, it was, “Well, okay, so you do this, this, this, this, this, this, this, this, and this. What? That doesn't sound hard; I could write a script to do that in a weekend.” 

Spoiler, if you can write a script that does everything that I do in a weekend, please call me. I have a job waiting for you. But it wasn't realistic, so at some point, it was, “Okay, I get it. No, you want to build your own stuff. That's cool. Thanks for meeting with me. Oh, by the way, can I chat with your boss real quick?” 

It's one of those things of just talking to the folks who are empowered to see the higher-level strategy was sort of the right answer. But I was never selling developer tools. Do you think that there's a go-to-market strategy that works with folks that are, A) skeptical because developers love to build, and, 2) in many cases, where their signing authority caps out at 50 bucks.

Regis: No, you’re absolutely right. We're not targeting any kind of hobbyist. We're definitely targeting startups like ourselves who maybe don't have a lot of DevOps engineers or maybe no DevOps engineers, all the way up to enterprises where we would basically be competing with a team of DevOps engineers. But the way that we've approached it—you're absolutely right—is, first of all, we have to convince the potential person or the people there that these environments are important. So, what would happen if you had only one QA environment and you could only test one feature at a time? 

How long would it take you to deploy new features in production? You know, all the things you need to do? What if you had 100 of those? What if your salespeople could go out and they could get a stable version of your product that you sell, but you don't have to worry about deployments and you don't have to worry about another salesperson sharing that environment. Ten minutes before the meeting, the salesperson, say, spins up a brand new environment, displays it to the customer, customer can maybe even—leave it with the customer so the customer can log in and use your product for a week, and then it disappears at the end of that or something. 

What are all these values that can be unlocked by the environments? And then you think about even scaling that up to the holy grail of, like, what if you had more than one production environment? We talk about blue-green, for example. What if you had rainbow production environments? What would that even be? What would it look like? We don't even know. 

The other thing is, in terms of value for the customers, what we look at is, how long would it take your DevOps team— or you yourself if you're the only DevOps engineer— how long would it take you to spin up a Kubernetes cluster that handles multiple environments, all the templating, with all of the configuration YAMLs, the 30 or 40 configuration YAML files that you need to manage, and all of those deployment pieces that you need glue together, all the integrations with GitHub, all the integrations with Slack, all that. It would not be a weekend exercise, right? We know, anecdotally, it takes about six months to implement sort of a new pipeline or new features that are in the production path, at a minimum. And if you're a startup, you don't have six months. You have a weekend if you're lucky. So, how quickly can you turn this thing on and get it running? That's what we focus on.

Corey: It seems that getting something out the door that developers like, but also solve serious enterprise problems is sort of the sweet spot right now.

Regis: Yeah, exactly.

Corey: I'm looking forward to seeing what happens next. If people want to follow along with your journey, where can they find you?

Regis: They can visit our website, it's just https://releaseapp.io. And they can sign up for free with GitHub]. They get two environments to start with. And for Christmas, we ran a promotion which is still valid, I believe. 

You can get a free Minecraft server, so you can read our blog to figure out how to start a Minecraft server, it’s just something fun you can do and shows off what our environments do. But yeah, it's pretty fun.

Corey: It seems it. I will be following along and we'll of course put links to that in the [00:32:13 show notes]. Thank you once again for taking the time to speak with me. I really appreciate it. It's great to catch up. 

Regis: Oh, yeah, thank you, too.

Corey: Regis Wilson, founding engineer at releaseapp.io. I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice, along with a comment that includes an entire performance review over my nonsense over the past year.

Announcer: This has been this week’s episode of Screaming in the Cloud. You can also find more Corey at screaminginthecloud.com, or wherever fine snark is sold.

This has been a HumblePod production. Stay humble.