Brian: PodRocket is sponsored by LogRocket, a frontend monitoring and product analytics solution, which is to say, it's not really sponsored by anyone. It's sponsored by us, LogRocket, and we're giving it away for free. The podcast is free. The product is not free. There's a free trial. We could split hairs about whether or not that's free to you, but anyway, that's it. There are no more ads. If you're interested and you want us to know that you came from the podcast, please go to loglocket.com/podrocket. If you don't care, logrocket.com works just fine. Thanks. Brian: In this Founder Friday episode, Ben interviews David Thor, founder and CEO of Architect, the world's first DevOps-as-a-service platform, they talk about the DevOps landscape, how Architect improves developer productivity, and how it helps teams adopt best practices. Let's get started. Ben: Hey David, how's it going? David Thor: It's going well. Thanks for having me, Ben. Ben: Yeah, super glad to have you. And as someone building a company in Boston myself, I'm always very eager to talk to other people building companies in Boston and investing in this tech ecosystem. It doesn't get quite as much hype as some other cities, but I mean, there's so many talented people here. And it's been a really supportive and awesome community for us at least, so I hope that has been the same as you've been building your company. David Thor: Oh, definitely. And same with past companies too. Despite us not getting a lot of the notoriety, there's a lot of opportunity here to in the startup landscape, for sure. Ben: Yeah, so I want to jump in and learn about Architect. I would love to hear a bit about what you're building. I mentioned this to you before when we were just chatting, but a lot of our podcast audience tends to be frontend developers. We can certainly go deep and learn about a lot of what you're doing, but I want to make sure that it's approachable to audience members who spend most of their days building frontend infrastructure. Tell me a bit about what you guys do. David Thor: Yeah, of course. Notably, I think a lot of the audience that runs into the problems that we're talking about is back-end engineers with containerization and microservices. But the reality is that the problems plaguing DevOps, the problems plaguing with automation and with deployment in general today have to do with a lack of capturing relationships with green applications. David Thor: Even in the frontend landscape, people building web applications, usability, and user experiences, eventually connect back to databases and APIs. And in many cases, those APIs have their own dependencies and messaging cues and other APIs, and so on and so forth. These relationships matter, but they don't get a lot of love. Really, they are effectively the key to achieving automation, is by capturing those more effectively. David Thor: Our product actually takes inspiration from dependency management like NPM, for a lot of people familiar with frontend, to allow people to assert the relationships and dependencies that are external to their application. "I need payments API. I need just the backend API for my frontend. I need a database." These are things that we can assert simply, we can specify the versions that we need. And our system will not only deploy your application, but it'll auto-provision those dependencies, auto-connect to them and automatically write all the strict network policies to make that happen in a secure fashion. David Thor: Taking what started as container delivery and making it truly application delivery, application deployment. Everything's connected, everything matters. If I have dependencies on something that's more than my own code, I need to make sure that's there. And if it's not there, I need to make sure I make it and connect it. Ben: Got it. Imagine I have a service and this service is responsible for... You mentioned dependency is something maybe like a payment service it depends on and that could be my own payment service, or would it be fair to think about Stripe as a payment service that it might depend on? Explain a bit more. What is the problem that DevOps teams and developers face today when you have some service that might depend on an external service like Stripe and how Architect streamlines that? David Thor: External, internal services, really the only difference is who's responsible for standing it up, who's responsible for making that API available and potentially where it lives too. It's either going to live inside my infrastructure or some other company's maintaining it for me. David Thor: Same thing with databases too. If I were to make an RDS instance, Amazon's just maintaining the database for me, but I could just as easily make one myself. But from my applications perspective, the only thing I really cared about was that there is a database and there's an address and credentials for me to connect to that database. David Thor: But doing that as more than just saying so today. If I, as a developer, make something that needs a database or needs to connect to a payment service, I need to tell someone about it. I need to say, "Hey, you need to make this API available. You need to make this database available. You need to tell me what address it has. You need to tell me where the credentials live and how I can get them. If you need to change credentials, we need to coordinate." It's this whole back and forth process. David Thor: And then when developers try to do it themselves, that's how we often end up with things that they're not familiar with, like networking policies and networking security being a weakness. We've seen a lot of high profile hacks in the last five, 10 years, where a lot of developers now have new access to make databases, to make messaging queues, to make APIs, but they're not as sophisticated or familiar with the security practices and network security and protocols and tools. David Thor: That's really the job of operators, and DevOps has emerged as kind of that role to glue those roles together, to help developers engage with operations and do all this stuff safe and secure. It's still a very manual process and it's manual simply because we don't give a lot of those relationships love. We require it to be manual. We say that these DevOps engineers need to come in and help you transform your application into infrastructure. But all you cared about was that the API exists and that I need the credentials to access it. David Thor: And if you have the simple way to assert that, we truly can automatically turn that into infrastructure. We don't need that DevOps role anymore. We can just allow you to serve yourself, allow you to assert these relationships and automatically deploy. We're about giving that power back to developers, making applications, to integrate with other stuff and make their own environments. David Thor: If we wanted to stand up something end to end but I needed a database and an API and another API, it becomes a lot for me to actually provision. If we index those relationships, we can do that all in one fell swoop, one command, and it's all just automated and automateable for everyone. Ben: What is the process of defining those relationships look like? Is it a YAML file, some of configuration file, or is it something you do in a UI? What is the interface for developers to build these relationships? David Thor: For us, it's very much configuration file based. We tried to take a ton of inspiration from NPM, because it was such a popular tool that provided such a graceful experience for dependency management, not for microservices but for libraries, but that usability still holds true for microservices. It's just the resolution process is different. Instead of downloading all the source code that is from all these dependencies, we have to actually run the services and then broker the connection to it. David Thor: We're doing all that. We fulfill it a little bit differently than NPM does with package management, but we provide the same usability. You just write a simple YAML file, Architect.YAML, you cite your dependencies and we're able to provision all the resources you need as a result. Ben: And in terms of actually provisioning these resources, can you do it on any cloud environment, AWS, Google, Azure? I have an existing environment. Do you plug into any cloud and do the provisioning? Or how does that work? David Thor: Yeah, we support any cloud provider right now. Notably containers are the main predicate or main resource that we demand for our applications. Anything that fits inside a container or anything that can be a hosted service, we can automate the instrumentation of, automate the configuration and deployment of, and service discovery, network security, credential management, all that jazz. But really the goal is that we can support any hosting provider, any cloud provider that you want so that your application can live where you want it to live and alongside all the other stuff that's already running. Ben: And in terms of running in containers, does that go for databases and stuff as well? Or what about the things like big query or some of the provider-specific services that don't neatly fit into a cross-platform container? David Thor: That's a great point. It can include containers, but really the idea is that from a development perspective, the database is a great example where I care that the database was made, that it's running, that I have access to it, but I as the person making the application don't really care how. David Thor: If I, for example, ran it locally for it to be run inside a container is totally reasonable. That environment might not be around tomorrow. I might completely reset it tomorrow. But for production, that's not acceptable. We need something more persistent, more manageable and more secure. I should still be able to say, "I just need this Postgres instance," but the team managing production for me can say, "Postgres instances mean RDS instances in production or they mean cloud SQL instances in production." David Thor: And that's really where the separation of duties game comes in, where you building product features don't need to worry about it, but we still offer all the hooks, tunes, and dials to operators to come in and say, "Databases mean this in this environment." They still get control. We don't sacrifice it. It's still your environment and your infrastructure, but developers building features don't actually have to worry about that fulfillment. Ben: In a lot of ways, it's not just about a tool to improve developer productivity. It's a way for teams to really think about, as you said, separation of duties and team organization and team responsibility. David Thor: Yes, exactly. Ben: Always interesting when a tool or a product is not just a tool or product, but something that helps a team best practices and can kind of bring consistency across different teams and the way they see the relationships between developers and DevOps and SRE and all the different teams. David Thor: Exactly, and SREs and developers both have valuable roles. People need to operate production and people need to know how to run databases at scale and need to know how to do security policies. But those don't have to be the same people that build new UIs for customers, that even build APIs for customers. Those are two totally different separate feature sets. There's two different skillsets. David Thor: And while we have DevOps roles that are supposed to help with that, it's simply because of a lack of these two parties to coordinate that we have that role at all. And if you go to our website you'll see that word DevOps-as-a-service, that's because we offer that glue in between the developers and operators. We help translate the relationships between apps and services into infrastructure per what the operators want. Ben: And so I'm curious to understand the ecosystem. I know HashiCorp comes to mind when I think about like tooling in this space. How does Architect compare to some of the services from HashiCorp, like Terraform or some of those tooling that do try to automate configuration and put configuration as code and some of those concepts? David Thor: Of course. And we're not shy about this at all, we are built heavily on top of HashiCorp products. They have built a lot of these granular infrastructure utilities that are extraordinarily valuable at scale, but it's really the developer experience for them that's lacking. David Thor: They're designed to make the lives of operators easier. They're designed to make it so that I'm not bash scripting to make infrastructure, I'm declaring it as templates and code. But for applications, it's still a lot and it's a new language to learn. And then I'm hard coding it all to the different deploy targets. I'm hard coding it to AWS or to Azure or to Kubernetes. David Thor: And really, we want to simplify that for developers. That you really don't care about the infrastructure as long as you trust the parties that are going to fulfill it. What you care about is that the things I need are there and that I can connect to them, so just give me the addresses and give me the credentials and take care of the rest for me. That's the experience we want to provide. David Thor: And also we want to help solve the problem of distributed contributors, microservices, applications. People who build different apps that share infrastructure inside big organizations, they all phone home back to the same infrastructure. And all the information comes from so many different organizations, so many different teams. We don't want them to have to all work in this mono repo of templates and infrastructure as code to say, "Hey, where does my application need to fit in all this?" You can just say, "Here's my thing. Here's the things I need to connect to," and we'll string it all together for you. Ben: Got it. The UI portion is a big part of it, it sounds like, in terms of visualizing that map of the application, its dependencies, and making it easy for everyone in the organization to understand what services talk to what services? David Thor: Yeah, so UI, but more importantly developer experience. Actually, a lot of our developers working with us get the most benefit working inside an experience much like package.json for NPM, where I can describe the dependencies from an application and then use our command line interface to have that translate to on-demand environments. David Thor: Developers working on new features with us, what they'll do is they'll make this manifest file their site the dependencies. So I might need the payments API, I might need a Postgres database, I might need a RabbitMQ messaging queue. I put that in my manifest file and then I run `architect deploy`. That'll stand up, not just my application, but all three of those dependencies too. David Thor: And in some cases, those dependencies have dependencies. It doesn't matter. We'll figure it out. We'll build the whole graph and the whole tree and make everything needed to power your application so that you can have a full end-to-end on-demand environment that includes all the APIs and backend resources you need. So if you're building a frontend app, you can just get push button ability to stand up your own environment, no shared QA. You don't need to worry about the remote dev environment being down. You just get a totally isolated sandbox that can go up when you're starting your work and go down when you're done. Ben: And so I'm also curious Helm and Kubernetes operator, two other technologies that are kind of in this area. Tell me a bit about how Architect compares or builds on those tools. David Thor: Of course. Those are two very different technologies and practices, so I'll address them both separately. Helm, of course, pitches itself as a package manager for Kubernetes, if not for microservices. It's a very similar pitch, but it's implementation is very different. David Thor: Firstly, it's only for Kubernetes. And because of that, it means that everyone who wants to write a package needs to learn the Kubernetes manifest language, needs to build Kubernetes templates, needs to know the difference between a pod and a deployment and network policies and Ingress routes and rules. It's basically a whole new language to learn and it's an infrastructure language. And while it's a good infrastructure language it's made for operators that now developers are having to learn. It's a little bit inverted in who it's made for, and it's asking a little bit more of developers than they should be asked to do. David Thor: Now, it also has dependency management built into it. The idea that charts, as they call their packages, can depend on other charts. But that dependency relationship is actually hard-coded. There's no such thing as sharing dependencies, unlike all the package managers we're familiar with in the frontend, like NPM, like Python pip, if you've ever built a Python project. All of those are resolvers. When you deploy or pull into a shared environment, if it finds that the two things depend on the same thing, it'll reuse them. David Thor: Helm doesn't really have that notion. It's all just building one macro package, one macro thing that depends on everything. So if two people dependent on a payment service and deployed in a different namespaces, they wouldn't find each other, they wouldn't really use the same payment service. They'd actually spin up the payments service twice, duplicating resources and limiting the ability for that to be a collaborative experience. David Thor: Our system really is designed so that things get reused when they can be reused. We really use semantic versioning. We really use dependency management to make sure we can actually we'll limit the footprint of the application and make it so teams can really own and manage the different applications that they've built. The payments team isn't just part of the application above it, it is a running thing that needs to be observed and monitored and taken care of when it's in production. And everyone who deploys and consumes that should connect back to it so that everyone can do their job effectively. David Thor: We really take a little bit more and heavier from the benefits of package management to bring them to microservices, rather than just trying to make ways to build clever but large giant mono charts. And of course, we're not limited to Kubernetes too. That's the other benefit. Ben: Yes, DevOps. Some of what you're describing reminds me of Heroku, which was super revolutionary when it first came out and everyone was using Heroku five, 10 years ago... I don't know if they've been out for 10 years, definitely five to seven years ago. I feel like I put every project on Heroku. And they really did have a lot of this magic in terms of standing up services quickly, easily describing and launching services. Ben: I'd be curious what, if any, inspiration you took from Heroku and I'm also curious why Heroku it seems like they've kind of declined quite a bit in popularity. I don't really hear people using them anymore, but maybe curious to hear your perspective on that. David Thor: Yeah. Well, I'll answer them in backwards order actually, because I find that to be the more interesting way to think about it. Heroku was obviously enormously popular very quickly. It made infrastructure tangible and approachable for developers so that you don't need SREs or operators, anything like that. David Thor: There's really a couple of things that came up that surpassed it for a lot of reasons, serverless being one of them. But also the other hosting providers, like AWS, GCP, Azure, started having competitive platforms, competitive, easy ways for developers to deploy their code, or at least just for their application and distribute that. And the teams, the operations teams liked working with AWS and Azure better because they were already there. David Thor: I don't want just some of these applications off in Heroku, especially when I don't control the infrastructure. Let me control the VMs and you can deploy on it and we're both happy. That kind of led to that translation off of Heroku because their competitors basically provided the same functionality but made the operators happy too. Long-term that pans out better. David Thor: But the other reason is that Heroku provided a great experience for deploying an application, just bundle of source code that they figured out how to run it and distribute it. But again, they didn't solve a lot of these problems with how do I connect to other things? You have environment parameters that include things like the address and credentials for a database or for another API. David Thor: But at scale that's hard to reproduce, hard to rationalize about, and then precludes you from having kind of a visual set of what's talking to what at any given time. It makes it very hard to audit and understand. And the more you invest in that process, the more complicated it gets and the more you lose track of it too. Really that idea of compliance inventory audit starts to break down a scale when you deploy on infrastructure like that without large scale visibility or structured integration. Ben: That makes sense. And so by a platform like Architect, you get the advantage of being able to deploy in any cloud, whatever the native cloud of a given company is, Google, Amazon, Microsoft. And by having a schema and structure to describe the way the services connect, it allows you to do a lot of cool things like showing that map and visualizing, and having the understanding of how the services talk to each other and stuff. David Thor: Exactly. Ben: Now, another area I'd like to dig into a bit is security. That's something you brought up early on as one of the advantages for adopting something like Architect. Tell me a bit more about some of the common security issues companies have as they're adopting microservices and how Architect helps. David Thor: Yeah. And as with almost all things in security, the biggest weakness is human error. It's not the fact that we have a lack of security tools. We actually have really good availability of encryption, a really good availability from the cloud providers to actually lock down applications as best needed. Then the weakness becomes our application code. David Thor: But really the two problems, is, one, like I said application code. If you have a bug that leads to a security vulnerability, that's a problem. But only you can resolve that. The things that were preventable issues are when people aren't aware of the security features or the best means of configuring them. And it's complicated. Do I make AWS security groups? Do I have to encrypt traffic in transit? Where do those security keys go for the encryption? David Thor: There's a lot of steps there. And when you have product teams breathing down your neck saying, "We need to release these features," and they've already seen it working on your machine, the priority isn't security anymore. It's deploy it. Let's get it there, let's get it to production, let's get it in front of customers. Then you say, "Hey, we'll circle back and lock this down right after." And that just often doesn't happen, because we're on to the next feature, we're onto the next product. David Thor: Really security needs to be able to be automateable, so that people working on product features who serve product teams can work on products features and serve product teams. And security, you can serve those engineers doing that. But that really just doesn't exist. David Thor: What we do is through those relationships, we transform and translate that into the security needs based on where you're going. If you're deploying to AWS, we'll automatically make the security groups and lock them down as much as needed so that you can only talk to the things that your application needs to talk to. If I'm inside the same environment as a Postgres database, but I didn't need that Postgres database, you can't talk to it. David Thor: And those are the kinds of things that are really hard to do because no single party knows all the relationships, and the people building the applications don't know how to lock it down. Unless DevOps gets involved, unless SecOps gets involved, no one's actually going to go back and fix that problem. The option there becomes automation. And that's really what we provide is grab the relationships right up front from the developers and security will be automated hands down. Ben: You mentioned building a lot on HashiCorp technology. I believe everything, or the vast majority of what they build is open source. Is Architect open source? Is open source part of your future plans? Curious to hear how you're thinking about that. David Thor: Yeah, open source is part of our future plans. It was actually quite difficult for us to build open source on top of so many different open-source libraries and tools. And because of the way we do pipelining and orchestration, what we would have to open source would be a pretty large scale application. The experience would be a lot more like a community edition of GitLab, rather than a library you run on your own. David Thor: And in that regard, there is of course inspiration for it. But for us to circle back and figure out how we draw those lines and how we fork off releases for community edition and enterprise edition, that's a lot of work, work that we want to get to one day. We certainly want to make it so that smaller teams and smaller orgs can access the same framework for collaboration. But today, we're right now focused on enterprise use cases. There's a lot of mid market up that's struggling to build DevOps teams or platform teams that we can say, "Hey, we've done it for you," and just drop it into their organization. Ben: Got it. You don't think open source, as of today, it seems like it's not a barrier to companies adopting? People see the value and they don't care if it's open source or not. David Thor: Yeah. I mean, at the end of the day, people are staffing up DevOps teams and platform teams to do exactly what we're doing. I came from Facebook before this. They have many teams building internal developer platforms that are designed to help people build, create, and integrate microservices at scale, and designed in such a way that not every team needs a DevOps engineer. David Thor: The whole point is that developers can serve themselves and get their code out there. But not everyone has the ability to hire 12 engineers to build and maintain this platform, especially a platform that's just an internal tool that doesn't provide direct value back to your customers. Instead, we've done all that work for you. We can drop it in today, and we'll maintain it and add features to it over time so that you can focus on what your customer and what your business does best. Ben: And was your experience at Facebook kind of what inspired you to go and start a company? We've seen a lot of very successful businesses that have been built by people coming out of Facebook, Google, the huge companies that have a lot of incredible internal tooling, and we've seen a lot of successful companies take inspiration and build it for everyone else. Would do you say you kind of fall into that camp? Or if not, what inspired you to start this business and build Architect? David Thor: Facebook definitely provided validation of the idea for Architect in particular, but actually this business is my third startup in the last seven years, the first of which was a dev shop that I had built out right after college. I wanted to do consulting, wanted to get a better understanding and pulse for what other people were building. And more importantly, I was very interested in the business side of entrepreneurship, what it took to build and scale a business, how you understand what resources you allocate, how you acquire customers, the pipelining, the architecture of the sales process. That was all very interesting to me. David Thor: Around two and a half years into that life cycle, I had the opportunity to merge that in with another startup in Boston founded by several well-known entrepreneurs. The company would become known as Confirm.io, who was doing forensic analysis of driver's licenses and passports by taking a picture from your mobile phone. It was just a simple API service that had an SDK, very targeted, very lean, and enormously valuable to banks, sharing economy and lots of other people that were trying to combat fraud and get ahead of regulation. David Thor: Facebook wanted that so that they could put it in front of a lot of the surfaces that they were most at risk for. Every time you go to put a political ad on Facebook and pay for it, they actually prompt you to take a picture of your ID to make sure that you are who you say you are and that you are affiliated with the region that you're actually advertising for, to make sure that they can be in compliance with that stuff. David Thor: That was an interesting, actually, double acquisition for me, first merging my dev shop into what became known as Confirm.io and then seeing that company bought by Facebook. That's how I landed there. I've had the bug for startups for years and years and years obviously. But this was actually seeing all the problems, zero to 60, from both those companies, and then seeing what it looked like at Facebook scale at the end of the journey. And seeing that, all right, the thing I was trying build for Confirm actually was the successful solution that these large organizations build at scale. And that was enough evidence for me to say, "Hey, it turns out a lot of people have this problem and not enough bandwidth to build it. Let's actually carve that out, do it for everyone so that not everyone needs to invest in a giant platform team." Ben: Got it, and tell me a bit about your progress. You have a couple of team members. What does the team look like? What's kind of the thoughts around customer acquisition? How are you reaching your users? Curious to learn a bit about the business side there. David Thor: Yeah, it's been quite a journey. We are formerly about a little over a year and a half old. Raised some money about a year ago just before we all got locked down, enough to fund our lean but mean five-person team, including a long-time friend of mine as a cofounder. But we're all engineering today. We have been focused on product, product, product, making sure that this is a stable and secure as possible. David Thor: And with a business like this and developer tools, we wanted to make sure that with our investors and with everyone we pitched to that they knew we were in this for the long haul. That this is something that is important for us to develop trust with the community, just as much as it is for us to build a business that can scale and support itself, is that those two go hand in hand. David Thor: We have been working tirelessly to make it so that our platform, which takes this architecture as code framework I described that is like NPM but for microservices, can ingest those. Build a package registry like you would experience there so people can find and discover microservices, and allow any one of those services to be push button or automatically deployed into any cloud environment. And we've successfully done that today. David Thor: And what we're doing now is starting to expose more operator features. We've spent the last six months or so since we opened our beta focused on what tunes and dials do operators want that matter for them in production. Not just what container platform do I want them deploy to, but what API gateway do I want? What service mesh do I want? Where do I want application credentials to be stored? These are all the kinds of things that we're integrating with now to make operators happy, because we spent the first year and a half of laser focused on the developer experience, making sure that their ability to describe the things outside their container was easy, effective, and approachable so that they can do it themselves. Ben: I'm curious a bit about the deployment model. Are you hosted or is it something that you stand up? Is there some meta thing there about standing this up as a service with relationships within your existing microservices environment? But tell me a bit about how you actually get started and how you bring architect into your organization? David Thor: Our application, despite us being a fairly young company, is a fairly complex backend. We have a component registry, we have our API and we have our frontend. We've got a couple of databases, messaging queues. We've even got a whole open source continuous integration solution that does a lot of our pipelining and async execution stuff. There's a lot that powers it, but we actually have been able to successfully, not just have a hosted SAS business where people can subscribe to our product, register their own environments, sign up for their own accounts and deploy into their favorite Kubernetes cluster or a favorite cloud platform. David Thor: But our more compliance and security-conscious customers who don't want to give us credentials, actually are able to have a private installation of our cloud product inside their own cloud. And we're able to fulfill that by actually deploying an instance from our SAS products. There's a little inception game there like you might've imagined, where we've been able to register the different parts of our application as units, as components inside our platform. And as long as we're given credentials into one environment to deploy to, we can stand up an entire instance inside the customer environment. David Thor: If they have a Kubernetes cluster or if they have an ECS cluster, or if they're on AWS, Azure, Google Cloud, it doesn't matter. We just deploy the entire platform into them. And anytime they want updates, they just press the button and they get the latest version. That's been a very easy way for us to deliver that value to larger security-conscious enterprises, where we get the best of both the SAS business and an on-prem business. Ben: How does auth work internally? Can you leverage roles within the AWS roles and Google and the existing auth systems? Or do you have your auth system in terms of like providing access control and auth to work within Architect? David Thor: Yeah, that's another good question. We had started off with AuthO, and for reasons unrelated to the reason news about their acquisition from Okta, we had made moves to migrate off it. Namely because as we started doing on-prem installations, we realized that we didn't want to have to sell AuthO with our product to all of our customers. We didn't want to have to pitch them on someone else's product in order to sell our own. David Thor: To alleviate that dependency, we actually found several open-source solutions that we could host ourselves, that we could wrap ourselves, that we could control the UI for ourselves. We packaged that up into a nice, pretty component and made that a dependency of our application. And now every time we deploy on-site, we're deploying an entire auth service with it. Fully OAuth compliant, a full-user management system. All the credential storage and management is all nice and polished and uses all the latest and greatest security practices. David Thor: For anyone wondering, we are using ory.sh's open-source products, Kratos and Hydra. Very interesting stuff, pretty complicated backend products, but once you've built out the office service, it's amazingly flexible on the UI side, on the backend side, so I highly recommend it. And now we're able to deploy that whole stack and that open-source technology along with our own. Ben: Yeah, we'll put some links to those platforms in our podcast description. I mean, especially with their recent acquisition, I definitely hear people kind of thinking, "Oh, is Auth0 what we want to be building on long-term?" Definitely I think a lot of people are thinking about alternatives. David Thor: Yeah. And that describes what we are going to be making open source as well, so anyone who wanted to try out deploying an auth stack inside your cloud environment, along with your application, you can use Architect do that. We'll deploy all the services, do all the network security, all the credential management, and it'll just go out for you Ben: Curious when you talk to your clients, and especially if you do interface at all with teams building frontend applications or user facing with applications, what are some of the common services you help with deployment of or some of the ways in which, you know, frontend devs may get value from their team adopting something like Architect? David Thor: Yeah. Well, we work a lot with backend teams to do a lot of microservices-based architecture. People who need more than just databases, but also have a shopping cart service that connects to a payment service that connects to a notification service, and so on and so forth. It's very, very complicated, increasingly so the more relationships that you have. And we help people rationalize it, help people describe it and help people deploy it. David Thor: But on the front-end landscape, there's a lot of common utilities that kind of everyone needs. Auth being a great example, right? Every application that does some form of user centric business logic needs to authenticate that user first and then get a secure token that lets them start interacting with a backend service on their behalf. Something like, OAuthStack, Auth0, Okta, or this open-source thing I talked about, is a very, very common one where people say, "Hey, I've got a front-end up and I've got an API. And that API needs a JWT token to access it first, but I need to get it from this auth service. How do I put all that together?" David Thor: And our system really helps out a lot with that. If I'm building my static site or single page app, and I needed to connect back to an auth service, I can simply set it as a dependency and start routing traffic to it. And whenever someone clicks a button and I can go to that auth service, formulate the OAuth call, and then I'll get a call back with the JWT eventually, and all works out great. David Thor: But the most important benefit is that I didn't need to point to one hosted one somewhere if that was open source, it just deploys with my application. Our team, when we're debugging locally, when we're running locally, every morning we come in and we run our architect deploy. And not only does our application stand up, but the whole auth stack does too. And we get routed to that auth stack. It automatically creates all our credentials, automatically routes the traffic back, and there was no complexity involved to do that. It just was there, it was ready, and I got a private end-to-end environment. Ben: Tell me a bit about your roadmap. What does the next year or so look like for Architect? What are you most excited about? And then maybe also five years, what's the vision? David Thor: In the short term, there's really three pillars of work that our process and our platform automates. The first is continuous delivery, so deployment, not just of my container but of the whole application, everything that I need in order to run it. David Thor: The next is service discovery. That's how do I load balance between things? How do I find all the different replicas of them? How do I make it easier to access them all and make it so all the things can talk to each other safely? David Thor: Then the last is network security. That's actually whitelisting the traffic between the things that are allowed to talk to each other and rejecting all the things that aren't allowed to talk to each other. It's always locked down from day zero as they call it. That's where you'll hear words like zero trust security. David Thor: The thing we want to add is another pillar, and this is really dynamic credentials. One big part of the relationship between microservices is not just whitelisting network traffic, not just finding it, not just applying it, but also authenticating with it. If I need to access a database, I often need to use a name and password to add another layer of security to it. We actually, because that's part of the relationship, can instrument automatic issuance of those credentials that get fulfilled at deploy time. Whereas I could say, "All right, I need to connect to the database, give me the address and make sure I'm whitelisted to access it." We can also say, "Hey, give me the database, make sure I'm whitelisted, access it and give me credentials to access it." And I can just inject those into my application automatically. David Thor: Then every time we deploy, we can not just issue those credentials, we can rotate them, we can change them, we can make them secure. And all we have to do is integrate with the secret manager and a place to put them to have those spit back out. And now all of a sudden, every application asking for a database can get different credentials, secure credentials. I can rotate them on different intervals and cycles. And getting credentials from one service doesn't mean I expose the other. That's really a lot of the enterprise benefit that becomes easier and easier and easier just because you have an inventory of the relationships between things. Ben: There's a common refrain. I mean, I see it on Hacker News and any time folks are sharing opinions that most people don't need microservices. And this is analogous to a lot of what I see people talking about in terms of frontend complexity growing immensely. And so maybe it's just something that developers always complain about is the latest and greatest technology is too complex and not necessary. Ben: But I'm curious as someone who, I imagine you've seen microservices at scale, you work with a lot of other companies that are deploying and managing microservices, what are your thoughts on that? Do most companies need microservices or is it a tool that has a very specific job? How would you advise a new company that's maybe starting to think about their architecture? David Thor: Yeah, it's funny, that's actually the theme of a talk I gave at Developer Week about a month ago. It'll probably come out on video at some point if anyone wants to check it out. But mainly the assertion that I made in that talk was that there's two thirds of the world that knows that they're using microservices for all or part of their application. And then there's the other third of the world that is also using microservices that just doesn't know it. That's the monolithic application or the monolithic architecture is where all your application code is in one pretty application package and gets deployed on one pipeline. David Thor: The reason that's still microservices is because, one, microservices doesn't necessarily mean micro. I know it's in the name, but we just can't use the word services because it means too many things and no one knows what we're talking about. So now microservices mean just different applications and processes. It doesn't necessarily mean that it's small, or it can't otherwise we have no word to use. David Thor: Given that it doesn't have to be small, your application when you wrote a monolithic application, still has things outside of it that it needs, namely a database. I don't know if you could show me a monolithic application at a large scale business that doesn't have a database or some way to process content. It's kind of a necessity. And guess what, someone else wrote the code for that database. That's commercial/open-source software that's just packaged up and available and you depend on it. And someone else is hosting and managing in many cases, but it's still a core dependency. It still needs to be there. David Thor: And so that means I need to make that database. I need to make the credentials. I need to put their credentials somewhere. They need to go into my application. They need to whitelist traffic. All that stuff happens, but it just happens for a very smaller subset of the applications. I just need to do it for the database and for my monolithic application, and I'm done. David Thor: We don't necessarily need to invest as heavily for that architecture because it's five steps, not 500. It's only once you start adding a second application or a third or a 50th or 500th that you can start to see that web increased. Because now five steps is 500,000 steps and it can't possibly be done by a single person. That's really where that complexity comes in. David Thor: And I say that everyone uses microservices because of that, but it's true. You don't necessarily need to invest as sophisticated, continuous delivery or as sophisticated tool sets if the steps can fit on one hand. But you add a second and a third and a fourth, and now you're adding hands to your team. You're adding DevOps engineers, you're adding SREs, you're adding other team members. And in many cases, if the tools are available, it's better to just have them from the start so that that growth happens organically. David Thor: And up until Architect, that has not been true. Now it is true. Now you can just grab it off the shelf and use it, so why not do that today? Even for that React app that just has an API on a database, you already have relationships so you might as well lean into it. Ben: Well, thanks so much, David, for joining. This has been awesome. And I certainly learned a lot about DevOps and architecture and Architect, so very happy to have you on and really appreciate it. David Thor: Awesome. Thanks so much, Ben. Thanks for having me. Brian: Hey, it's Brian again. So it turns out that running a podcast is maybe harder than we thought and so I kind of want to hear from you. I'm genuinely interested in your feedback. We have to think about new topics, new guests. We have to find them. And don't get me wrong, we can do it, but it's a lot easier if everyone else who's listening helps. Brian: If you'd like to suggest a topic or volunteer to be on PodRocket, we'd like to hear from you. You can do that by going to podrocket.logrocket.com/contact-us. The hyphen is next to the delete key if you're curious. If all of that is too long, you can just email me directly, brian@logrocket.com. That'd be great. Also, if you're feeling magnanimous, be sure to like and subscribe to PodRocket. Thank you.