CF: CCFML or Making the Case for a Different CFML Future

Looking at the demands of our enterprise and the product road-maps as far as they have been disclosed by either Railo or Adobe we discovered a gap between what we are trying to achieve and what the technology is going to offer.

So, I have taken upon me to summarize a few thoughts and suggestions that I would like to share to see whether we can sway the Railo/Adobe general product direction.

I believe that focusing ever more innovation resources on the concept of RAD (Rapid Application Development) and language improvements, though interesting and useful, are not making CFML standout sufficiently to make a long-term difference and detract people from leaving or encouraging  new people to join.

In my opinion, the next level of server improvements need to be substantially different from other offerings and, this, in turn, requires a rethinking of what Railo/ACF offerings are.
Specifically,
• Abandonment of the concept of Application Servers
• Remove the need for download/installs
• Remove the need for server administration and management
• Redefine offering as packaged “infrastructure” with smart policy and deployment
• Use clear convention based guidelines for subsystems (cache, application, storage, db)

Ok, now you say, what the heck are you dreaming about?
Good question, that.

In short, I am proposing that we work towards a true Cloud CFML platform === CCFML.

Let me explain:

We come from a heritage of dealing with individual servers and have embraced that concept wholeheartedly for many years. However, in the age of the cloud we should question those expectations.
How much more attractive could CCFML be when you only need a github/subversion account to deploy your code and a few policy definitions on how large you want your Application to scale and how fast.
When there are application problems, you can define policies how much CPU a process may consume, add more CPU cycles specifically for it, and/or cache. All automatically.
You application works automatically, fully scalable, across the globe on CFML.
You are kept abreast of any problems, bottlenecks and are given options to upscale CPU, refactor code, or add instances. But, best of all, you let the Cloud CFML take care of everything that a global CFML service should.
You want to push a new version, just change code and click deploy/schedule button.

Whatever decisions need to be made to get us this platform nirvana should be in the forefront of cfml future enhancements. This would require more standardization of convention so that we can have auto- configuration over coding whenever possible.
Behavior for deployment will need to be defined and “standard conventions” documented.
Here is just a selection of things that need to be answered on the way towards such a CCFML platform:
- Which distributed cache to implement and deploy
- Deployment system magic (version, install, upgrade, start, stop, pause engines)
- How do you scale session across servers
- How to communicate among cluster members
- How do you join servers to clusters
- How do you create a unified lightweight Application scope across the cluster,
- How to measure and set time,
- How to define and use a shared file-system
- How do you delineate code files storage vs. user assets
- How do you provide Application policy definitions for scaling
- How to manage and analyze code performance
- Create Application Manager (instead of Server Manager)
- Assigned Server roles, e.g. stateless vs. statefull servers
- Global logging and analysis
- Etc., etc.
There are probably many elements I don’t quite understand or have not considered. This is where I would ask for the smart people of the community to jump in, but, the point I am trying to emphasize is that future innovation should be directed towards creating such a platform rather than focusing on the minutiae of the language syntax.

The CFML language is quite mature and tweaks on syntax can only have limited impact on stopping developer attrition while an easy to use application platform has the potential to attract developers.
This model also provides a clear path for providers of this tech to charge for the services with the value recognition they are looking for.

The good news is that we have many components already; the next step is to create the working package and provide CFML as a first class cloud service.

We would not be the first, others like Microsoft with Azure and .net and the Java/Scala Play! Frameworks have already started the thought model and are getting traction. I fear that if we hesitate too long we may miss an opportunity to reverse course.

I hope this is not too confusing of a ramble and I am looking forward to feedback.

-Bilal