There’s great news coming regarding Adobe ColdFusion 2020, with regard to deployment of CF via Docker images and/or in the cloud.

As I posted in much more detail on my own blog, Adobe’s Director of Engineering for CF, Ashish Garg, recently held a wide-ranging interview with Michaela Light (on the CF Alive podcast) about the CF2020 roadmap.

The key points for the subject of this post are that Ashish shared news of some substantial changes planned in the next release regarding modularity in the engine, the size of installers/containers, and their startup time, as well as matters like licensing of containers, logging within them, monitoring of them, and more.

Update (Nov 2020): Now that CF 2021 has been released, I’m sad to have to report that the licensing for Adobe CF as Docker has not changed. The links above to the FAQs go to pages which HAVE been updated to refer to Cf2021, but the sections on Docker licensing terms. Are unchanged from what I quoted above. Very sad to hear, when there had been acknowledgment of a change needed for practical containerized deployment. Oh well. Again, use for dev is free. Use for prod requires licensing like regular CF deployment.

Again, in the post on my own blog, I offer more detail (including time marks) and some additional commentary. I just wanted to make sure to get these key quotes here on the CF Portal, where some may see them and not my own blog.

Coming: better licensing for containers/cloud

Ashish thankfully addressed the “elephant in the room”, the all-important question about cloud/container licensing. For more about the current state, see another blog post I have done here. Ashish said:

“When CF2020 comes out, it will have the right licensing which is suited for the cloud environment, because whatever else we do it will defeat the purpose“. He was speaking there of other plans to improve cloud deployment in CF2020, which had been discussed earlier in the podcast. And after some other clarifications, he added that this licensing change was “one of the key pillars of making CF2020 successful“ and indeed, “a key requirement from our [engineering] side“.

It will be VERY interesting to hear the details about this as they emerge.

Coming: reduced image/installer size and startup time

Ashish later talked about the OTHER elephant in the room (the large size of CF containers installers, as I mentioned above). As for what especially caught my attention, regarding containers (and scalable deployment), note specifically that he said:

“The goal for…the core runtime is …we imagine that it could be somewhere like 100 to 150mb“, though he added that they are still evaluating and think they could make it even smaller. But he noted that “for normal functionality, everything should be less than 250mb“. As important, he indicated that the goal would be that “it should start in maybe 5 seconds or less“.

Other topics covered

Again, it was a wide-ranging hour-long interview, but cherry-picking the topics that I think were most relevant to the topic of this post, Ashish also discussed plans for:

• improved command-line/declarative Admin/config
• centralized deployment/config
• better management of monitoring across instances/containers
• better management of logging with them
• improvement regarding serverless/lambda functions
• hope of additional integration with cloud-based services like nosql, caching, messaging, and notifications
• plans to better support hybrid/multi-cloud deployment, which may appeal to some regarding their deployment flexibility

More in my other blog post

That’s all very encouraging news, and we can look forward to more info to be shared by Adobe at the upcoming Adobe CF Summit, if not sooner.

And again, I share much more detail and commentary in my blog post of the same name at my blog, including a reminder about the presentation and day-long pre-con session I will be offering at CF Summit on the topic of getting started with CF on Docker.

I am definitely very encouraged to hear this news of more specific plans to make the prospect more appealing, from the perspective of licensing, performance, configuration, and more.

PS For those who may want to interject how Lucee is already free, modular, and smaller, I acknowledge such points in my other post.

For more blog content from Charlie Arehart, see his posts here as well as his posts at carehart.org. And follow him on Twitter and other social media as carehart.