ColdFusion 2018, do I need Standard or Enterprise edition?

Daniel, great to hear that you're satisfied with the answers.

BKBK, I don't understand your vehement offense at what I wrote. I stand by all I said, and I meant no offense to anyone. I simply stated facts.  Let me address first what's more important for most readers here: the "core vs cpu" thing, and about "the number" regarding licensing. Then I'll address your "no one drew a line in the sand" assertion.

I. So first, I see what you are quoting about the "per two cpu". Thanks for sharing it. And understandable that you were relying on it. But it seems it's wrong. Not your fault, but Adobe's. Why do I say that so strongly?

I was quoting the EULA (which we agree to on installing and can be found in the root folder of any CF install, and stands binding legally vs any web page). It says specifically (for CF2018), first in section 1.1 regarding, "Enterprise License for Physical/Virtual Machine Deployment" that:

"Adobe grants Licensee a license to install and use the Production Software on a per-Core basis as provided herein or in a separate writing. Adobe grants Licensee the right to run a single physical machine/single VM instance for each valid license of Production Software that Licensee has obtained, as long as the number of Cores in such single physical machine is less than or equal to eight (8) or as long as number of Cores assigned in such Single VM is less than or equal to eight (8). For clarity, each Production Software License can run on a maximum of single Physical machine/single VM instance, provided that the number of Core exist in a physical machine/assigned to such VM instance is less than or equal to eight. For example, if Licensee has a 17 Cores in a single physical machine or if Licensee assigned 17 cores to a single VM instance, in each case, Licensee would need three (3) Production Software License."

Then in in section 3.1.2  on "Standard License for Physical/Virtual Machine Deployment" it says:

"Adobe grants Licensee a license to install and use the Production Software on a per-Core basis as provided herein or in a separate writing. Adobe grants Licensee the right to run a single physical machine/single VM instance for each valid license of Production Software that Licensee has obtained, as long as the number of Cores in such single physical machine is less than or equal to two (2) or as long as number of Cores assigned in such Single VM is less than or equal to two (2). For clarity, each Production Software License can run on a maximum of single Physical machine/single VM instance, provided that the number of Core exist in a physical machine/assigned to such VM instance is less than or equal to two. For example, if Licensee has a 5 Cores in a single physical machine or if Licensee assigned 5 cores to a single VM instance, in each case, Licensee would need three (3) Production Software License."

Seems pretty clear to me that that page you are quoting is wrong, which is indeed quite sad, if it may mislead people about what they think they need to buy. I can't find any other page on Adobe's site (other than the EULA) that talks about this matter of 2 vs 8, but I will note that CF reseller sites clearly show the same distinction of 2 cores for Std vs 8 cores for Enterprise:

https://www.buy-adobe-software.com/

https://www.aventissystems.com/Adobe-Software-ColdFusion-s/10616.htm 

Finally, on the matter of cores vs cpu's again it's the EULA that makes the distinction, not me:

"1.6 “CPU” is each distinct central processing unit (physical) within the Computer. Each CPU may contain one or multiple processing Cores."

"1.5 “Core” means a physical or virtual core on a Physical or Virtual Machine and is capable of independently manipulating and operating the Software. In Physical deployment, Core refers to one of smaller processing units of the CPU in a Computer, and in virtual deployment, it refers to the unit of processing power in a Virtual Machine. A virtual Core is the virtual representation of a single hardware thread in underlying processing core. The total number of Cores operating the Software in the Computer may not exceed the licensed quantity, and will be the greater of (a) the exact number of Cores operating the Software in the case when Licensee configures the Computer (using a reliable and verifiable means of hardware or software partitioning) such that the total number of Cores that actually operate the Software is less than the total number of Cores on that Computer; or (b) the sum of all the Cores contained in every CPU on the Computer. The total number of Cores assigned to the Virtual Machine may not exceed the licensed quantity."

II. Second, on your asserting that I somehow misinterpreted you or Dave about what is or isn't in Standard, again I just went based on your words.

