Understanding the State of ColdFusion
We’ve had time to read through the results of the annual “State of ColdFusion” survey from TeraTech. It’s a community-driven survey that tries to collect the sentiment of the ColdFusion community to identify trends. At first blush, it seems that die-hard developers, with 20+ years under their belts, continue using CFML like it’s 2005. Meanwhile, as we suggested earlier [https://www.webapper.com/coldfusion-2021-off-ramp/], it seems there’s a growing number of users who are frustrated by ColdFusion’s outdated licensing, a contracting market, and the lackadaisical attitude of Adobe. So having had time to digest the results of this report, we wanted to share five key takeaways regarding the state of ColdFusion in 2021.
1. ColdFusion Roots Run Deep
We’ve used CFML since the good ol’ Allaire days (mid 1990s…), so we know the depth of the roots. It’s amazing how many “grey beards” continue using ColdFusion — after over 20 years, it speaks to the loyalty developers have to the platform. Many developers initially chose ColdFusion because it was easy to learn, fast to deliver code, and “fun to use”. But “young blood” isn’t coming in, and that would be a danger sign for any development platform. We’ve seen the 2-for-1 exchange rate for years: when it’s cheaper to hire two 25-year-olds than one 50 year old, companies opt to save money… So the lack of a youthful talent pool means higher salaries to continue development, and ultimately that will work against the roots.
2. Monolithic Adobe ColdFusion apps aren’t getting “cloud native” fast enough.
Over the past year, we’ve written quite a bit about monolithic applications, microservices, and Functions as a Service. By design, ColdFusion leads to monolithic applications; it’s fast and easy to build a functional solution. The survey indicates that developers have a lot of legacy CFML code to manage. Since these apps are monolithic, developers need a broader understanding of the system to be truly productive. Especially with mature systems that have been developed over many years, the inner workings are tightly coupled. The result is that extending monolithic ColdFusion applications into the cloud means living within a bit of a walled garden.
Building and consuming APIs & microservices in another language is one way to begin strangling the monolith. We see this strangler pattern as a critical strategy for CFML applications.
3. Lucee Is a Helpful Detour…
Per the survey, Lucee 5.3 is more popular than CF 2018. We do quite a bit with Lucee at Webapper, so we know it has a reasonable chunk of the market. Although porting to Lucee saves on licensing costs, it doesn’t solve the “true cloud” problem either. We consider it a useful detour before really tapping into the cloud. We have found ways to leverage the cloud better using Lucee.
4. Adobe Isn’t Solving the Problem.
Many of the survey participants expressed frustration with the slow pace from Adobe and the apparent disregard for marketing. The economics for Adobe investing in ColdFusion simply do not support deep investment. Sure, there’s a swath of users who continue developing, but the segement isn’t growing. We’ve seen a long, slow decline for Adobe, which probably doesn’t stack up well when they’re making big strides with their other products. It’s also obvious that the Lucee open source solution has made some inroads into the potential revenue as well. ACF licensing fees will continue to be a source of community frustration as more complex cloud applications evolve.
5. AWS Is Most Popular.
Ironically, Amazon has a big chunk of the CFML hosting market, coming in as the most popular in the survey. AWS beat out options like Azure, traditional hosting services, and on-premise data centers. So the cloud appears to be a community hope and goal, but not yet to the aspirational level we think the market seeks.
The State of ColdFusion 2021
In our first article on this topic, we shared our expected roadmap for the monoliths:
- Stay with Adobe ColdFusion (status quo).
- Switch from Adobe ColdFusion to Lucee (changing course slightly, with better near-term options for true cloud design).
- Rewrite portions of the application as cloud native (minimize ACF expenses while using the “strangler” pattern to slowly replace monolith components).
- Rewrite the entire application as cloud native (most divergent).
What we continue to see is that the community needs to look closely at these options, sooner rather than later. At some point, the operating costs will be too high, the work will be too difficult, and the switching options will be limited…
If you have additional questions about cloud migration or cloud native application development, please contact us.