Heroku and the Twelve-Factor App with Vish Abrams

0:00Heroku is a cloud platform as a service that enables developers to build, deploy, and scale applications. It was founded in 2007 and was acquired by Salesforce in 2010. The platform supports multiple programming languages, including.NET, Ruby, Python, Node.js, and Java, and has features such as automated scaling, database monitoring tools, and a streamlined deployment workflow. Vish Abrams is the chief architect at Heroku and previously worked at Oracle and NASA, among other organizations. He joins the show to talk about the history of Heroku, its role within Salesforce, open sourcing the 12-factor manifesto, the long-standing challenge of credentials management, and much more.

0:43This episode is hosted by Sean Falconer. Check the show notes for more information on Sean's work and where to find him.

1:02Vish, welcome to the show. Thank you. Awesome. Well, nice to meet you. I'm glad you're here. So you're the chief architect at Heroku. How did you end up at Salesforce? I joined Salesforce slash Heroku about six years ago. Formerly, I was at Oracle where I was working on cloud computing and AI, helping them build their public cloud. And I joined because I've always had a deep love for Heroku. In fact, my early days of software engineering, I was working at NASA where we were trying to replicate the Heroku platform for an internal project at NASA. I would suspect like, because Heroku, when I think about it, it was such a pioneer when it came to Cloud Platform as a service, like the whole Git push to Heroku deployment.

1:46Like there's a whole generation of engineers that went through that. That was like a really simple idea, but like super transformative in terms of how I think it's changed. You know, I-Pass and also like expectations about deployment. now that Heroku has been part of Salesforce for the past 14 years or so. What are some of the big changes that have happened to Heroku during that time? Well, it's been quite an adventure. I mean, I feel like when Salesforce first bought Heroku, they didn't really know what they wanted to do with it. It was kind of an understanding that developers were really important.

2:19Force.com was relatively recent, and they were really trying to figure out how to appeal to developers. and they saw Heroku and said, well, they're doing really cool stuff. If you think about when Heroku was founded, it was sort of in the timeframe where in order to be a developer, you had to also be an operator. You had to be a Linux admin. You had to understand how to spin up a VPS and do a lot of work. And the whole pitch of Heroku was, hey, what if you didn't have to worry about any of that stuff? And so Heroku went through a period where internally it sort of just grew fairly independently for a long time.

2:55massively grew in revenue and users and was very successful, but it sort of sat kind of independently from Salesforce for a lot of its life. A few years back around the time I joined was part of a big effort to bring Heroku closer into Salesforce and to start using Heroku internally a lot more. Over time, what's happened is Heroku has become, Salesforce has become the largest customer of Heroku. In fact, we're used all across Salesforce for internal projects from business technology. We're behind Trailhead, which is the Salesforce education platform. So it's really become sort of a linchpin of all the internal systems at Salesforce and been able to grow in terms of how it's appealed to customers as well.

3:36Are there certain types of projects that aren't the right fit for Hoku? Yeah, I think basically projects where companies don't want to spend a lot of investment in building out a platform or operations team where they want to leverage the advantage that Heroku gives you in terms of being able to just focus on business logic and development. So we find that application teams that don't have a lot of, say, platform expertise, cloud expertise, or even Kubernetes expertise, for example, derive a lot of benefit out of Heroku. I had a pretty interesting story talking to a customer who said, you know, I build up a Kubernetes platform and my best developer spends all his time maintaining that platform.

4:18So he doesn't really get any value out of the most senior developer on his team because that developer is tasked with supporting the operations of the system. And I think that's where you really start to see the value of Heroku is when you don't have to give your best engineers over to the platform side and you can have them working on the business logic and the application itself. And then I think, I believe at KubeCon this past March, it was announced that Heroku would be replatforming onto Kubernetes. Like what's the status of that project? Yeah. In fact, we just took that project to pilot.

4:51So we call it our fur platform. So Heroku traditionally has named their platforms after trees. So the first platform long, long ago was called Aspen and then we went bamboo, cedar. And we've been on the cedar platform for a long time. There was some D and E in there with various starts and stops that we don't need to get into the details of, but the new platform is called FUR. So leaning back into that, the F name for our next generation platform. So that is a replatforming of the Roku experience on top of Kubernetes. So deriving a lot of the value of the cloud standards, cloud native standards, specifically like open container initiative images, cloud native build packs, open telemetry, all the real underlying pieces of value that Kubernetes offers, but providing the same simple user experience that Heroku is known for.

5:39So basically, as a customer of that, I'm getting the value of essentially containerization, scalability of Kubernetes, but I don't have to manage it myself. Exactly. Yeah. So I mean, one way to think about it is sort of like an easy button for Kubernetes. Okay. In terms of where Salesforce is in the world, What is their continued interest, I guess, in something like Heroku? In some ways, at least as an outsider, they seem not that related, I guess, as products. Yeah. Well, you may have seen this big shift towards agents and AI in Salesforce recently. Agent Force is the big new hot thing, right?

