The Amazon Web Services (AWS) cloud simply cannot be matched for geographic diversity as they have presence all over the world. In the US alone, they are located in the Eastern, Central and Pacific time zones. Other data centers are found in South America, multiple locations in Europe, Australia, Asia Pacific region and China.
This is very important because the hosting platform should be located as physically close to the potential customer as possible. When the data is located within the same geographic area, there is less latency when a customer navigates from page to page.
In the past this was accomplished by moving large images, CSS and JS files onto a Content Delivery Network (CDN) that has Points of Presence (POPs) all over the world. In this scenario only the Compute part of the process happens in a central location but all of the large content that causes the most end user lag is downloaded locally.
Some merchant websites have very large product detail images, and it’s very important to reduce the cross-continent traffic to hide the fact that a US based data center is used for customers in Europe.
With AWS, it’s possible to bring Compute closer to the visitor as well. For instance you may launch an instance in Northern California and another in Frankfurt and a third in Singapore. This way, in most place in the world your customer can always reach a data center within a couple of hops on the network without having to cross an ocean which introduces a lot of latency.
In a similar way AWS allows merchants to “spin up” new web servers in an instant. When running a sale or expecting a seasonal event such as Black Friday or Cyber Monday, we can add multiple new front-end web servers to handle extra traffic and then tear them down when the rush is over. Best of all, you only pay for the time that the resources were used, because all billing is done on an hourly basis. This is why people call it the “Elastic Cloud” because you can expand and contract it at will.
Due to the size of AWS, it’s trivially easy to add and remove servers of any size by building templates and relaunching them on differently sized Instances. Some of AWS customers maintain fleets of thousands of Instances, so a typical merchant with a dozen servers will never have capacity issues.
Other great features that AWS provides is removing the complexity out of technology. They provide Services rather than Servers. For instance, the AWS Aurora database which can be used by merchants to replace MySQL and MariaDB is only accessible as a MySQL client, not traditionally managed like a typical MySQL deployment. Everything is administered either through the AWS API or Web UI, logging into the server with ssh is not possible. This makes it far less customizable and more difficult to troubleshoot in case of trouble. But it also provides features such as no-impact snapshots, replication and failover.
The downside of Elasticity is that it’s very expensive. Since AWS has to maintain extra capacity for “splash-over” traffic, this cost is passed onto the customer during their every-day deployments. These costs are small when you are just starting up, but as your usage grows, the cost becomes very significant and then eventually prohibitive. Most merchants do not have large margins as they are forced by the market forces to compete on price, so when you pay a 50%-80% premium on hosting, it’s very noticeable and can cut into your margins. This is why we recommend that only high earning merchants with $30 million in revenue or more, consider hosting on AWS. By the time your hosting costs are a less significant part of your revenue, it almost does not matter where you host, all you care about is stability.
Hosting on real servers in a data center is the easiest and most cost effective way to gain high performance.
It’s effective because it’s simple. Each piece of hardware is dedicated to a single customer. You don’t have to time-share the CPU, RAM or disk subsystems between multiple users as is done on a public cloud such as AWS. The entire performance of the dedicated server, including the physical and hyper-threaded cores, RAM, network and the I/O (SSD storage) subsystem are dedicated to servicing only your individual website.
The best thing about working directly on hardware without layers of virtualization is that performance is extremely predictable. Variability in performance is greatly reduced because there is no contention from other users who may also be experiencing elevated traffic.
There are no artificial throttles to slow down processing during the times when you need the highest performance. The maximum performance of your hosting platform is available at moments’ notice, whether you are experiencing a small burst of unexpected traffic or you are regularly saturating any of the subsystems.
Physical separation also means a reduction in break in-vectors. Since most data theft on web servers happens when software vulnerabilities are discovered somewhere in customers’ software, having a smaller exposure area means less vectors of attack. There are no perfectly protected systems but it helps to have compartmentalization based on physical hardware barriers.
The disk read/write subsystem is typically the slowest part of any platform. It starts to slow down the entire system during peak times such as during database reindexing, inventory updates and incremental backups which should be happening several times each day to maintain transactional integrity after disaster recovery. These are challenges for merchants of all sizes but especially those with tens or hundreds of thousands of SKUs.
Overcoming this limitation is easy by to right-sizing customers’ deployments before it becomes a problem. Having access to physical hardware makes it simple to predict when the point of saturation is about to happen and give us enough time to be able to do something about it.
Because JetRails controls the entire hardware stack we pre-structure all customer deployments to be able to scale horizontally by adding more front end web servers when they are needed. To go from a single web server deployment to a 3-5 load balanced systems, takes only a single request and a couple of hours. And it’s just as easy to scale back down after a busy holiday season or a large sale.
|Consult a Specialist||See Our Solutions|
Expert advice, guidance and solutions from ideas to creation. Real transformations.
Read Case Studies
Changing platforms is only the beginning. Value added services keep you competitive.
Out-of-the box isn’t good enough for your investment. Discover your bottleneck.
Test My Site