84. Salesforce for Heroku Developers

Chris: At the time, right, I had just come to Salesforce, maybe nine months before we purchased you guys. But I think at the time what we were looking at was how do we go a step further, right? How does Salesforce move further from this business only mindset to a mindset that can actually cater to the professional developer, to the modern developer, who at the time were starting to really, really start to use and adore the features of Heroku. So to me, when the purchase happened, you kind of made complete sense, right? It's like, okay, here's this new development platform that we can use and bring to bear on all these different business problems and other things. And since then, I'm surprised that I haven't seen it come to as much of a fruition as I would have thought early on.

Greg: Yeah. I kind of echo that. On the Heroku side, there was kind of confusion, but there was a lot of excitement as well about sort of the investment opportunities that Salesforce could make into Heroku, and growing the Heroku platform. We saw it as a good way to talk to people that we normally didn't talk to. Because at Heroku, I mean, we talked to developers, right? We talked to Ruby developers, Python developers, all those sorts of people, but we never really engaged with business. So we never were able to expose business to the value of Heroku, or advocate the value of Heroku to business. So there was some thought that perhaps Salesforce could help us with that conversation. Give us that sort of inroad into talking to business folks and explaining the value of Heroku to them and grow the community of folks that use Heroku.

Chris: Yeah. And I think when you consider sort of the Salesforcian origins, we started on that business side, right? Consider back in the day when we were first that upstart making news about getting people to do fake protests and whatnot at other software vendor's conferences. The idea of Salesforce was rooted very strongly in the development should be for anybody. You shouldn't have to bring on all of these developers just to rebuild the same page for the 300th time. It should be easy. It should be quick. And the teams that sells to are sales ops and sales VPs who don't want to use one of the incumbents, right? They want to get out there and they just want to do their own thing and do it quick.

Chris: And doing their own thing, doing it quick, easy customization, traditionally was a thing that developers would push against, right? When you dev, easy, fun, fast, that sort of stuff, what that brings to mind is Microsoft FrontPage, right, from back in the day, or the WYSIWYG editors. And the first thing that that always brings up, is I'm going to hit a limit. And when I hit the limit, everything I just did, I'm going to have to redo. So I thought it made complete sense. We could help her Heroku sort of look and get closer to the business. And make the projects in Heroku, real business drivers. And at the same time, Heroku showed the world that we were real about our attempts to woo developers and to build custom cool stuff on our platform.

Greg: Yeah. I'll echo that FrontPage comment. I made the mistake of looking at the code that FrontPage generated once, probably back in the 90s. And yeah, I didn't know you could do that with HTML. I didn't know you needed that many tags just to center something.

Chris: Dude, back in the day, all you really needed was a blink tag and a marquee tag, and you were web 1.0, top of the chain.

Greg: So from a Heroku user's perspective, I was wondering if you could give me a little education on what exactly is this thing called Salesforce, and why should I perhaps care about it?

Chris: So I'll do it in two ways. The first way I'll do it is I'll give you a bit of a story of my first development cycle on Salesforce, and then I'll sort of frame it with respect to the broader market of developer tools, and how we tend to think. Now caveat to those of you that are out there that are, I guarantee, way better devs than me. I was just a lowly MIS major back in the day. I'm not CS, right? I can code enough to be relatively dangerous, I'd probably say. But I've coded enough to understand sort of a lot of the problems and concerns and issues you run into.

Chris: Now, the first time I developed on Salesforce, when I joined the company 10 years ago, I still remember that first or second day. And I wanted to get to work on this prototyping team. So I did what everybody would do at this stage. I went to my boss, and I said, "Hey, how do I get a server? How do I get provisioned whatever IDs I need? Where are the extra tools for deployment?" Et cetera, et cetera. And I was stunned when he looked at me, and he was like, "I don't know what you're talking about. You don't need that."

Chris: And that worried me because I was like, "Hey, wait. I thought I was here to build some stuff. I'm pretty sure you need that to build some stuff." And he set me up in front of a Salesforce organization, sat me down, and I just clicked the new button for custom code. And I just started writing code, and it just worked. And I had come from a history of building a lot of tiny tools for a startup. I worked for another enterprise software company. So there's a lot of building and stuff. And, oh God, at one point I was using VB.Net. I'm sorry. And I knew what I needed. Right? You needed an IIS server, you needed all this other stuff to stand up to even be able to deliver a webpage to begin with.