6:16And the place that Heroku has sat in the Salesforce ecosystem has been essentially when you need to get a little bit lower level and extend the capabilities of the platform. That's where we've had the most success. We have a product called Salesforce Connect, which allows you to sync your Salesforce data out into an external data store to serve it at sort of high volume for customer facing applications, et cetera. So we tend to fit really well as ways to extend the platform when you need to get down to a little bit lower level. And I think that's going to continue to be the case, especially as we get into agents and AI development.

6:49There's edges where the out-of-the-box solution isn't going to solve all the problems and you need to start extending it. And that's where Heroku has been super valuable in the Salesforce ecosystem. Now, we also have a lot of other customers that aren't necessarily customers of the rest of Salesforce that just use this as a really great platform as a service as well. And so when we look at our customer landscape, we kind of divide it up into different segments of here's more customers that are using the other Salesforce and are trying to extend Salesforce products and customers that are just using us as more of a platform as a service and building all of their systems on Heroku itself.

7:24Yeah. I mean, back to your first point or in terms of like certain use cases where you need to extend the sort of default functionality, I think that's certainly very, very true and relevant in the early days of abstraction, which we are very much in when it comes to like AI. Like, I don't think we know for sure, what the proper abstractions are for building agents or doing even things like RAG or whatever you're doing with your sort of Gen AI project. It's very early days. So you're going to probably end up for doing something at production at scale for like enterprise, a lot of like bespoke work that's going to be very customized to whatever specific problem you're trying to solve.

8:02Yeah, I agree. I mean, I look at it, when I think back about the days of Heroku, we're in a transition period very similarly to where we were when Heroku was founded. We were just starting into web development, building stuff, rapid development, agile development were all very new and people didn't really know how to build things. There was a lot of experimentation and I think we're in the same place with AI right now where there's going to be a lot of trying stuff out, gluing things together and having an easy place to do that is really what Heroku is about. So we fit in really well in these kinds of transition periods.

8:35Yeah, absolutely. Cool. So I want to talk about the 12-factor app methodology, kind of taking this in a different direction. But for those that are unfamiliar with this framework, can you provide a bit of an overview? Yeah, sure. So the 12-factor app manifest or methodology was written about 2010, 2011 by Adam Wiggins, who was one of the co-founders of Heroku. And it was really his attempt to distill down the essential principles that an application developer needs to think about in order to build an application that is easy to scale and grow as needs change. And it has become sort of a go-to manifesto for everyone who's building web applications, cloud native applications, to kind of remember the principles that help make those applications easy to run.

9:23Given that it was proposed in 2011, has it changed much since then? So surprisingly, not a lot has changed. If you go back to the original principles, so it's 12 factors or principles. So for things like dev prod parity, having a single code base, separating your config from code. So those types of principles, a lot of them are still super relevant. We've done some pretty extensive research and thinking about which principles we'd want to change, which principles need to be updated. And the essential essence of the principles are still pretty much the same. There are a few places where the world has moved on a little bit where either the technology that was in use before is no longer relevant, but a lot of the changes are just in terms of the examples.

10:04It's referencing, the manifesto is referencing application or libraries that don't really exist anymore. And a lot of the principles stay the same. There are a few areas that we're looking to actually improve things or change things, but they're pretty few and far between actually. What are a few of the challenges, I guess, that organizations run into with running applications at scale? And how do those things kind of map to these principles? Yeah, so looking at the journey of people in building applications, there's kind of different tiers that you go through as you start out. When you're dealing with a single application, the main thing that you're trying to worry about is how does that application grow as demand increases, right?

10:46So I might start originally just running one copy of the application, and then eventually I need to sort of horizontally scale and run multiple copies. And so the first part of the manifesto is really about how you build your application in a way that prepares you for that sort of stateless scale out type of deployment. So things like separating your stateful services into backing services that can be scaled independently so that your application tier can scale out, being fast to start up and shut down. And then it's about development principles of as the application changes over time and you need to make updates, how are you going to do that in a way that makes it easy to deploy new versions, to be part of a continuous integration and delivery pipeline and things like that.

11:25So that's the early phase. And then as you start to push up against the boundaries of the 12-factor application is when you start getting into things like, okay, multiple applications, microservices, dealing with secrets at scale, having to deal with security incidents and rotating those credentials and things like that. So your needs and concerns start to change as you grow bigger. And I think 12 factor really nailed the first part of that story, how you go from zero to one. And then when it goes from one to 10, it needs some extension. And what about things like consistency, reproducibility across like dev environments?

