Episode #64: From ColdFusion to Serverless with Raymond Camden

About Raymond Camden
Raymond Camden is Lead Developer Evangelist at HERE Technologies. He’s an expert in web standards, Node, and serverless with a passion for teaching others. He has written about, and presented on, technologies for the past fifteen years, and enjoys helping others become passionate about the web as well. Ray is a prolific writer, as evident from his blog content as well as in industry publications. He has authored (and contributed to) multiple books over the years, such as his book Developing Serverless Applications, and speaks at conferences around the world. 

• Twitter: twitter.com/raymondcamden
• Blog: www.raymondcamden.com/
• HERE Technologies: www.here.com/

Watch this episode on YouTube: https://youtu.be/2I3nNsU6HSs

Transcript

Jeremy: Hi, everyone. I'm Jeremy Daly and this is Serverless Chats. Today, I'm chatting with Raymond Camden. Hey, Ray. Thanks for joining me.

Ray: Thank you for having me.

Jeremy: So, you are a Lead Developer Evangelist at HERE Technologies. Why don't you tell the listeners a little bit about your background and what HERE Technologies does?

Ray: Sure. I'll start with HERE. So, we do everything involving location. So, we have a mapping platform. We have APIs for routing, geocoding, reverse geocoding, anything that a developer may need in regards to location or mapping we have technologies and tools for. People are free to reach out to me later to talk to me about it.

Jeremy: Awesome. And your background?

Ray: Let's see. I've been in web development since '93 or so. So, I've been around for a while. I spent a long time doing back end work. Last decade or so, more front end work. I've been involved in developer relations unofficially for most of that time, because I like to share, I like to give presentations and stuff like that. Officially in DevRel for six or seven years or so.

Jeremy: Awesome. All right. So, if people don't know you, if anybody was ever involved in the ColdFusion community, you are a legend in the ColdFusion community. I was looking through my old books trying to find some of the old books that you had written, I think ColdFusion MX 7. You and Ben Forta had so much material out there. I was a huge fan and always fall into stuff that you guys were doing back then. So, I'm super excited to have you on the show.

What was kind of funny is I was a ColdFusion guy way, way back in the day, as well. I had a big customer, it was a college that was doing everything ColdFusion. So, I learned ColdFusion just for that customer and I actually fell in love with ColdFusion. I thought it was a great language, it was super easy to use, all kinds of features, but I eventually got away from that and I really wasn't following what you were doing anymore.

Then, all of a sudden, I come around maybe two years ago and I see you're working on serverless stuff. So, I would love to get that perspective of how you went from ColdFusion to serverless.

Ray: Absolutely. So, I began actually with Perl CGI scripts back in the old days where there were no real defined roles. I would do everything HTML, Photoshop work, and back end work. I discovered pretty quickly that I don't make things pretty. I enjoyed the back end work because back then, having a web page be dynamic was a big deal. I can remember at college finding some random website that would pick three tarot cards and it was random. I was amazed by that. It would take five minutes to load the images. I would sit there and just reload. So, I kind of migrated there.

I got into ColdFusion because I had been doing Perl CGIs for a while, but we had a client who had a SQL Server system. I knew that Perl could talk to it, but also knew that it wouldn't be fun to write that code and just randomly discovered that ColdFusion supposedly made working with SQL Server and Access, et cetera, it made that easy. That was right. I kind of fell in love and spent probably a good 15 years doing just ColdFusion stuff.

Jeremy: Yeah. No. I mean, it's funny because I have, I think, pretty much the same exact background. I started in college with Perl and CGI. Then, I went to PHP and MySQL and sort of that stuff, but then moved over to ColdFusion. I spent many, many, many years with ColdFusion until I moved back to PHP.

So, when you got to the end of that ColdFusion era, what was the next step after you sort of were done with ColdFusion?

Ray: So, I remember when JavaScript came in, but it quickly became hard to use. You know the whole browser war type thing?