Chris: And for Salesforce, you just didn't. You could just do. And not only could you just do, but it was just connected to everything. It just worked. When I wanted an account record it just, okay, I create an account record. It was horribly simplistic, dramatically so. Now if I were to compare that to the rest of the world, I don't think it's that far off from how developers think. It's just we don't really package ourselves in a developer friendly mindset.

Chris: Consider what an infrastructure as a service provides you. Everything is around getting rid of activities you don't want to do. Activities that are commodities, that you're not really defining a differentiation on knowing. Consider Heroku then. Heroku is a level above that infrastructure. Doing a bunch of the infrastructure work you would normally have to have ops teams do so your developers could start working. And instead in Heroku land, no, no, you just start writing your freaking code. Point and click and connect it to your database, and deploy in seconds, right? It's again, it's removing more and more of that commodity work.

Chris: And when I think about what Salesforce brings to the party as a development platform, comparative to Heroku, it's more of that abstraction. It's getting rid of more stuff at a higher tier that I don't want to have to deal with. I worked with a company last year on this video auditioning service that we needed to release for potentially up to millions of folks. We went in there, and "Hey, put this on Heroku. I can wire it with Bucketeer to store the videos, and then we'll store the information in Postgres."

Chris: And they needed to not only build the intake forms, right, but they also needed to have all of the backend stuff. They need to have a production team go through and vet all of these folk, have a workflow pass that information to other people. Secure this, lock it down to ensure other people can get to it. If I had built that all on Heroku, that's dozens and dozens of pages I'm building. It's sharing tables and user tables and implementing off some sort of off library to SSO against their structure and all this other stuff. It's building reports and search, and APIs to connect it to other stuff. It's all of this rote common stuff that every business application is going to ask for.

Chris: And so what we did was we just wired the Heroku form so that we had that scalability across to Salesforce. And then Salesforce provided me the login system, the sharing rules, another database to run against, all of the APIs out of the box, all of the reports and search. All of that common commodity stuff for business application was just done. And to me, that is the value that you should be thinking about from a Heroku standpoint as to why you would wire into Salesforce even if your company wasn't already on Salesforce. I mean, if they're on Salesforce news and sales cloud or service cloud, and I think it's a no brainer for me, it's more of a question of what if we're not yet? Why would I care about a Salesforce platform next to something as powerful as Heroku?

Greg: Yeah. It's that kind of leads into my experience as well. My background is in ops, it's in servers and Linux Kernels and standing up boxes. And in the old days, wheeling racks into rooms and plugging servers into racks, and plugging cables into servers, and then into UPSs and internal base UPSs and all sorts of stuff like that. And infrastructure as a service certainly made that easier. And kind of I had that epiphany that you had when I saw Heroku as a sysadmin or as a devops person, I was like, "Oh, wow. You mean, I don't have to do any of that? I can just start coding." And that was kind of eye opening for me. It made me super excited about starting working at Heroku.

Greg: And a little bit about my background. I actually started in the startup industry, came out of working for one of the largest enterprises in the world, building data centers. And came into the startup world into a competitor for Heroku that had a different vision. They consider themselves sysadmins as a service. And so, you'd open a ticket and they would stand something up for you. And sometimes it would be standing up a box and a rack. Sometimes it'd be standing up infrastructure elsewhere.

Greg: But then moving from that to Heroku, and seeing the automation and just the beauty of the platform underneath all of that, where it was self-healing, it was self-automated, and it just took care of itself, really was eyeopening for me. And it really, really impressed me. I mean, I can see how as a developer, kind of taking that next step of, oh, you mean, I don't have to create a table on a database to keep track of my users. I don't have to figure out how I'm going to salt the password. I don't have to do any of this stuff. That is pretty cool.

Greg: But how could a Heroku developer, say I'm starting a project, and I'm going to need to have people log in and have workflows and stuff like that. How would you go about building that sort of hybrid application?