12:02Is that part of the framework as well? Yeah, absolutely. So one of the principles is dev prod parity, which is essentially that you should be using the same services in development and staging as you are in production. That is kind of an obvious one these days, I feel. But in the time when it was written, people were doing all sorts of very different versions of things when you're running locally versus running in production. And that, as we've all experienced, leads to challenges. It's funny how many of the principles have kind of become common knowledge over time since they were written and sort of the obvious thing to do.

12:37Yeah. That can get complicated though, too, of like mirroring your prod environment, especially if your dev environment's on like a local machine from a resourcing and compute perspective, or even if there's like specific data you need and things like that. So how do people typically try to deal with those issues? Yeah, it can be. And actually that's one of the areas where we're looking to extend the factors a little bit. So it especially gets difficult when you're talking about sets of microservices and you're developing one of those microservices and you want to be able to run copies of the rest of them as they would run in production.

13:07This is something that much of Heroku is built on Heroku. And so this is something we run into when we're, for example, developing our API server. So our API server has a component that's an identity server, an API server, a proxy. So there's a bunch of different pieces and replicating an environment for development that has some of those pieces that you're working on that you can iterate on quickly, whereas other pieces are running sort of in a shared environment that you might be working with other developers on. And those types of things can be challenging. Some of the principles that you start with are making sure that, for example, you're using the same version of a database locally as you are when you're running a production.

13:47So rather than an old practice might be something like, OK, well, I'm just going to use an in-memory SQL database for my local development. And then when I push to production, I'm going to be using Postgres or MySQL or something like that. And one of the issues you run into is that works up to a point and then you run into weird edge cases where things start to break. And so it's much better if you can run locally the same version of the database that you're running remotely and things like that. One of the ways that we simplify this in the 12-Factor Manifesto is to talk about stateful applications being backing services that are exposed through config.

14:21So the idea here is that you have a production environment, you have a staging environment, you have a local environment. and they're all talking to the database by referring to a connection that's in the environment, like database URL, that can be changed per environment independently. So they're all talking to the same version and type of database, but they're not all talking to the same database because you don't want to be doing development against your production database. So having those proper interfaces between stateful and stateless services was one of the ways that it helps you sort of prepare for that kind of development versus production.

14:53Okay, got it. How has 12Factor influenced the design of cloud applications even outside of the Heroku ecosystem? Well, a lot of the principles have actually, let me back up a little bit. Heroku was created before things like Docker existed. So the containerization that we used at the time was custom containerization, but it pioneered the idea of what we call the dyno, which was essentially a primordial container, you can think of it. A lot of the way that configuration and config maps work in Kubernetes were sort of modeled after Heroku. The way that there was an open service broker project that came out of the way that Heroku models add-ons and backing services.

15:32So a lot of the way that applications are built and the way that they're separated and defined as containers, different containers, having a build process, actually came from the principles of the 12-factor app. In fact, when I've started talking about 12-Factor App in public at KubeCon recently, a lot of people are surprised to even find out that it was written by Heroku. It's become such a sort of well-understood way of building applications that's influenced the landscape that people don't even realize that it was originally a Heroku-led document. So we've talked a little bit about how containerization has influenced the direction Heroku is going.

16:08What about these types of trends like containerization and infrastructure as a service, serverless, things that didn't exist when a lot of the 12 factor was written? It was essentially, have they impacted the original manifesto at all? Well, the original manifesto has not been changed since it was written, which is one of the reasons that we're updating it now. But it has definitely impacted how we're thinking about the rewrite, without a doubt. And one of the things that I think has become clear is that the thing that the original manifesto got right is it really focused on the application developer and how an application developer has to think about their code and their deployment of their application.

16:50When you look at a lot of what's come afterwards, so the Kubernetes landscape, it really is focusing on how to build a platform and not how to talk to an application developer. So when you go to KubeCon and experience the tracks, a lot of times the developer experience for an application developer is not the main focus. And so many times developers that end up using the platforms that are built by the platform teams have a very difficult time because the level of abstraction is incorrect. Constantly hear stories about platform team built this great platform and then gave the developers a Kubernetes API and said, here, go for it.

17:27and what the developer was looking for is more of a Heroku-like experience where I have my code and I push it and then it all just happens like magic, right? And even the design of Docker and Docker files really focused on, okay, what if we took this containerization thing and did a DevOps slash platform lens? What can you do with a container? And it's a very different place that you end up when you go in with that view versus when you go in looking at it, how a developer would think about these things, how an application developer would think about it. And so when we look at the updates, what we're trying to do is go back to that original view of like, okay, what if you had a lens on Kubernetes and platforms from an application developer's perspective?