Jeremy: Yeah.

Ray: So, not only with me not being able to design well, the other reason I didn't like doing the front end work because it was such a pain to make everything compatible with IE4 and Netscape 4, et cetera, so working on the back end, somebody would just hand me HTML and I'd make it dynamic.

What got me kind of looking back is I remember I was bored at work. Ajax had been around. Gmail, I think, had just come out, so the whole Web 2.0 thing was fresh in people's minds. I had only done a tiny bit of JavaScript over the years. I thought, "Let me look at it some more," now that supposedly things are a little bit better. And I found out that, yeah, things were a bit better. Browser dev tools were around.

And so, I just started doing more work on the client side and I began to realize that having the app server there, primarily because browsers were so horrible, wasn't necessarily the case anymore. There was a lot more that I could do on the front end and without an app server.

Jeremy: Yeah. No. I mean, I think that was one of the things that was the biggest pain for all of us that were ... I mean, I owned a web development company for 12 years. So, battling with IE6 and all the different browser compatibilities was definitely a huge problem, which is why one of the things that I think we did or we did well was build back end applications that would completely render the pages.

And as you said, as we move towards this more of an Ajax, sort of filling things out, and of course now, we're into a whole new era with single page apps and React and Vue and things like that, but what was it, though, that once ... So, once you started building some of these more interactive JavaScript side of things, were you still using ColdFusion or did you move to something else for your back ends?

Ray: Well, so it's interesting. Yeah. I was still using ColdFusion, but what I began to notice is that ColdFusion began to get more and more dumb in terms of what it was doing, whereas before, I was rendering entirely the entire site. It began to be just a JSON provider.

One of the things that kind of got me off ColdFusion is that, at the time, it did JSON very badly. It would have this wonderful feature where, because it was typeless, it had to make guesses in terms of what your data was. If you would try to take someone's name, let's say possibly an Asian person who's last name was No, Dr. No, maybe. It would, in JSON, convert that to false. You had no control over that at all. So, both seeing how small I needed ColdFusion and seeing it kind of fail in terms of generating JSON, that began my migration to more Node.js development.

Jeremy: Yeah. And so, when you started using Node.js, were you still setting up servers and doing all that fun stuff?

Ray: Yeah. And so, in fact, what really got me into Node was Express, because I would go to intro to Node presentations at conferences. It was 40 minutes of setting up a web server in Node. That was cool, but having used Apache for a decade, I'm like, "I don't want to rebuild Apache." It may be slimmer and quicker and I'm doing it by hand. I just didn't want to do that, but seeing Express and seeing it kind of handle some of that boring stuff behind the scenes and really just kind of get you quicker to building routes and actually building applications, that's what really kind of nailed it for me.

Jeremy: Yeah. And so once you discovered serverless and I know, we'll talk about the JAMstack a little bit more later on, but once you kind of came to all of that, I mean, because I know, for me, building everything on ColdFusion or PHP or any other language and having to deal with the servers and the routes and all that other stuff that you have to build in, a lot of that goes away. So, did you see just an efficiency gain when you started moving to JAMstack and serverless?

Ray: Absolutely. So, I mean, Express is pretty slim. It's pretty quick. I can get a server up and running in four lines of code. I could define a route and then, on that route, say, "Do this logic." The first time I did a serverless function where the route was handled for me, URL informed handling was just passed into me. I literally, I only did the logic. I was like, "Oh, god. I'm never writing a server again."

Jeremy: Right. Exactly. So, you go from ColdFusion, which was, especially in the beginning was relatively simple. If people aren't familiar with ColdFusion, I think it still exists. I think I just looked and there's ColdFusion 2018, maybe, which is now under Adobe. It was J.J. and Jeremy Allaire who started it, I think, '99 or something like that. Then, it was eventually bought by Macromedia and then Macromedia was bought by Adobe. So, it's changed some hands.