Chris: I always start with trying to abstract away as much as possible. So always using the platform of essentially least resistance. Now there is some concern, again, like we talked about earlier, like lock in and work arounds, and stuff. Yeah, that's true. But the place I always start is, hey, I don't need to overengineer for five years from now. I need the data. I need the logic. I need the UI. I need it on something.

Chris: And if what I'm doing is very business oriented, like you said, I would start with a Salesforce, right? I tend to look at Heroku as the super power enabler for Salesforce. Now, granted that's because I come from sort of the Salesforce centric view. But hopefully it will be understandable by the devs of Heroku. Heroku can do a ton of stuff, but it is extra work to do comparative to Salesforce in most scenarios like this, right? Hey, I just need a form. I just need to take in some data, show it to some other people, do some searches, and stuff like that. Right? It's basic stuff.

Chris: Those views, those internal authenticated data-driven application types of user stories, those are the Salesforce. It's the bread and butter there. And so an existing Heroku developer who has built some really neat web app or product or something, right, where I highly recommend to my customers when to bring Salesforce into the mix. It's the business side of it. Cool. You've built this really neat thing that rents flying cars or whatever, and pulls in telematics from this and that, and the other thing. And it's this amazing globally available, whatever. And that's cool. That is your secret sauce. And that makes you unique as a company. It's your differentiation.

Chris: All of the other junk, how do you sell this material? How do you service your customers? How you do all that sort of stuff? That's what you use Salesforce for. And we thankfully have a thing that makes that easy in Heroku Connect. That is a major, major, major deal when it comes to working across both. It's that ability to have right tap on both sides, retap on both sides. And to partition that data is huge.

Chris: I was just working with a hotel chain and they ended up not going with us, and that's cool. They had good reasons. But they wanted to do service with us. I wanted them to put their customer information system on Heroku because it had to scale to this consumer grade. Something that Salesforce isn't going to give you the levers and the dials to be able to do super effectively for it. Because that's not what it's built for. I wanted that super power connected to Salesforce. But all of the service desk stuff, all of the entitlements, the SLAs, all that stuff that goes into helping service cloud customers, that stuff, you push it to Salesforce.

Chris: And part of the reason you do that is you're essentially inheriting our development teams. And yeah, there's a lot of stuff around abstracting. And I think, you'll have a lot of really good devs out there then they're like, yeah, that's cool. That stuff sort of rote, but that's what freaking libraries are for. That's why NPM whatever, or bringing my Gemfiles or whatnot. Right? It'll do 90% of that junk. Okay. That's fair. But it's not going to rebuild itself in 10 years, right?

Chris: So one of the things I actually like to push to developers about the value of building on something like Salesforce is one of the advantages we have in abstracting away so much information and so much of the work is we can update it. So, oh, Heartbleed comes out. Cool. You don't care. And Heroku did a great job of making sure people didn't care on that too. Oh, implications are coming that require us to add encryption this stuff. Cool. Well, we just have to do that because we have to do that to allow our products to survive. So therefore your application that only you use, yeah cool, you get it for free. Oh, hey, our UI's looking old in the tooth? I mean, we've had two major UI overhauls in the last 10 years.

Chris: Consider any application that's over 10 years old at your organization. It probably looks like butt. And it didn't look like butt at the time, because everyone was developing, and then we realized 10 years later that day that our standards look like butt. And that's not something that's easy to upgrade across your entire organization. But at Salesforce, because we've abstracted away because we know the scale and the scope of what we have to deal with, we can upgrade everyone's application at the same freaking time. And then you just inherit what our devs and designers have done for you.

Greg: It just comes down to, for each individual use case in a greater use case of use cases, or in a great application, looking at each individual use case in saying, almost probably first off is, is this internal only. And if it is internal, is this something that's going to benefit from having a managed UI that I don't have to worry about that I don't have to build? I don't have to write a line of CSS or HTML to deliver to my internal stakeholders. Can I enable them to use some of the advanced features inside of Salesforce, like reporting that's built in, or dashboards that's built in, or any of that, and just let them go free with the data?

