Why ATG’s Core Based Licensing is Stupid

ATG, like most enterprise software companies started by licensing their product based on how many CPUs you ran it on. Back in 1999 this was a pretty fair way to do things. It meant that big companies running a very high traffic site on a big Sun E4500 or E10k paid a lot more than a smaller company running on a pair of E450s. They handled more traffic and hence ideally made more money off of the site, and therefore paid more. Overall it was a decently fair model, and very easy to enforce in the software. Upon startup the software checks to see how many CPUs the server has and checks that against the license file and only starts if the license file matches or exceeds the CPU count. Makes sense, right? Most folks were doing the same thing at the time.

One aspect of this system is that year over year, as processors got faster and faster (from 250 MHz to 480 MHz for example), you got more power for the same licensing cost. In generally this was partially or fully offset by the increasing complexity of the software you were running, but worst case scenario it kept you from LOSING request handling ability over time, and best case scenario you were able to increase your traffic handling ability a bit, as Moore’s law drove clock speeds up.

On the chart above you see the green line which is the number of transistors on a CPU growing just like you’d expect from Moore’s law. This line can be thought to translate roughly to performance, and has been on this trend for over 30 years.

However, the blue line, which is clock speed (MHz or GHz) does something very odd around 2003. It flattens out. What happened?

Processor design changed. Due to some limitations in our current chip technology, going faster and faster (and smaller and smaller) couldn’t keep happening due to some physical and quantum limitations. So instead, companies like Intel and AMD began designing and building CPUs that had multiple “cores”. They went wider instead of faster. Basically each core is like a mini-CPU that, if your software supports it, means you can get more work done per second without having to have a faster clock speed.

Instead of a CPU with a single 3.4 GHz core, we have a CPU with four 2.66 GHz cores. Now keep in mind that the actual useful performance of the CPU kept climbing as it has for the last 30 years. It’s just that instead of faster clock speeds, we moved into multiple cores.

The problem is that software reports each “core” as a CPU. That means a server with a single quad-core CPU appears to be a 4 CPU server. That means CPU/core based licensing now costs FOUR TIMES AS MUCH as it did last year for the same request handling ability. We’re not taking hundreds of dollars here. We’re talking hundreds of thousands or millions of dollars for each customer.

To make matters worse the latest generation of CPUs, Intel’s Nehalems, use something called HyperThreading to make each core do more work. The upside is this generation of chips performs better than the old ones, as they should. The downside is they now report as twice as many actual cores, due to the HyperThreading. A quad core single CPU now reports as 8 CPUs. You can disable HyperThreading, but that actually introduces a 20-40% performance penalty (depending on how you benchmark it, etc…), so in most cases you’re actually getting LESS performance than you did from last years chips. At that point you can either cough up another $500,000 in license costs, or have your brand new server be slower than your old one. Great options.

Fortunately most companies saw this issue when it first reared its ugly head back in 2003, and have moved to socket based licensing. They are basically licensing the same way they always have, just redefining the CPU as the “socket” or the physical spot on the motherboard the CPU plugs into, and getting away from things like cores, hyperthreading, and that whole mess. Customers of companies which made that change (such as Oracle, JBoss, and many others) essentially end up paying the same as they always have, and everyone goes home happy. The licensing cost/performance curve for those folks has stayed pretty stable over the past 10-15 years.

Unfortunately ATG has not changed their licensing at all. This means that ATG customers are paying 4-8 times as much for licenses than they would be in 2002. And it’s only getting worse. Processor design is continuing to go wider not faster, and ATG customers will continue to be massively penalized by this CPU architecture trend.

I’ve spoken to many people at ATG, and the response is generally the same: “We understand what you’re saying, we are aware of CPU architecture changes. But changing our licensing is a big deal and takes time to do right.” Okay, I buy that. You’ve had SEVEN years so far! This has been a growing issue since ~2003 and one that pretty much all the other players in the space have handled since then.

It’s getting harder and harder to get dual core CPU servers, and pretty soon you won’t be able to get anything smaller than a Nehalem quad with HyperThreading. This means that out of the box, if you want two small servers (for redundancy) you will need 16 cores of ATG Commerce licensing. That’s millions of dollars. If you disable HyperThreading, and take the 20%+ performance penalty, you “only” need 8 cores of ATG Commerce licensing. That’s still probably close to a million dollars (I don’t have actual costs handy). Not only is ATG penalizing all of their existing customers, but they’re really forcing themselves out of the mid-market they are trying to target.