So, you're building things on ColdFusion. It's this relatively simple thing where it's very much like PHP. You can write a lot of stuff inline, if you wanted to. You could do some application components and things like that, but mostly you're writing code inline. So, it's a really sort of simple, I build a page, I add some dynamic content to it, maybe I query a database, whatever I'm doing. Very simple, very straightforward, render the page, session management, all that stuff built in.

Along comes the JAMstack and along comes serverless functions that are, for the most part, stateless. There's this huge paradigm shift. You have to think about it in sort of a different way in which we build applications.

So, I'd love your perspective. From going from something like ColdFusion and building more traditional applications that were rendered to moving to single page apps and static sites and stateless functions, how did you sort of, I guess, calculate that or deal with that complexity in your head?

Ray: Hard. It was hard at first. On one hand, it was kind of mind opening to say, "Yes, I could have a serverless function that will do whatever logic and it's just a file and it's just deployed. It's good to go." But starting to wrap my head around, I used to build a site this way, now I can build it that way. It was definitely a process and still one I'm thinking through. I'm blogging right now about migrating a node site to serverless and JAMstack.

But, it was a bunch of things happening at once over a couple of years, although I guess, "At once at a couple of years," doesn't make sense, but when I'm this old, things kind of compress. Again, seeing browsers just get really, really good. We were both there back in the old days, so now they're amazing. So, being able to rely so much more on the clients to be able to do stuff and also realizing that many of the sites I built with ColdFusion, they were dynamic but the data was changing once a month or once every couple of weeks. I was still doing extensive calls to a database just to fetch something that never changed.

So, recognizing that there was data that was more static, even though it was in a database, so it was still essentially static and that accounted for a vast majority of what I was doing, just kind of made me realize I did not need an application server. I didn't even need Node.js. That was overkill in a lot of cases and just to start the think of what is dynamic? What could be fetched on the client, what could be generated at bill time with the static site generator? Just kind of think more about my data, I guess.

Jeremy: Yeah. No. I think that's a really interesting way to start thinking about it. I actually had Guillermo Rauch on several weeks ago now. We were talking about Vercel and Next.js and this idea of static first versus serverless first, which I think a lot of people are kind of praising this idea of serverless first, but the more you think of it and, of course, if you're looking at it from a web development perspective, static first is a very, very compelling thing because it reduces a lot of complexity, like with a blog post. What do you care about on a blog post? It's the content of the blog post. We want to see that as soon as possible. If you've got comments and maybe a little offer that loads on the side or something like that, that can all be done after the first paint, but you get the benefits of the SEO, you get the benefits of it running really quickly, you get the benefits of not having to call a database every time like you do with something like WordPress.

So, yes, so I think that's great. So, what are some of those other things so that you then did sort of to make a JAMstack site or a static site have extra dynamic capabilities in it?

Ray: So, I've been working with JAMstack for three or four years. Back when I started, it was the static site generators. Pretty quickly services began to spring up. So, I remember Formspree was one of the first ones I used where literally you would just point your form at it and then it would handle sending an email for form submission. Now, we have hundreds of stuff like that.

So, not having to do form processing, not having to send mail, we have options for database storage. There's literally nothing left for me to put on my server except for the particular logic, so if I pick something on a dropdown, the form content gets mailed to Mary, whereas, if I pick something else, it gets mailed to Sue, but everything else, the routing, the mailing, that's not handled by me at all, so I write three lines of code to handle that if clause.

Jeremy: Yeah, yeah. Now, I saw that you were using Eleventy for some stuff which I just started using it as well, so why Eleventy over something like Hugo, for example?

Ray: So, I think all of these JAMstack options, they have a different philosophy and I think some engines are a bit more forgiving, a bit more loose in terms of what they allow. I could see philosophically why you may or may not like that. You may like something that is more strict in terms of what it allows. I found Hugo at the time I was using it to be very strict. I remember I was trying to build a JSON file. A couple of years ago, that was very, very hard to do. In fact, I just gave up. Ended up outputting plain text instead, whereas I feel like Eleventy allows you to do anything you want to, whether that makes sense or not, Eleventy's not going to judge you on that. I've yet to find a place where it stopped me from doing what I want.

