Hey all, quick question. If a serverless function provider offered a native CFML Runtime, would anyone here consider using it for production?

I built fuseless.org several years ago, it allows you to run CFML on AWS Lambda. Based on the interest level in Fuseless I would say interest is fairly low. Adobe also had a beta version of CF that could run on lambda but that never took off either

Thank you for that, I have great respect for what you do at Foundeo, and I did find your fuseless.org site recently. Not sure what the resistance might be exactly, serverless architecture has so many advantages. It would be interesting to know what is holding people back.

For me, if I was going to build something serverless I would just not use CFML

The stuff that makes CFML great -- DB connections, connections to mail systems, integrations with all other stuff is less suited for serverless than some other languages. Considering java based apps have a pretty big overhead when starting up, there has to be a real compelling reason to use CF as a serverless back-end.

Hey trandall and quetwo, thank you for your input, like you I love CFML. To quetwo's point you are right, CFML has many built-in packages. Meaning you don't necessarily need a separate service to handle things such as database connections, reporting, scheduling, image manipulation, and the list goes on... That is one reason we use CFML. The problem is the architecture. It is getting harder to convince people they should stick with MVC patterns on monoliths. Not to mention paying for, provisioning, and securing servers, when you don't have to anymore. Many new devs don't know devops, and many prefer using CDNs as their frontend. To trandall's point, you are right too, there are other native languages you can use for serverless. Java being one of them. From my perspective the vast majority of web development these days is using a variant of javascript such as React. The rest are splintered into all the other languages. Unfortunately CFML is not even on the radar. I could be wrong, but it would make sense to use CFML (using Lucee) as a serverless resource. With that, any web application or mobile phone can use CFML to process requests. If CFML was packaged as an easy-to-use, serverless resource, it could improve the popularity of the language. I would certainly like to know more opinions, but as Foundeo mentioned, there may not be any interest. Transitioning off monoliths may be a hard sell for CFML devs. Instead, such a solution might be more accepted by Jamstack devs who use serverless and are looking for something easier.

@Bill Nourse -- I guess, I'd want to know /what/ would you do with CF as a serverless resource? What I typically get is "well, I like CF (or I want to promote CF), and I want to write serverless in it!". With serverless, you can't write applications -- you would only write small bits of code -- a single function call would really be it. If all you are doing is a DB dip and maybe a small bit of business logic, OK... but beyond that, I guess I don't see the point.

Thanks for asking. Exactly right, each function is a single-purpose block of code. However you CAN write applications, any web application you can think of, but not the MVC variety we are all familiar with. That is the biggest difference I had to get my head wrapped around. With serverless you write event-based applications that handle requests from users, schedules, or other events. State happens on the client. If it helps, consider a microservice simply as a group of functions, not too unsimilar to a CFC really, but without any OOP. Here are a few advantages... 1. Easy to scale, handles any number of requests without worrying about the server 2. Easy to deploy, one function at a time 3. Easy to write, that is if you used CFScript 4. Easy to debug, one function at a time. 5. Easy on the wallet, use .5 - 2 seconds, 15 seconds max. A simple example is a form. One function could handle validation, routing, transaction emailing, and final database insert. To host the app you could use a cheap VM, or have it cached on a CDN. To run a database, use another VM or use a cloud service in the same region as the function. For me, the point is keeping it super simple, but allowing massive scaling, at lower costs. It's actually a fun way to code I think.

I don’t think the question is around the benefits of serverless. More, what is the specific value added of using CF to do it when it is already easier to do with other languages? Especially with something like JavaScript/node.js which is something you’re probably already pretty comfortable with if you’re a full stack CF developer. I think I would use node, python, or Go all before I’d choose CF for Lambda or something similar. I’m sure lots of others would use Ruby.

Hey trandal, Fair question. Since you mentioned NodeJS, let's use that as an example. To create a function, you first have to package your dependencies using NPM or another package manager. Which is all fine and good. The trouble with that, in my view, is you are reliant on code written by other people such as database drivers with various versions and contributors. With a CFML runtime there are no dependencies. That's what the Allaire brothers gave us, a vast array of native global functions. You are absolutely right however, any current serverless language will work. It's more a matter of how fast you can write it, and how fast a processor can output it. I personally prefer CFScript... that is why I asked the question. If a CFML serverless runtime is not an advantage, then it would make no sense to use CFML at all. At least for event-driven architecture. I still think CFML is an advantage, but I am open to being proven wrong. Please let me know.

Oh I don’t think I can (or want to) “prove” you wrong. I just think very few people are going to share your preference. I have used CF as my main backend language for 15 years and I would not go out of my way to use a CFML runtime for serverless functions.

Hi Trandall, thank you for your input, much appreciated :) Giving it some thought, my conclusion is you are right, it may not make sense to push CFML as a serverless runtime. There might be better alternatives such as Go which is faster and more appropriate for single-purpose functions. But if you need an MVC monolith (containerized or not) CFML is still a great choice, especially with Lucee. The challenge is convincing new clients. How to do that might be a good question to ask everyone.

Yeah I think there is certainly room to discuss how to improve CFML adoption. I’m a bit pessimistic about that as long as Adobe pursues license models that push so many developers away from the official CF, though.

Yeah, I'm familiar with that sentiment. It pushes the decision to pay the high fees, transition to Lucee, or pivot off CFML entirely. I know of those who have done the latter.