Everest Software Deployments

Let’s start by defining what these 2 options are.

Virtualized environments are where organizations invest resources/dollars into one big server. Maybe an eight (8) core server with say 2.4GHz processors, with 96GB of memory and 1 TB of disk space or more on an SSD RAID 5 / RAID 10 array. Sounds like a decent hardware environment to run everything on EXCEPT that server is likely to cost something in the neighborhood of $15,000-$20,000 by the time its all done AND:

• database servers need disk speed & fast memory access, better yet, hardware layer memory access to SQL temp DB’s.
• web servers need fast disk speed & fast CPU’s/processors (and in some cases many of them) or the server load balanced for scalability.
• Everest application servers need mostly memory and some CPU however there is little to no disk operations to create latency.
• Everest end-user clients which actually physically “use the software” … they need ~500GB per user profile (if using RDP) for Windows resources + Everest usage needs if a heavy user. Moreover, the end-user clients really need CPU speed, the faster the better. In a study conducted by MARTEC360 for a client moving from their local environment to our Private Cloud for Everest, we were able to speed up the client by over 227% by simply increasing the clock speed on the RDP client-server.
• and you still need local IT which fully understands the 3 tier architecture support needs of the system and how to optimize each server for their respective performance needs.

In a Private Cloud environment such as the fully managed solution MARTEC360 has put together for clients – the entire eco-system is rolled out in a virtual private cloud. In our case, we have partnered with Amazon Web Services (or AWS) as our backbone. The benefits of going this route from a performance and optimization perspective are considerable:

• each server can be spun up (created) to serve its specific role.
  • you do not need to pay for “extra” utilization for an Active Directory server or a file server when those can be inexpensive T2-Large devices (approximately $80 a month before storage) or even less on the hardware side.
  • a database server could have something like a Z1D or M5D class which is highly tuned for SQL
  • an application server can get its needs met without needing the disk speed, CPU or memory requirements necessary to meet the SQL demands
  • an end-user client RDP server can go light on disk speed, fast on processor with the necessary memory limits based on what’s needed for your # of users
  • if some of your end-user RDP clients need super fast access and the others can live with 2-4s longer lag, no problem, bring on a super-fast client-server for those which need it and have a T2-Large for those users which do not require blazing speed.
• you can easily scale from SQL Standard Edition (which has a 32GB memory limit) to SQL Enterprise without having to “rebuy” the software all over again if/when your needs grow.
• you have a team that doesn’t work after 6 pm and before 6 am on client/application servers? Cool … in an optimized private cloud environment we can auto disable those servers during the off hours. What does that mean? It means you just cut your bill in 1/2 for that server each month because for the hardware you’re only billed for when it is “on”. It is a consumption model.

In Summary:

While virtualizing is better than nothing. The cost certainty, total-cost-of-ownership (TCO) and ROI of moving your ERP eco-system into a professionally managed private cloud with the redundancy and scalability options which it brings is the #1 reason why a private cloud environment should be more strongly considered vs investing in your own on-premise virtualized server.