Now, have I pushed some very ugly code? Absolutely. But one of the awesomest things about JAMstack is I feel like I could do ugly, inefficient code during the build process because once it's live, it's a flat file and that's awesome.

Jeremy: Yeah. No. I totally agree with that and that's something, too, where I found myself, I want to say, "hacking" the Eleventy stuff, a little bit to make some things work, but then I find that it works really, really well. Even the data model that flows down. If you have data stored somewhere else but then you want to reference that data like maybe within some loop that's happening there. Of course, the fact that you can do, what is it? Support Nunjucks and all these different template formats. You can do things in markdown. It uses Frontmatter in order to do the, you can put titles and all kinds of information up at the top. You can control sorting. You can do all kind of things like that. So, I do agree, it is a little hacky, but it gets the job done. I think the most important this is what you're loading once you push that to production.

Ray: Yeah. Yeah.

Jeremy: So, great. So, all right. So, what else around JAMstack have you been doing, because I know you've used Vue quite a bit and you also have written a little bit about Netlify. So, where does Netlify fit in with what you're doing with some of the JAMstack stuff?

Ray: So, they are essentially a JAMstack provider, so they allow you to host static websites, but then they provide all kinds of really good features on top of that, so they have a form processor built in. They have analytics built in. They have serverless functions built in, so you don't have to go anywhere else to do any of those things.

So, to me, they are the gold standard in terms of where to host static sites. Not perfect and you know Vercel is also pretty darn good. You could use S3 as well, so you definitely have options, but I tend to compare everybody to Netlify as the gold standard.

Jeremy: Yeah. And are you still using Vue or you building static sites that are using server-side rendering or something like that or how does Vue fit in there with what you're building?

Ray: So, I tend to not use Vue to build sites. So, I don't use Nuxt, for example. I'm not opposed to it, but just my mental model, when I'm generating a JAMstack, if something like Eleventy or Jekyll or Hugo. What I think about the interactivity that I'm building on the client side, then, yes, I use Vue.js, but I tend to not worry about them together, if that makes sense.

So, I'm building a website. It's going to have a list of films, for example. I know I'm generating that dynamically with Eleventy. On the film page, I want this interactivity, so click for a video preview or whatever. I use Vue for that. I know that Nuxt can do that entire stack, but for me, that doesn't click right. I'm not saying it's wrong. It just doesn't click for me.

Jeremy: Yeah. I know. I'm still on the fence about static site, like where to use Vue within some of that static, because I love the reactive or I love the Virtual DOM and being able to easily manipulate stuff. If you've ever used, whether it's Redux or something like that, in order to use the state management, I forget what it's called, in Vue. But, it's very cool stuff that you can do if you maintain that state across, you can do page transitions and stuff like that.

Anyways, interesting but, I actually want to go back a second and go back to this idea of embracing sort of this new paradigm. So, again, if people know you from the ColdFusion world, you wrote a lot of books. You were an educator. You continue to educate. You even have a book on serverless. We can talk about that in a minute, but in terms of teaching developers, I mean, because again, I think teaching developers ColdFusion was, in a way, similar to teaching people a little bit of ... Because it was a little bit of maybe a mind shift there, but do you find any parallels between sort of what you've been teaching with ColdFusion and how you've been trying to teach people about serverless and JAMstack?

Ray: Maybe. I could not imagine how I would do a course now that was just welcome to the web. I wouldn't know how to do it day one like if you knew nothing. I feel very comfortable talking about the JAMstack and JavaScript, Vue.js, et cetera, but if you were beginning in web development, that's something that's actually been in my mind lately, like how would I start my children on that, but I would not know how to do that.