Dave asked Daniel to consider rhetorically, "Do we use any of the Enterprise features? PDF generation, API management, etc. I think the server monitoring may be an Enterprise feature now too. Look at the feature matrix for that."  You may feel I misread that, but it seems he was implying that those things were Enterprise only. I have known many people to do it. Any of us can make mistakes (you're accusing me of one now). Can't we just put facts on the table without seeing it as some sort of fight? I didn't intend one. 

Then you said that if "your application relies on threading, messaging, APIs, multiple instances and failover clustering. These are capabilites that are absent from the Standard Edition." If saying a thing is "absent" is somehow not "drawing a line in the sand to separate Enterprise-only from Standard-only", then we just aren't using the same meaning to words.

Can we leave it at that, and let others make sense of what we have written?

Or is there more behind your comments here than what you've stated? If you want to get it out publicly, here or elsewhere, feel free. Or if you may want to say something to me privately, feel free to email me or dm me or call me. All are offered on my site. I don't know where this came response of yours came from, but I'll admit that like many in IT, my "social IQ" may be on the challenged side.

Thank you everyone for the replies, and great insight and information.  This definitely helps narrow my decision on which version to choose. 

-Daniel

Lots of good thoughts here, but also some misstatements or things a reader could misinterpret (partly Adobe's fault per info on some of their pages). As I discuss these things with people often in my consulting, let me elaborate.

First, regarding some things asserted here to be enterprise-only, these ARE in fact in standard:

•  PDF generation: both cfdocument and cfhtmltopdf are in standard (though, yes, they are single-threaded, per that efr mechanism later referenced here)
• server monitoring: the new cf2018 pmt is in both editions (I realize Dave admitted he was unsure about this. And the older "server monitor" was indeed enterprise-only from cf8 to 2016)
• Threading: that's a loaded word, of course. CF is inherently multithreaded. I suspect it's cfthread that's being referred to. And Standard sets a max of 10 for the number of concurrent cfthread threads
• messaging: bkbj, were you  referring to the old feature within cfc gateway,or something else? Those are in standard
• APIs (again, that's a loaded word. Standard supports APIs, in terms of serving or talking to APIs, whether as rest or just via json or web services, etc. What it does not have is the separate api manager, which is offered with enterpise only)

Not saying the above to merely nitpick or be critical, but because they may be important deciding factors for someone debating std vs ent. As has been suggested, see the feature pages from Adobe for more, though they do leave some things potentially unclear.

And that "restricted" footnote is about the EFR, which as indicated will single-thread requests to certain tags, so that if a request is running cf document, for instance, no other request can run it until the first one completes. That's just a small subset of tags (indicated by feature group on that page), but it is a real limiter of standard for some folks.

Finally, a comment was made that both editions were licensed "per two cpus". That's not correct, per the EULA (which refers to cores btw, and to find the eula, see https://coldfusion.adobe.com/2018/01/finding-the-eula-end-user-licensing-agreement-for-your-installed-cf-version/).

First and most important, it's instead 2 for standard and *8* for enterprise. That's a big difference if you have more than 2 cores.

Second, this is not about how many CF "will support": it will use as many as there are. This is simply about how many there are, which controls how many licenses would be required.

So if you have an 8-core machine, you'd need to buy *4* standard licenses VS only 1 enterprise. The four Standard would cost MORE than the one Enterprise license, in which case it's no longer about whether you "need" the other advantages it offers. They'd be a bonus. 🙂

I don't say that to "push enterprise". To be clear, I am not a cf reseller, so I make no money based on what license people buy. I just help people weigh their options, and I help troubleshoot problems which sometimes is about licensing.

Indeed, fwiw, I have more often SAVED people from going to enterprise--when they feared it was the only solution to their problems, and instead we solved the problems so things worked fine even on standard. As has been said, different people have different needs of one vs the other.

Finally, to the OP, I will note also that you can currently buy CF2018 licenses at 25% off from the makers of FusionReactor, at https://buy.adobe-software.com.

And while Adobe (and resellers) always offer a discounted upgrade price to the latest version from the previous one, when cf2020 comes out, that would only be available to those who have licensed cf2018, nor to those on cf2016 or earlier.

Hope that's helpful.

Thank you Dave_Watts and BKBK for that information.  Looking at the ColdFusion edition comparison matrix, at the very bottom of the document there are a few footnotes, one that I don't quite understand.  How is performance impacted by Standard Edition running only one shared simultaneous request througth the EFR compared to Enterprise, assuming, can run unlimited request through the EFR?:

"2. Restricted features in ColdFusion Standard Edition: Enterprise features run through the Enterprise Feature Router (EFR).  These features run in the Standard edition.  However, all features running through the EFR are limited to one shared simultaneous request."

When thinking about your applications are doing now, as well as what you may want them to do in the future, be sure to compare that list with the corresponding functionality in CF, and whether or not that functionality is limited to single-thread operation.  For us, PDF generation has become more and more of a requirement.  In Standard Ed., that is a single-thread task, which has forced us to migrate to Enterprise.  Yes, Enterprise has more features, but features that are common between the two version are, often times, more robust in Enterprise.

Your initial decision should be based on 2 factors: the requirments of the application you intend to build and how much you are prepared to spend on the software project.

1) Requirements of the application

As Dave has said, the requirements of your application are of fundamental importance. They decide whether you should go for the Standard Edition or the Enterprise Edition of ColdFusion. Size doesn't matter.

You may have just two developers and a dozen customers. But then, you happen to be a bank or stockbroker. The two developers are in charge of an application that analyzes millions of bytes of financial data streaming through the servers every second. Your application converts the bytes into meaningful information. Your customers are themselves banks or big investors. Your servers communicate directly with theirs.

If so then, chances are, your application relies on threading, messaging, APIs, multiple instances and failover clustering. These are capabilites that are absent from the Standard Edition. Hence your choice will be the Enterprise Edition.

Have a look at the comparison of the capability offered by Standard and Enterprise: https://www.adobe.com/products/coldfusion-family/buying-guide.html

2) Total project expenditure

Your project budget may comprise, for example, the cost of:

a) Software analysis and design
b) 1 or more ColdFusion Developers
c) Adobe ColdFusion software: the 2018 release comes in two Editions, Standard (US$2,499 per two CPUs) and Enterprise (US$9,499 per two CPUs)
d) Some Project Management assistance

Is the scope of the project large or will it likely get larger? Is the project critical to your business, now or in the near future? If the answer to these questions is yes, then Analysis, Design and Project Management will in fact be the more indispensable, hence, costlier tasks than software development.

This is kind of a tough question to answer with limited information, ultimately you'll have to decide this yourself. Key questions for you:

Do our apps use Oracle? Enterprise comes with DataDirect JDBC drivers for Oracle which are probably better than Oracle's own drivers.

Do we use any of the Enterprise features? PDF generation, API management, etc. I think the server monitoring may be an Enterprise feature now too. Look at the feature matrix for that.

Do we want to deploy CF within a customized J2EE environment?

What kind of hardware environment are we using? Enterprise lets you deploy multiple instances, which can help you take advantage of available memory on larger machines.

What would it cost us to deploy Enterprise vs Standard in larger environments? For example, you could deploy a bunch of "regular" machines behind a load balancer using Standard licenses for each. Enterprise may have different licensing allowances. (I don't really know the differences between Enterprise and Standard for multi-server deployment if there are any, consult the EULA for that and good luck with that! Someone here might have more information about that specific topic, though.)

Dave Watts, Eidolon LLC