18:08What would that look like? And then defining sort of the interface on both sides between the platform and the application so that it serves both users much better than many of these platforms do today. In terms of going back and refreshing this and making these updates, what is ultimately the goal with putting time and effort into prioritizing some of this stuff? I think there's a couple of things. One of the goals is just to remind people that Heroku is still around and thinking about making their lives easier. I think there's a memory of Heroku being a – people have fond memories of what it was like to run stuff on Heroku.

18:45And they think back, oh, back in the early 2010s, I was running stuff on Heroku and it was so easy. But now I have all of these complex things I have to think about, right? Now I have to think about my container orchestration and Terraform and Helm charts. And there's all of these new concerns. And there's this fond memory of Heroku. And so one of the goals of updating is just reminding people, hey, you know, we're in a new world. There's new technology, but we can still have that same simplicity. If we go back to the fundamental principles, we can still find that same simplicity and provide an experience that really is like the magic that people remembered.

19:19So it's bringing in that modern development approach, but then layering back on the simplicity of the original manifesto. And I think we can find that balance. In addition, I think there's other goals, which is there are certain areas around the edges of application development that are still really hard. And the only way for them to get easier is for a bunch of application and framework and platform developers to work together on creating common solutions. So one example of this that we've run into in Heroku is the complexity of dealing with credentials at scale, especially long-lived credentials.

19:54And I think there's a best practice that's evolved around, okay, well, you put your credentials in something like Vault from HashiCorp that'll help you manage sets of credentials. But the real solution here is to move away from long-lived credentials. And that really requires application developers to understand something like workload identity, where you can have a short-lived credential to authenticate to things. and then application developers and frameworks and platforms collaborating on making it super easy to use those things. And so there are some areas where we can really move the industry forward, but it's going to require some excitement and collaboration from a bunch of different groups.

20:32And 12 Factor was a way for us to do that in the early days, and I think it's a way for us to do that again. Yeah, I mean, that's interesting because I think one of the things that's happened over the last 14 years as well has been since the framework originally came out was it's also been the rise of the API. Everything essentially has an API and we're building, we're really interconnecting a lot of times between APIs, either internally or externally. So we live in very much more in a world of essentially credentialing all the time, essentially, in order to just stitch these things together. Yeah.

21:04And I think what you end up with, especially at scale, is hundreds or even thousands of unique credentials that you have to deal with. And as soon as you have a security incident, that becomes a huge pain. So it's much nicer if you can minimize the number of credentials. Another area is around telemetry. I mean, we kind of have standards that are coming around about how to do telemetry, but the implementation of those standards across platforms from different application developers are all bespoke. And we would all benefit from having more consistent ways of doing that. The industry is moving forward.

21:37Open telemetry is a big new project that has garnered a lot of attention. And it's really connecting those pieces together into the platform and application developers so that there's sort of one consistent story for how you do things like application metrics and traces. The original manifesto focused on, well, you throw your logs to standard out and then it goes to some backend system and you don't have to worry about it. And I think we need something a little bit more robust than that for the current world. As part of this update, another thing that you've done recently is open source, the 12 factor.

22:08So I guess what is the significance of open sourcing? Is that you want to essentially update and continue to build this as a community-led project? Yeah. So the intention here is everybody loves 12-factor. There's a lot of appreciation for it in the community, but we don't want it to be something that's just Heroku telling people what to do. It should be something that community is saying, these are the things that we agree on are the right practices. and using that as a platform to sort of influence other development communities and framework communities, platform communities to sort of build things collaboratively.

22:42We think that's the right way to go. And the only way for us to do that is to expand the control of it to a community-led project. So when we say open source, usually that refers to source code. And as it stands right now, it's more like documentation. So we use the CC BY license. But we do expect bits of code and software to exist in the fringes around the manifesto. So, for example, we might have a local CLI that helps you implement the principles of a 12-factor platform locally so that you are working in a similar environment to how you would be if you're on a platform. Or we might have defined different standards around 12-factor where some don't exist in the community already just to make it easier for us to work together on things.

23:30So there may be code at some point in the future. Right now, it's essentially just documentation at the moment. Were there any challenges with or concerns, I guess, with making the framework more public and more of a community-led thing? Yeah, I think there were. I mean, primarily, we spent months and months investigating it ourselves and developing an opinion about what does need to be updated and where should it go. And as always, when you take something to the community, not everybody in the community is going to agree with you. So the concern, of course, is like we have these great ideas and we bring it to the community and they take it in a totally different direction that doesn't really align with where Heroku is going.

24:08That would be a big miss if that happened. But we felt pretty confident that the ideas and the direction we wanted to go are solid. And what we did is we started out by inviting some community, some trusted sort of community members to come in and review it and see if they had the same opinions and kind of develop a collaborative start, which resulted in kind of an initial maintainer list that's broader than just Heroku that has people from different companies and the community as a whole that are interested in it. And we've been actually quite surprised with the interest and the attention that we've gotten so far.