I can say that, for example, I think some technologies are more welcoming to people of different backgrounds. I found ColdFusion to be very welcoming to people from nontraditional backgrounds. I find Vue.js to be a bit friendlier than React, which is not to say that it's more powerful than React, but if you came to me and said, "I'm an English degree person, no ComSci background," I would absolutely lean more towards Vue.js than React.

So, I myself, I tend to lean on things that are a bit more approachable and a bit more simpler. I don't find myself to be the smartest person in the world, so that helps. Some of the easier stuff works for me as well.

Jeremy: Right. Well, what about the level of abstractions when it comes to serverless? So, if we look at something like AWS, we know we've got all these building blocks. I know that you haven't done much with Lambda and some of those other things, but if you think about SQS queues and DynamoDB and just the Lambda functions themselves and whether you're using Netlify to do that or you're using something else, you've got all these different building blocks. So, is that too complicated, you think, for some of these people getting into web development and that just this idea of using Netlify or JAMstack, does that create the right level of abstraction for people?

Ray: I think if you start with just HTML, then you're doing fine, but that's how we started in the old days. I really like Duran Duran, so I'm going to build a fan site on it. So, you go to Geocities or MySpace and it would have a small amount of HTML that they could build.

So, I think starting with the JAMstack means mostly starting with the HTML. Typically, you have a bit of interactivity with the template language involved. So, I think that would be great because if you could even do JAMstack without any dynamic aspect at all, just to kind of get your feet wet.

Jeremy: But is that something, too, where, I mean, how many people getting into web development because I know, I used to interview a lot of developers not too long ago. So, many of them didn't even know what the cloud was, nevermind getting into any of the details. Is that starting point there is, there's just so much to learn.

So, I think you're right. What is that starting point? If you were to say, "Welcome to the web 3.0," or wherever we are now, that includes cloud, that includes JAMstack, it includes serverless. I mean, again, maybe you can't answer this question but what advice do you give to somebody who's just starting out?

Ray: I think it's less about teaching the cloud and more about looking at a problem solution type aspect. So, I have a web page and I want to put the current time on it. That's a problem. And then you use that as a way to talk about JavaScript, as a way to add interactivity to a web page. When it comes to the cloud, maybe the introduction there is, "I want to put my website out there for people to see. How do I get my website on the internet?" And you talk about Netlify and other providers like that that allow you to push the HTML live.

So, to me, it's more focused on as you're learning HTML and building a website, what are the problems you encounter and then how do you solve those problems?

Jeremy: Yeah. And what about defining serverless? I know you have interesting thoughts on maybe what serverless means, but just in general, if you start talking to people about serverless, where does that put them?

Ray: So, first off, I'm kind of happy that I don't think people are complaining about the name anymore because, for a long time, that's all you heard was, "Oh, you know there are servers, still," and that was a voice that every person said it with. So, yeah, I don't necessarily think that you have to worry about that anymore. I kind of lost my train of thought, too. What was the original question?

Jeremy: No. Just, in terms of introducing people to serverless. Again, I mean, we talked about people, do you need to know the cloud? Do you need to know ... Obviously, you need to know basic HTML design principals or things like that, but just where does serverless fit in there? Is it something where we're getting to a point where it's just that the term itself might just become synonymous with the cloud?

Ray: Yeah. I think, again, if you take a problem and solution type aspect, so there's something that I want to do in this web page where JavaScript won't work for me for whatever reason. So, I can look at serverless as a way to kind of solve that problem. Netlify has done a great job and also Vercel of just making it in the same package, so you're not going to Lambda, even though they're wrapping Lambda, but you don't have to worry about that.

