Running JDE in the cloud - the true cost story

The low-down from our resident JDE guru Shannon Moir.

Start at the start 

It’d be a dangerous thing for me to give you a formula and let you go, as there must be a lot of explanation around a formula.  What I can do is tell you that the numbers I have are based on real usage.   Real production workloads of JD Edwards across a number of production instances.  I’m going to give you some high-level calculations that you can use to estimate public cloud costs. 

We all know that not all JD Edwards implementations are the same, but if you know what components affect pricing significantly and what components do not really affect pricing, you can start to narrow down what you need. 

I find that if you are new to AWS or new to JDE, it’s hard to know what to type into the AWS cost calculator.  I need to be honest, I’m not going to give it the title of simple, as the page title might state, it’s not that simple: 

It is a complex beast! 

Another thing that I want to explain up front is the difference between “lift and shift” and rearchitecting.  Lift and shift is essentially taking your on-premise hardware, making some space in the cloud and slapping it down.  This can be done with some pretty cool V2V migrations and you’ll be in the cloud quickly with minimal change.  Rearchitecting does come in many flavours, but it’s using more cloud constructs to make JD Edwards a better cloud tenant.  If you implement scalability, flexibility, advanced monitoring and insights – you will run JD Edwards much more efficiently than your lift and shift brethren.  The other bigger advantage that come from elasticity and flexibility is your capability to implement change and a much greater pace. 

Finally, you may read this as a homage to AWS (don’t get me wrong, I’d choose it if I get the opportunity), but this is actually a homage to public cloud.  The price points and architectural options are very similar between the large cloud providers and whether you are Azure, AWS, Oracle or Google – I think the lessons here are the same.

Some simple tips for beginners

• Initially price a “lift and shift or replatform”, don’t worry about too much rearchitecting for the purposes of pricing.
• If you want long term savings, do NOT implement a lift and shift. 
• The big hitters are RDS and EC2 you need to get these right 
• Make sure that your IOPS are right for your RDS, this is ALWAYS contentious.  If you have loose queries hitting the DB, you are going to soak up your IOPS quickly 
• Ingress and egress costs for JDE are minimal – like tiny.  I’ll provide some monthly stats, but that is not important for really accurate pricing (unless you are doing something really fruity). 
• EBS will add up, but again – disk is cheap 
• Architect for nightly shutdowns.  What I mean is if you can be granular about your environments, you can shut them down on a schedule and save lots of money.  More about this later.  You can still lift and shift and save a packet 
• Despite lift and shift, please architect over multiple Availability Zones, this will actually give you DR and HA in a single bound.
• Encrypt everything from day 1, some KMS charges
• Use a single account, please
• Use a single VPC, please 

What information are you going to need? 

It’s good to start with your current architecture, and lay this out as a replatform (note that this is NOT what I’d do, I’d implement lots of other cool things to save you a lot of money, but this is the beginners guide).  If you know the disk sizes, number of machines and stats, you can get a pretty good baseline for web and enterprise servers.   

You could also EC2 your database, but I’d recommend RDS because of the huge advantages in high availability. 

How many users is a great piece of information to assist with the pricing too, and any usage patterns that you have about your environments.  How often they are used, time of night / day etc – this is going to be very helpful. 

Would you like to know some real data? 

I’m in the fortunate position of knowing how much it costs to run JD Edwards in AWS for a number of clients.   

The raw data is good, but let’s look at price per page load (that is a good summary). 

The price for a page load ranges from nearly 4c to just over 1c.  This is a large range.  What I can say from these clients is that some are just beginning their cost rationalisation journey.   

The very interesting thing (for me), is that we can look at the price per hour of engagement, and the tables are turned completely. 

What can I say, running a JDE user is pretty cheap in the cloud.  Every client is less than 1 dollar a day to run their complete ERP in the cloud.  This is the costs of database, web servers, enterprise servers and storage.  A highly available and disaster recoverable environment in public cloud for less than $1 a day per user. 

Conclusion 

Whether you are a huge client with 1000’s of users or a smaller client with 100’s, you can expect to run a JD Edwards environment in the cloud for less than $1 per user per day (let’s assume 1 USD! For AWS pricing).  I do want to also reiterate that I firmly believe that I could get Client1 down to 20c per user per day – as I know that there is a lot I can do for this client.  The reason I can save much more money for this client is that they are setup to be elastic.  They are architected to be flexible, to choose an instance size that is appropriate for the time of day and retire this without any outages.  If you do not have flexibility in your architecture – then you might be on the upper end of the price points. 

There is a large difference between a rehosting vs. a replatform.   Please do not just accept a rehost or “lift and shift”. Ask for more from your partners (or perhaps ask Fusion5) to help you architect an environment that is going to provide you with some long-term savings.