Cloud and Web Hosting
Frequently I stumble
with customers that are torn, or don’t know whether to host their project on
the cloud or with a web hosting. So with the objective of clarifying which path
to follow, lets compare those two worlds. The following will try to help non technical people and developers alike, while they don’t speak the same language, they
both need each other, especially when starting a new project.
The Cloud
While the cloud is very popular today, let start by defining it, which is quite simple. In the beginning on the networking world, every other equipment that it wasn’t in your premises was pictured -literally- as a cloud. Signifying that you didn’t care how communications went there, you just cared the info (network) was there and it went where it was supposed to be sent. As such, the internet world stole the cloud concept and now it uses it to describe the same objective: You -as a user- don’t care the technology or platform behind it, you just send it there and benefit from what it offers.
Web hosting
In the begging on the
internet, a server was an expensive computer. Since that time, a server could
host multiple web pages from multiple accounts. That’s the concept behind web hosting: A company or a user leases a space in that server in order for their
webpage to be hosted there. It is a shared space, with the advantage of
lowering cost and simplifying maintenance. The user/company of that hosting
space doesn’t have to worry about maintaining the machine, they just use it and
that’s it! On the down side, because it is a shared machine, there are
constraints on what it can be deployed over this server. Those constraints
might be security related, an specific functionality or feature not available,
or simple load times.
The cloud today
First servers became cheaper and cheaper, second companies like Google, Amazon and Microsoft needed to have thousands of servers in order to run their business. However, because those servers were there in order to handle peak loads, what about the time of valleys in load? Thus, the cloud was born. Amazon started renting that computing power it had to spare, while their machines were almost idle. And because it was a gigantic amount machines, renting those use was really cheap. That’s the chore of what is a cloud service today, and because it represented a business in itself, now that extra capacity isn’t just shared, it is the objective. Amazon store back-end became Amazon Web Services, Google search engine massive deployment paved the way for Google Cloud Engine, and Hotmail and Bing help the inception of Office 365 and Azure.
Challenge
|
Cloud
|
Web hosting
|
Setup
|
Easy
|
Easy
|
Deployment
|
Easy
|
Easy
|
Maintenance
|
Depends on the service being used in the cloud provider
|
Easy
|
Security
|
Hard
|
Easier
|
Scalability
|
Possible
|
Impossible
|
Initial cost
|
More expensive
|
Low cost
|
Dependence
|
Code/setup will be married to the exact cloud provider. Moving
out of it is neither cheap nor easy
|
Code/setup is independent of the provider. Moving out is a
non-issue
|
Mobile services Integration
|
Easy
|
Non-existent
|
Coding (feature) flexibility
|
Complete! Do what you want!
|
Limited to what the web hosting allows
|
Nuances
Maintenance: With web hosting, maintenance is
straightforward as you only maintain the code of the app, server patches
(including security) are out of the customer (business owner) jurisdiction. So
no worries about that. For the cloud, maintenance will be directly linked to
which service of the cloud the app/website is using. If the app is using
Software As A Service (SaaS), makes maintenance easier, as it is a service
similar as Web Hosting, only with steroids. On the contrary, if the app is
deployed by using virtual machines on the cloud, all the security (hardening)
and server patches will be a direct responsibility of the business, not the
cloud provider.
Scalability: This is tricky, rule of thumb: It’s better to
start small and later grow. The development team can make an app that can
scale, but this will come out as cost of development. The app is beautifully
coded to allow heavy load, however the business is not bringing that load, then
the business will end up paying for an app that was over dimensioned. While the
risk of under dimension always exist, it is better -business wise- to build an
small app, which will have lower developing cost and if the case comes that it
needs to handle more load, well, that’s a great problem to have! Ask the
Twitter whale about it! Besides, thanks to the enormous amount of computing
power available today, an small server or a single web hosting account might be
able to handle that load easily. It all depends on the app functionality.
Initial Cost: Similar to scalability, using web hosting is
by far the lowest cost of deployment, as long as the app requirements allows
the use of shared hosting. Not all of them allow that.
Today many developers will default on using the cloud first,
even though they’re making an small project that easily could be hosted on a
shared hosting. Once delivered, then it becomes an operational cycle for the
business, but the business ignored these challenges from the beginning.
One last thing, a website is not necessarily an app. If all
that you need is a website, then a web hosting will do the job with the lowest
cost and complications. We in Mollejuo apply a hybrid approach: Our website is
being hosted on a shared account, with e-mails. And our back-end is hosted in
the cloud. By doing that we have the best of both worlds.
No comments:
Post a Comment