So, I have my folder. I put my HTML pages in there so I use the same folder to write a function. So, I would use that as an opportunity to basically introduce function as a service. I need to write some logic that runs on a server. Here's how I do it. Here's how the input comes in and here's how I return output. You teach that for Netlify. They can transfer that knowledge to Vercel. They can transfer that knowledge to other services as well, because then it's just input/output and what you name your file, essentially. But then, the idea of I couldn't do it in HTML, I couldn't do it with CSS, I couldn't do it in JavaScript on the browser. I needed a server, and this was my gateway to doing that.

Jeremy: Yeah. I think that that's actually good advice is, again, if you go down the static-first route is to think about what you can do without making something dynamic, how often something has to change, and then, like you said, sort of slowly increment and say, "Okay. Now, I need to add this bit of dynamicism or whatever and start adding those pieces in."

All right. So, I want to talk about OpenWhisk, because I know you did some work with this. I know you wrote a book about OpenWhisk. You don't use it anymore, but I'd just like to kind of get your perspective. What was that about and why aren't you using it anymore?

Ray: So, I think I first looked at Lambda and I was a bit intimidated by it and I remember it was a bit hard to use from the command line. I doubt it's hard anymore. I was working at IBM and I knew that we were participating in this open source project called OpenWhisk. I knew it was serverless, so I took a look at it. It just clicked with me. Via the command line, it was very easy to use so it's very easy to deploy stuff. I tend to gravitate to things that are easy to use and quick to play with.

I can make a new file, I can deploy it in one second. At that time, Lambda felt like there was a lot more overhead to get something up and running and to be able to test it in my browser. So, if I could play with something and I had the same thing with Vue is that I could drop a script tag on a page and play the Vue whereas, both React and Angular felt like it needed more of a build process, so I couldn't play as much but OpenWhisk, I was able to play and build a crap ton of really stupid demos, but that enabled me to learn it a lot faster.

Jeremy: Right. Yeah. No. And so, with OpenWhisk, though, you stopped using it and you moved on. So, are you still involved with that community at all?

Ray: No. I mean, I try to check in on it every now and then. I know, for my company at some point, I'm doing a blog post on using our APIs with OpenWhisk. I don't hear anybody talking about it, which I think is unfortunate, because I do feel like it had a very easy-to-use approach. I would like to see it get more attention, but I don't work at IBM anymore, so that's not my job to help promote it.

When I left IBM, I went to Auth0 where they had Webtask, another very easy to use one. That product is now canceled. I think I was about to start looking at Lambda again when Netlify added their thing. I was, "Oh, great! I don't have to worry about Lambda again."

Jeremy: Well, Lambda is great so you should definitely check out Lambda, but actually this is something that maybe draw another parallel between ColdFusion and serverless is ColdFusion was always proprietary, right from the beginning. So, you had to buy a license to it. There was no just download it and run it like you can with Node or with pretty much any other language that's out there now, and so it was very proprietary. There's been this battle in the serverless community about the idea of being or having vendor lock-in, like this idea of saying, "Oh, well, AWS owns my Lambda functions, so I'm locked into using those."

I'm wondering. I mean, I personally think one of the reasons why ColdFusion wasn't more successful was because it was proprietary and it wasn't something that just anybody could use. It wasn't something where you could get the developer edition, but there was still quite a bit of work there.

So, do you see a parallel between that? Do you think that there's going to be an adoption problem because of this idea of proprietary versus open source?

Ray: So, a couple things. There is an amazing open source engine for ColdFusion called Lucee. It's been around for a while now, has a great community. Is it as big or as popular as the commercial release? Maybe not, but it's absolutely good to use. There's been other community members and other companies like Ortus Solutions. They have CLI products where I can literally go into a folder and I can say, "Add the open source ColdFusion engine here," and then just runs.

Jeremy: Oh, wow!

Ray: So, I'm not doing that kind of old school thing of double-clicking the installer and spending a half hour to install ColdFusion. So, the open source version has done really, really well in terms of making it easier to use. Honestly, I don't think the community is growing that much. I do think a lot of people have moved on, but there is definitely an open source flavor of ColdFusion or CFML, if you will.

