The form contains errors
How much does it cost to run JD Edwards in the cloud?
The low-down from our resident JDE guru Shannon Moir.
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 to 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.
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.
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.
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.
We will get back to you as soon as possible.