Greg: I think from my perspective, when I learned about Salesforce and sort of kind of saw that light, my big takeaway was, as a Ruby developer, I want to concentrate on problems that are interesting to me. Which is web scale, which is dealing with large amounts of data, which is all of that. I don't want to build a dashboard for a CEO. So piping the data into Salesforce and then letting Salesforce admins build that for me, and manage that for me, and letting Salesforce manage that UI, keep it accessible, keep it fresh, that seems a little bit attractive.

Chris: Yeah. And it's important to note too, that in talking about the differentiation between Salesforce and something like Heroku, we focus a lot on the point and click, right? Oh, it's so easy. Admins can do it. Salespeople can do it. We used to sell it, right, as and, hey, this is the thing your salespeople can manage themselves. You don't need IT.

Chris: But what's important to understand around the Salesforce is the scale and scope of the project you're fighting are big. And we're not just point and click Lego building. There is an extensive amount of code and development that's available to our customers to go beyond whatever our point and click development tools are going to allow you to do.

Chris: So to give you an idea, when you consider development in a sort of data-driven application, such as befit something like Salesforce, generally you care about three bits, right? You care about your data. You care about your logic. You care about your UI. Data, relational data store, kind of straightforward. We have specific query languages, search languages that you can use to pull information out of, as well as ephemeral caches that you can use to speed things up, stuff like that. Logic, so things that power your APIs, things that are sort of your server controllers, scheduled jobs, that sort of thing. We have a Java-like language called Apex. And when I say Java-like, that's a really weird term.

Chris: I guess what I'm trying to say is, Greg, you mentioned Ruby. I'm glad you like Ruby. As soon as I looked at Ruby and Ruby on Rails, I didn't know what I was looking at. The syntax was like I don't know what this Greek is. It was like learning how to program all over again. And I remember feeling that way when I looked at Objective-C. When I went from sort of C and C++, and go from that to Java and then go from that to Apex, it was like nothing. Right? Oh, okay, I can read this. I know what I'm doing.

Chris: So the key about that code though is the code is not there in place of everything else, right? It's not that you use our workflows and our process builders on our flows, and all these neat little point and click tools that I'm using terms no one necessarily knows. It's that you write code to be invoked by that point and click material.

Chris: To make it more real, let's consider that you have some sales process. And at the end of that sales process, you need to do this really complex algorithm and fire off a couple of API messages. Complex algorithm, point and click tools, those aren't usually two things that wire together super well. That said though, the entry criteria to get to that algorithm, all of the preparation, all of the data gathering, all that sort of stuff, that's kind of rote. That's kind of normal stuff. And it's not just normal stuff, but it's stuff that's going to change a ton comparative to a call out, comparative to the complicated algorithms.

Chris: So whereas in a traditional development structure, right, you'd have to write all of that in code. In Salesforce, what you do is you use those point and click builders to sort of decide, hey, if it's over this amount or if it triggers this, or if this, then that, and go through your logic flow, then call this method, and pass out all of these input parameters. And so all of a sudden, Greg, the code you've written is not the 100% of this complicated thing, it's the 10% that's actually unique to you. And then you don't have to go back. You don't have to mess with it. The admins can go and change it. Or if you're the admin and you're the developer, you can go back and change it. Because instead of realizing that you have to go back and write in that new code, you just change a couple of variables on the way in.

Chris: And I guess the way I like to put that is I've always felt that the worst programmer is yourself six months ago. In that, you built it, you built it quick, you were on a timeline. So of course you didn't comment it as effectively as you could have. And X equals whatever. You're like, I don't know what X is supposed to be. And you spend a good couple of hours trying to remember what the hell you were thinking, as well as feeling that shame about how bad your earlier code was before you actually get any changes done. And when you do this, it minimizes the amount of your own code or someone else's code you're going to have to go back through and hack through. Right? And so that becomes an immediate speed add, value add for a developer.

Greg: Yeah. I always say that two week ago me is twice as smart as today me. Because I read my two week ago code and I'm like, wow, I was really smart because I have no idea what I was doing.