In terms of lock-in, I don't do a lot of orchestration. I know we're going to talk Pipedream a bit later, but this idea of I have 20 serverless functions and I need them to flow in a pattern. If I was doing that, then I'd be worried about lock-in with Lambda or somebody else. If I'm doing a couple of serverless functions, then I'm not worried. I know I can convert a Netlify serverless function to Vercel in five minutes. I look at their docs. I see, "Oh! They passed this argument instead of that argument." I rewrite a couple lines of code and then I'm good to go.

So, personally, I'm not involved with that, but, again, I tend to build a lot of small demos and a lot of toys. I'm not building an enterprise application again with those 20 functions being called in a chain.

Jeremy: Yeah. So speaking about that orchestration stuff, tell me more about Pipedream.

Ray: So, I found Pipedream six months or so ago. One of the people from the company had emailed me and asked me to check it out. I didn't get a chance to look for months and months and months. Then, when I did look, I was just blown away. I loved it.

So, Pipedream, it's built around this idea of building workflows. So, I want to read data from a Google Sheet. I want to take that data. I want to find a particular row. And then, I want to send an email for that data. Then, once the email is sent, I want to do a tweet.

So, all of those particular things, those are unique steps. They're unique bits of logic. What they have done is I've built a system where they have prebuilt all of these steps for you. You can literally, like Lego bricks, pick a couple, maybe have one step in the middle that's your custom Node.js logic that literally does like an if condition. It does real minor work, but a real example, I have a Google Sheet that has 10 rows of URLs for pictures of the moon. So, it has an image URL, it has a credit and that's it.

So, I built a Pipedream that says, "Read from the Google Sheet." So, Pipedream, they built that logic. I didn't do anything. All I did was plug in what my Google Sheet ID is. I didn't have to write any of that Node.js code.

The next step, the select random, I wrote that. That was three lines of code to pick a random index from an array. Then, when I'm done, I have a random URL and I have that random credit. I then wanted to tweet that. Well, again, Pipedream, they wrote that logic. I dropped that Lego brick in. I say, "Here's the input from the last step. This is what I want you to tweet." And I'm done. And it all started with a cron-based trigger, that, again, they wrote where I say, "Run once an hour." So, I have a Twitter bot where my coding work was literally the "pick a random row" and that's it.

Jeremy: Right. Right. Yeah. And I've seen some other companies like that. I think Paragon was one. A couple of these other companies coming up with these sort of low code solutions that are using serverless behind the scenes, because, again, it's so cheap to use a serverless function here and there and even some of that logic that you're talking about like the crons and things like that, probably using CloudWatch scheduler or something that was already written, too. So, they're just building on top of it.

But that's one of the things with these abstractions that I think we're seeing a lot of is that people are building these new layers of abstractions on top of serverless infrastructure and you've got very, very low level abstractions like the serverless application model and the serverless framework or Claudia.js or some of these other ones or even the AWS CDK that are building these, but things like Pipedream and this idea of saying these repeatable things, these things that you need to do over and over and over and over again, why would you write that more than once, right?

Ray: Yeah.

Jeremy: I mean, again, when I owned my own web development company, I had to write so many forms to process, you know what I mean?

Ray: Yeah.

Jeremy: And you're always writing these form processing things over and over and over and over again and it would just drive you nuts. I think that this is really interesting where we're finding this really powerful paradigm under the hood but then finding companies like Pipedream that are taking advantage of it and writing those powerful pieces of business logic that let you just stitch them together.

Ray: Yeah. So, I think so much of my work back in the old days was boilerplate, was setting up browsers and stuff like that. My work is getting much, much, much more smaller, but much more enjoyable as well.

Jeremy: That's a good point. So, I'd love to ask you, then, if you see a lot. I mean, you're using Pipedream. You're trying to stay away from Lambda, because, again, you're getting what you need from Netlify and things like that. So, I guess my question is and I think if you're building full-on applications, then you're going to need Lambda and you're going to need SQS and you're going to need some of that, but certainly, when you think about the future of serverless from a web development perspective, where do you see that going?

