MARTEC360 Private Cloud for Everest and Other Business Systems

Over the past 20 years, the team here at MARTEC360 has partnered with various co-located and dedicated hosting facilities to implement and provide Private ERP Cloud Hosting. We have experience working with Rackspace, Amazon Web Services (AWS), Total Server Solutions, Peer1, Godaddy, Dedicated Server Farms, Colocated Server Farms, Virtual Servers, HyperV Servers, VMWare Servers and lastly working with “in-house” IT resources of clients to ensure that stability, security and scalability were never in question.

After experiencing the best and worst that many of these partners delivered, ERP customers were demanding that it become easier to know where to go to for “support”. The result of this is now a fully managed MARTEC360 Private Cloud environment whereby you can have your ERP & eCommerce environment in the cloud and not need to worry about security, updates, scalability, backups and where to go to for “support” for if/when you have a problem. All of this provided by engineers with 20+ years of datacenter, ERP and eCommerce experience.

Private Cloud & Managed Server FAQ’s

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 $10,000-$20,000 on a server See Example 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.

Everest ERP versions 4, 5, 6 and 7 are all supported in our environment by our team of engineers in the MARTEC360 Private Cloud. This can range from single server very small environments for companies with less than 5 employees/users to organizations with 50+ users distributed across multiple application servers and client servers.

A typical one (1) server environment with monthly maintenance and management starts around $1,000/mo. The price will vary as the costs are calculated based on specific user requirements. A few of factors which go into the specifications are: how many CPU cores needed, how much memory is needed, how much storage is needed, is eCommerce involved, is marketplace integration involved, how many 3rd party connectors are used (such as e-bridge, wms, crm, sdk/api tools), how many employees access the system, is Outlook or any other back-office software required on the server?

Have your own SQL, RDP or Office licenses? Bring them with you and provide the copies to the MARTEC360 account management team during on-boarding and it can reduce software licensing fees.

This can take a little as a couple days and as much as a month depending on the complexity of any customizations you have, level of documentation for said customizations or size of the environment.

Depending on version of Everest this changes.

For version 5.x & 6.x, Everest 2008R2 Server Standard Edition or Enterprise/Data Center Edition. SQL 2008R2 Standard or Enterprise.

For Everest 7.x and above, Windows 2016 Standard, Enterprise and Data Center. SQL 2016 Standard or Enterprise.

If one is looking for more than 32GB of memory support (larger database sizes, larger numbers of users, or targeting faster performance) then the Enterprise and/or Data Center editions should be considered.

Through extensive optimization and testing spread across a variety of accounts over the past 20 years, MARTEC360 has settled on Microsoft Remote Desktop Services (RDP) as the primary remote configuration for all versions of Everest. Additionally, with the remote application deployments (part of RDP), so long as a user does not need the Outlook interface for mailing documents from Everest, then the “Client” can sit via RemoteApp on ones remote workstation and communicate efficiently with a cloud/wan deployment.

While a number of organizations have attempted to roll out Citrix remote deployments, the speed and performance in the client application layer is deprecated too greatly to consider it a viable solution.

We have run into this question or concern a lot. The answer is it depends on what is happening in the environment and the business.

  • For each 20-25 concurrent users, we find that it is best to silo them onto a separate application server. This is typically by department so that should one department have an application error, it impacts them only – not the entire organization.
  • If there are 3rd party integrations in play such as FoxFire WMS, TrueCommerce EDI, KnowledgeSync CRM (CRM Studio), other integrations or SDK/API applications performing extensive automation capabilities then we strongly suggest they be on their own application server. This is so that should these components/solutions have a problem they are isolated from the application servers and client users … similarly, if the application server(s) being used by clients have any type of problem it doesn’t adversely impact the SDK/API integrations.