Chris: Oh, I always feel the worst. I read two week ago code and I go, that doesn't even go there? Why is this even working? And then I rewrite the whole damn thing because I would be so ashamed as to what I wrote.

Greg: For sure. So, we talked about hybrid apps, we've talked about why Salesforce and Heroku, what parts of Salesforce do you see a Heroku developer utilizing and really getting a lot of value out of?

Chris: I think primarily when you consider a lot of the Heroku devs who would be first looking at the foray into Salesforce, usually it is through the app lens. It's not through the platform lens. It is, hey, we need a thing to do service guys because our product's working and we're selling. But now people are mad that they can only email this one random email to get any help. And that the five people or two people we have looking at that email need something to actually keep track of all of the stuff coming in. Right?

Chris: And usually at that time what we tend to see is, okay, cool, a startup or a small firm will run out and grab seven different things. Each of the individual departments within the company will run out and grab their own thing and mash them all together. And it's this crazy disconnected set of silos. And I think the first place you guys should start with Salesforce is understanding your product's built on Heroku. And we have built Heroku with this pipe across to the business side.

Chris: So marketing, sales, service, commerce, whether it's B2B or B2C, right, CPQ, all of the gnarly stuff that you start to grow up into needing, we have it. It's there. It's ready to go. And the first thing you should be considering is when you start to get your business to that point where you have to care about the business, where it's not just the fact that you have a super cool product, and where things are starting to spiral out of control, that's when you should consider Salesforce.

Greg: That makes perfect sense. And that's sort of my idea as well, is a replacement for point solution X, piping it into an integrated system where if you start with service, like your example. We have emails coming in. We need to respond to them. We want to turn them into tickets. Maybe we want to start watching a social media. Having that data go into one place that then we can pivot into, oh, and by the way, our execs want dashboards on this. And our execs want to combine that with sales dashboards. So we get it all in one place. And we can actually have that to, use a trite term, that 360 degree view of the customer.

Chris: Yeah. And I'm inside the mothership, and I'm stunned on a three monthly, on a quarterly basis, as to the stuff we do. It's difficult for me to keep track of it all. And even if we just look at service, sure, taking in emails, having a view for cases and a view for your agent wiring into an SSO system that uses standards. That's not terrible. It's not really that hard.

Chris: Handling things like social media integration for 17 different vendors, or 50 different vendors, or whatever number of vendors you got to deal with, right? Adding on SMS hooks to it where you're tying multiple SMSs to the same case and all this other stuff. Handling things like phone and CTI popping and all that sort of stuff. Everything starts to snowball. It gets bigger and bigger and bigger as to what people expect from you as a company.

Chris: That snowball, that's what Salesforce does super, super freaking well. And it continues to have to do it super well Because otherwise we wouldn't be competitive. So as a developer, it's like, hey, yeah, I can go out and I can build this thing for day one. And you know what? It's probably going to be a 100% of what I need day one. And you might look at Salesforce. And Salesforce, hey, it's a packaged product, it's a packaged application platform. It may only satisfy 75% or 80%. It may not look the way you want. It may require some workarounds. I'll be straight, that might be a thing that you run into.

Chris: But that's day one. Day 90, day 180, day 360, as we continue out there, we will still continue to add features, add products, add things to it that you will be able to take advantage of. If you develop it yourself, that's all on you. And now you're putting together scrum teams and explorations as to, hey, do we take the time to build this? How do we build this? We've never built that before. Well okay. Well, let's talk to the business. Business, do you want to do this? You don't know because you haven't dealt with that before. Okay, cool. It creates all of these extra conversations you don't need to have. And we make that sort of future proofing a lot simpler.

Chris: And I keep bringing it back to this. This is not that dissimilar to how you think about it in Heroku. Sure, you can run on an infrastructure and set up your own load balancing system and your own notification system and your own custom stuff to be able to scale up and scale down and scale out all these different systems for you on the fly. And all these different runtimes are all hooked into all this other stuff. And you may have a product that requires that level of tuning.