Ray: I think it'll basically be what the browser can't do. It's something where I can't trust a browser to handle this for me. I need to rely on a server that's where serverless is going to plug that hole. So, JAMstack is rendering my HTML, which we still need. People still read stuff. We have JavaScript in the browser to handle 90% of the interactivity. Then, there's certain things that need an extra layer of security. Can't be in view source and that's the last mile, I guess, the last bit will be serverless. I'll only have to go there as a last resort. I'm fine with that.

Jeremy: Yeah. So, I mean, in terms of building out some of these things, I mean, it's funny because now it's like when I think about building a new site or I think about building something, I spend most of my time planning and a lot less time actually writing code, which, like you said, I think makes things a little bit more enjoyable as opposed to just coding randomly and hoping things work out. You can actually do much more planning and structure that way.

So, all right. So, one last thing I'd kind of like to do just because when you get two old people talking, it's always and again, I am including myself in that because I was back there in the early 90s with you. The idea of setting up a site back in the day versus what we're doing now. You mentioned earlier in the podcast Perl and CGI. Well, in order for you to get Perl and CGI up and running, if you either call the hosting provider or signed up for a hosting provider that had it set up for you, but if you were setting up your own service even 10 years ago, let's just talk about that. What was that like?

Ray: So, 10 years ago was a heck of a lot easier than it was 20 years ago.

Jeremy: That's also true. Right. So maybe start 20 years ago and then we can work our way through.

Ray: So, I know, I live in a small city. There was maybe two ISPs, so we were on good terms with them as a web development shop, but you would call the ISP up. You would say, "I need a machine," and they'd get one piece of hardware just for you. Then, they would tell you the FTP address. Then you would FTP to it and you would remote desktop in, if you were lucky, to install software. This whole set-up process was before you got the machine in maybe a day or two. Now, I think it was a bit quicker for us because, again, that we knew people, but if you didn't, it was at least a couple of days. Then, you installed all the software and then you deployed your site. So, it was at least a week or so to get stuff going.

10 years ago, it was a heck of a lot easier because you could go to Amazon and get an EC2 machine and have that immediately. But, then, install your software again, but I was so much happier about that because it was instantaneous. I know at some point, they allowed you to define what was already installed and you could just clone that. I wasn't really around or I didn't really play with that much but yeah.

So, now, I tend to use Netlify for my real sites and Vercel for my quick demos, but at the command line, I typed something and 60 seconds later, it's live on the web. That's nothing compared to how it was.

Jeremy: Right. Yeah. No, I compare setting up an EC2 instance or I had a colocation facility, so I actually or I rented space in a colocation facility, so I was buying servers from Dell, racking them, installing software, doing all that kind of stuff as well. So, that's my equivalent of walking to school uphill both ways in the snow. But, anyways.

Well, listen, Ray, thank you so much for taking the time to talk to me. Seriously, I was huge fan of yours. Still a huge fan of yours. I appreciate everything that you've done, not only in the serverless community lately, but way back in the day in the ColdFusion community, because I think you're right. There were a lot of parallels between what this non-traditional background and making it easier for people to kind of get in and I think, as you've called it, democratize the web, sort of get to that point where more people can start participating and sharing ideas. I love that ColdFusion and serverless are very similar in that regards or ColdFusion and serverless/JAMstack are in there.

So, again, if people want to get in touch with you, find out more about what you're working on, how do they do that?

Ray: So, I have a blog at RaymondCamden.com and I'm on Twitter, @RaymondCamden, and my DMs are open and I like to get questions. So, absolutely reach out if you have a technical question or any question's fine. I'll be happy to try to help you.

Jeremy: Awesome. Well, thanks again. We'll get all of that into the show notes.

Ray: Yeah. Thank you for having me.

Episode source