The times have changed, for majority of PHP developers the norm used to be all about cheap shared hosting, we had godaddy, hostgator, bluehost, ipage. But times have changed, CMS and application development is going on different routes and if you are still looking at shared hosting to deploy that newly built api, application suite, you are not serious about your code.
Developing is only the first part of the journey, you should consider leveraging a good deployment environment along with a great workflow to save the time of you and your entire development team.
Shared hosting or anything in that nature will work if you want to play around, but for a commercial project consider using at least a virtual server. Read on to see why.
Criteria for Great Application Hosting
Location, location, location
Location of your application will play a important part for your audience. If you choose the right location, audience will see a considerable performance gain when they use your application. Say your application is targetted for south asian community, then there’s no point in hosting your application in a US based data center.
For Sri Lanka, from my tests the best place to host applications is Singapore.
To demonstrate this, if you ping sahanh.com which is hosted in Singapore, the latency is under 100ms. It’s good.
And if you ping laravel.com
This means, every request made to the website from any client (Browser), former wil have a ~80ms delay while latter having almost 4 times of that. This is just a ping test, so in real world the delays of database calls, script execution or worst case external api calls will add up to a request. Also keep in mind, a request will be a call to your script + assets (images, css, js)
Bear metal or cloud/vps?
With bear metal you are going to get limited to the physical hardware, application will be directly hosted within a physical server and since there are no middle layers for things like virualization (Hypervisor), you’ll get the most from your hardware.
With VPS, there will be performance bottlenecks COMPARE to bear metal, but in reality for most applications VPS/Cloud would be the ideal way to host an application. You get on-demand scaling, means you can increase the allocated RAM, HDD quickly than a bear metal server. Because in bear metal, a person physically has to add a new ram and that takes time.
Room to scale/Options
AWS, Google, SoftLayer/IBM, Azure, Rackspace the big players of the cloud market not only provide servers, but they have a huge catalog of solutions to cater specific needs. For example, AWS and Google has their own NoSQL solutions so developers can completely forget about the management parts and focus on just storing data and developing of the application. Read on to see what we can do with these offerings.
But providers like Linode, DigitalOcean only have virtual servers.
For business critical applications, the management is required. By default, almost all the providers provide un-managed servers. And 98% of cloud and VPS providers are offering servers without support.
Of course the hosting providers will need to handle the network, server up time and regular maintenance in a harware level. But once the server is setup, with un-managed support, you’ll get the full responsibility of management from the OS point. You’ll need to update the OS with security updates, firewall settings, or any application packages. That’s why servers get cheaper, specially the cloud ones.
Managed servers come at a cost, but you’ll get.
OS level management
Provider will take care of regular patching of the OS, server monitoring + customer support line. Even though with managed support, providers don’t provide application level support (like if you’re database query is not working it’s your fault), they will try to support as much as they can. Managed support differs from provider to provider, so it’s always better to do some digging before signing up.
Also typically server providers support common stacks like LAMP, but they won’t promise it in an agreement.
When you get managed support from a provider, typically they will provide a SLA (Service level agreement). With SLAs, if provider fail to meet a something that they promised during your subscription, they will do a partial refund. Each SLA is different and most common way is to reimburse with refunds. What this means is, even with managed support things can go wrong, but you’ll have commitment from provider’s end.
Building the best hosting environment
With above criteria let’s look at our options.
To host in singapore, below providers have datacenters in singapore.
- DigitalOcean (DigialOcean is using an upstream provider called (Equinix)
- Linode (Linode might probably be using an upstream provider, couldn’t find who they are)
- Rackspace (Rackspace doesn’t have a data center in singapore, closest is in Hong Kong)
All above providers support on-demand scaling. You can create a server with 4 GB of ram and make it 8 GB within few minutes.
Planning a scaling roadmap
Horizontal & Vertical
As you know, we typically get a single server and put our entire stack within that. Language runtim (PHP, Node etc) + the DB + HTTP server. But if you are planning a good amount of traffic upfront, breaking the application stack is the easiest way to scale. For example let’s say our application is hosted in a single server, the database, the http server and our application is sitting there. We get a traffic spike and our application start to crash. Now the thing is, most of the time it will be a single component that’s behind this crash, say mysql running out of memory. Of course you can add more RAM (that’s vertical scaling), but depends on the business need you can’t keep adding ram forever. Modern applications handle quite a lot of data, and do lot of processing, it’s always better to keep each component in a separate layer.
Imagine, MySQL running in a separate server. Now you have access to database layer on a separate server, you can bring another server and offload traffic to that. Adding more servers instead of adding more resources to a single box is called horizontal scaling.
But do we really need this?
Depends on your application, this approach will be an overkill. If you have no idea about the traffic, start from a single VPS. Scale from there. As experts always say, don’t do premature optimization. But keep the options in mind when things go down.
Scaling with cloud
Apart from on-demand resource increase capabilities (ram, hdd, cores) one more popular thing is to leverage hoted services. Each cloud provider comes with their own eco system. This works well for startups, for example if you leverage AWS Dynamo DB you can completely forget about database server management parts and focus on business logic. That’s a good call if you are already hosting within AWS. Google’s cloud platform has cloud databases. Our ultimate goal is to move quickly and outsource more operation overhead to elsewhere.
One popular offering of most cloud providers is the object storage. The popular guy in town for this is AWS S3. Remember we used to upload all the images to the public path of our application? we ain’t doing that anymore, instead its highly recommened to upload these to an external service like AWS S3 and storing in the URL within the app. Your application becomes more portable.
|Rackspace||Cloud/Bare Metal||Cloud Files|
|Softlayer||Cloud/Bare Metal||Object Storage|
Full services catalogue
- AWS – https://aws.amazon.com/servicecatalog
- Google – https://cloud.google.com/products
- Rackspace – https://www.rackspace.com/cloud
- Softlayer – http://www.softlayer.com
- Azure – https://azure.microsoft.com/en-us
Keep in mind, with hosted services you might go in to a vendor lock-in, so if you select dynamodb to integrate with your application, you can’t leave AWS without changing database engines.