Chris: And if you do, bully for you. That's awesome. Continue doing what you do. If that's not going to give you a value prop, then you would obviously use something like Heroku. Because that's all junk you don't want to have to... And I say junk, sorry, ops guys. I don't mean what you do is junk. I just mean it's work. It's work as a developer. I don't want to do it. It's not what I know. I just want to write code and I want to make it better. Same general idea. Right? If you hand that to another company whose lifeblood depends on them delivering a top of line product in that realm, it just saves you the heartache and the pain and the effort of having to essentially do the same thing.

Greg: Yeah. I saw a tweet a while ago from somebody who said, and I'm so totally paraphrasing from memory, but as I said, like in 2010, 2012, they were using Heroku. Then they went to NASA and they built a platform as a service. They left NASA, and now they're back to using Heroku again.

Chris: I mean, throwing Salesforce to the side, I've talked to a number of customers who tell me how amazing their teams are on infrastructure as a service. Some of them show me what they built. Like wow, God. You are breaking new ground. This is nuts. And some of them show me what they built. And it's impressive, but it's also like, cool. But you know you didn't need to do any of this, right? You go to that purple site, this is actually all done. This is table stakes guys. Why have you built your own? And a lot of times they get back the answer. "I don't know, we have the devs, right? We have the ops. Might as well do it."

Greg: So that earlier question, maybe I should rephrase it. What should Heroku developers learn, and what order do you think they should learn it in, about Salesforce, they'll start thinking about these hybrid type of applications where they don't have to worry about that kind of admin backend stuff.

Chris: It's a complicated question to answer. So I mean, technologically, what do I need to learn? Well, UI is built on JavaScript using web components. We're one of the people in the web component consortium or whatever it's called, we're moving more and more to these open standards. Which is, in my opinion, freaking great. So that's really easy to do. Backend as this Apex, Java-like language. So if you know pretty much any language, right, you will roll into that fairly easily.

Chris: The difficult thing with learning Salesforce is it is all intertwined. You're going to have to sort of start a bit of a journey. I think the first places to learn would be how do I integrate with it? So understand the APIs, understand your options around, oh, maybe I want to do a Pub/Sub model to understand what's going on in Salesforce. That's a good, probably first wave.

Chris: And then the second becomes, okay, cool, how do I build custom stuff on Salesforce? And for that, start with the point and click stuff. Someone came up with this really cool idea at Salesforce. And then we turned it into Trailhead. As a grumpy dev, I'm going to be straight with you. There's a lot of cartoons, and it may seem like it's not content heavy, but it's not true. It's actually fairly content dense. You just have to find the right material on it. So that can be a really good place to go. And for free, you can spin up instances of Salesforce, go to town learning and playing around and blow them up and then spin them back down, and not care about it. You can learn what development looks like, what delivery looks like, what all of the things you're familiar with look like.

Chris: But don't short change the point and click stuff. Too many times I see experienced devs jump right into Apex, jump right into Lightning. And then they've customized the hell out of their instance. And all of a sudden they are sort of out of phase with our new changes and our new products. And the reason is they essentially just turned Salesforce into a server. And you don't want to do that. You want to utilize any of the point and click stuff, any of the easy stuff, wherever possible. Because it'll keep you in line with us better because we have to service that. And honestly, it'll just make your lives easier. So that would be where I'd start right here, hit up, Trailhead, learn about us in general, learn about some of the point and click tools. Try building some stuff.

Greg: I've definitely utilized Trailhead quite a bit to kind of start to skill up and start to take that Salesforce journey. Is there anything else you want to touch on, Chris, before we wrap up?

Chris: I think that it's very common for us as developers to look at anything pre-packaged, abstracted with a side eye, right, with that feeling that there's a catch. That there's something that's going to make my life harder by going this way. That it's going to make me irrelevant. We have to learn how to fight that. Otherwise we're not going to be able to take advantage of certain features and certain platforms and certain technologies that can honestly do a lot of good for us.

Chris: Now I've been with this company for a long time. We're not perfect for everything. Legit, we're not. Almost every single customer I talk to, "Cool. This stuff you want to do? Yep. We can help you out with that. Okay. That'll take custom. Wait, you want to do what now? Nah, nah. That's just not going to work. Not going to work." And that's okay. Right? Because we're very good at what we're doing. We are a chainsaw compared to a scalpel. You're not going to do heart surgery with us. And I think that's the thing to keep in mind.