The ATG “starter” bundles are becoming impossible to implement due to this as well. “two cores of commerce” means you can run a single server, which doesn’t offer any redundancy. “four cores of commerce” means if you can manage to find new servers that still have a single dual core proc available, you’re limited to really old and slow chips. For instance, looking at available single processor servers from one major hosting provider, the “best” dual core you can get is a Xeon 3060 dual core 2.4 GHz with a 4 MB cache and 667 MHz RAM bus speed. The best single single processor available is a Nehalem 5570 with a quad 2.93 GHz HyperThreaded chip with 8 MB caches and 1333 MHz RAM bus speed. Real world I’d expect the Nehalem to deliver at least four times the request handling ability as the 3060, if not more. If you’re using Oracle, JBoss, or almost any other piece of enterprise commercial software out there, you, the customer, can leverage the best hardware and get more bang for your license buck. You can upgrade and quadruple your real world performance for free (like you’ve been able to do for years and years). If you’re on ATG, the modern server will quadruple your price instead.

So if you’re an ATG customer, ATG partner, or ATG employee, be aware of this issue, and try to get ATG to adopt socket based pricing. Thanks. Exponentially increasing software costs hurt the customers in the short term, and will hurt ATG in the long term.

11 Comments

This is a great article Devon and pretty much dead on in terms of the issues facing ATG right now. I think that the socket approach makes the most sense as well and it doesn’t really “change” the license model that much, although from a company perspective, they would need to change the cost of a socket.

The difficulty comes in getting your BATNA out there if you are ATG. The best negotiating approach for them is to look at volume based pricing and bundling in order to offset their cost of sale and not let software out the door for a price that will hurt them in the future.

If I look at the 16 core model (I have some cost ranges on that depending on volume based pricing), you are looking at between 800k and 1.2MM for ASE + commerce. This should allow you redundancy of 2 servers running the Nehalem processor. I see this as more of a “starter kit” of 2 “sockets” which should go for between 400-600k depending on volume discounting for this piece. This would essentially cut revenue in half though due to hyper threading, but at the end of the day it probably wouldn’t.

I think people are going to spend what they are going to spend and increasing your commerce software sale for additional processing power can always be made if you utilize the volume discounting approach.

So, if I were to go with 2 sockets at 600K or I could up that to 4 sockets applying a discount for a larger purchase at 800K. If I throw in a small bundle of ATG Recs and CA and CSC for 200k, I am still at a 1MM software sale and everyone wins.

Great comments Devon and Mike, pretty much summarizes a more general view I’ve seen on ATG licensing in the industry.

I favor the business/transaction volume based model over anything that ties licensing down to sockets or cores. ATG commerce implementations are fundamentally different based on the type of business that they support (cater to different assortments, conversion ratios and fulfillment models) and my experience is that at large scale – a commerce implementation is more memory and instance(jvm) bound than CPU bound – this forces one to compact multiple instances per socket/core (there are limits to how far that can go) and eventually allocate more hardware/sockets.

Most large scale commerce implementations end up under-utilizing the CPU due to this and eventually requiring more CPU/cores than what’s needed for true request processing – eventually driving up license costs. Hence tying up licensing to sockets puts a customer organization at a significant commercial disadvantage – especially the ones that have to support a large number of sessions (low conversion)

I’ve often wished ATG would offer a model based on a percentage of transactional revenue on the site. This would let the smallest mom and pop site use ATG and would scale up pretty well even to the huge players. I’m not sure how difficult it would be to implement in a way that wasn’t easily circumventable (since you need to allow folks to add custom payment processors, etc…) although realistically it’s all sort of on the honor system even now. The flip side of that is you still have to bill for support differently, as staffing to provide phone support to a client who pays you $10/year is a whole other barrel of monkeys.

I put forth the socket pricing because at least it’s inline with the other vendors you’re likely to deal with (RedHat, JBoss, Oracle).

Really interesting article and discussion Devon. And I personally believe that most of the future licenses will be based on a percentage of transactional revenue as more and more SaaS ecommerce solutions and providers will pop up, the competition will get worse and eventually either they will have to change their licensing policy to stay competitive, or they will start loosing customers imho.

Thanks! I’d love to see ATG sell based on a %, but that’s hard to enforce as many customers end up rolling their own payment integrations or heavily modifying the OOB ones. The other problem is that they’d still have to bill for support, as that can be a big cost center on a platform as complex (and dare I say it – poorly documented) as ATG is. But there’s no real reason support costs would scale with the number of CPUs/Cores a company ran on, so support could be a fixed per customer annual fee or something along those lines. We’ll see.

Love the rant, but sorry to say that Oracle still charges per core. At least for the app server and the database. I am just writing something for my own blog about this and did some searches to see what others already wrote. So I ended up here. I think licensing should be on a per usage basis, e.g. occurrences of use or amount of transactions.

Oracle Standard is thankfully socket based, although you’re right Oracle Enterprise is core based, although at least they have a core multiplier, so you aren’t paying full price per core.

The problem with transaction based is there are some applications which will run a high number of transactions but they could be very light or async and don’t need a ton of HW, and/or aren’t related to making any real money, etc… It’s a tough one. ATG, being primary an eCommerce platform could charge based on on-site annual revenue, which would scale nicely and be pretty fair.