Chris: And so I would say to all the folk out there, keep an open mind with this. Recognize that there's a lot of stuff you do that you might not like doing. And if something like Salesforce, and it doesn't have to be Salesforce, I'd like it to be Salesforce because I'm biased. Right? They pay my bills. But you want to use something else that's out there that does the same thing, that abstracts away some of the same stuff and you feel it's better for whatever your use case is, okay. Go with it.

Chris: Don't be afraid of it because it doesn't reduce your value or your importance. I find instead what it'll do is it'll target your value and your important to the things that matter more, to the things that need your intelligent view and your experience, your development chops. Greg, like you were talking about, right, in terms of, oh, I want to scale these systems out and be able to do all this crazy stuff that's breaking the bounds of whatnot. That's where I would prefer you guys and gals all building. Not on, hey, we want to add this table to our indexer, and we want to set up this different type of sharing model for all this other stuff. And we need you to code all it. I want everyone out there doing the cool stuff, not the other boring rote stuff that I think that we do really, really well.

Greg: That's echoed through the industry as well. And through history, the history of the industry, you look at it, right? Back in the day, we had to buy servers and rack them and start there before we could even write a line of code. Every time we add an abstraction layer on, we accelerate what we can do. We amplify what we can do. We multiply what we can do. So we can get more done faster because we're abstracting away all of the crud that we don't really care about. All of the components that are commodity. That it's a server, who cares if it's a rack, which rack it's in, or anything like that, unless you do. Unless you're building satellites or something and you need totally 100% real time Linux Kernels, or some sort of wild stuff.

Greg: But for a vast majority of the people, there's levels of abstraction. And getting over that, I didn't build it so why should I use it mentality can really accelerate development, and allow you to build more cool things. And I think that's something that infrastructure as a service has fought against on-premises, that platform as a service has fought against, infrastructure as a service, and the Salesforce, or software as a service, has fought against platform as a service and infrastructure as a service. So it's an interesting journey we're on as a industry. And I'm super excited to see what comes next.

Chris: I am too. If anything is a constant here, it's change, and it's really impressive to see the sheer number of people and executives and folk that are in the trenches, that are in our engineering team actually keeping the servers running and churning, and are in our product teams and building out the cool stuff. Everyone is focused on, hey, how do we make this better? How do we improve this? How do we make it the next version, right? How do we stay ahead of stuff?

Chris: And that's a full time job for a global team of people here. And it's really, really neat to see the focus on it. And it's really cool when I talk to customers, and there's a bit of that panic, right? It's like they're trying to essentially do the same thing. It's like, no, you don't have to though, for this chunk of your business, for that chunk in your business, let us do that for you.

Chris: And if you disagree with us, cool, build your own thing with us, or build your own thing and integrate with us. We're not going to get mad. That's totally all right. But you're sort of outsourcing that, and it can be really valuable. So I guess to everyone out there who was on Heroku, was using Heroku, I'd definitely say, you might not agree with me. You might not trust me, right, because I'm biased. It's fine. Talk to your Heroku folk. Ask them about it. Ask them to give you the honesty. Ask them to connect you with tech people on the Salesforce side. Folk like me. We'll tell you. We'll hear out what you're trying to do. And we'll be straight with you. Hey, this will work. Hey, this won't work.

Chris: Half of my job at this point is talking to customers and trying to see, okay, how feasible is this solution? Can we actually accomplish this? Does this push limits in certain ways? What should we be concerned about? How does this integrate with your larger architecture? We love those conversations. And as you can tell, that's not a CRM conversation, right? That's an architecture conversation. That's a much larger technological thing. Customers that get the most value out of Salesforce and Heroku are the ones that work with us as sort of technology partners in it. And if this podcast can get more of you all to be out there and go, hey, we'll try it and we'll see what's up, cool. Totally worth it. And if not, then I got to at least hang out with Greg for awhile.

Greg: Absolutely. So thank you so much for your time, Chris. I really appreciate it. And we'll have to see about doing this again. Thanks.