"Sorry, that's a server problem."
At some point in your relationship, your developer might tell you – a less technical person – that the bug you have raised is a server problem, and that they cannot take responsibility for it.
You may find this response dismissive, but it's important to understand that developers are no more server administrators than sommeliers are winegrowers. Their trades overlap, but a developer cannot be expected to have the same level of server know-how as someone who does it for a living – though most of us are pretty good at Googling our way to a solution.
If a bug is the result of a server problem, it means that there is nothing wrong with the actual code that drives your website, but rather the environment that supports it. The smooth running of a server requires the correct configuration and monitoring of thousands of settings – your website is a bit like a baby floating around in a temperamental amniotic sac.
This article will explain what a server actually does, and why it's important to invest time and money into picking the right hosting solution for you.
What exactly is a server?
Imagine that you are in a restaurant. You order onion soup. The waiter relays this request to the kitchen, and within 20 minutes you are served the dinner you expected.
In this scenario, the menu selection you made is the website's address – like
http://www.3sixty.co.uk
. The waiter is the way that you communicate with the kitchen, which represents the server. The kitchen interprets your order, performs the tasks required to produce onion soup, and returns your order. If they've run out of onion soup, they will send the waiter back to your table to inform you. This would be the equivalent of a 404 error (page not found).
Every time you make a request – for brown bread instead of white, for another bottle of wine, for the bill – you are sending requests to a location (like a kitchen) that understands what you want and returns a result via the waiter. This is where servers get their name – they serve content back to a user based on requests made of them.
Any computer can become a server – and like kitchens, they can be late-night chip shops or Michelin star restaurants. Either way, they are machines that sit in dark, cold rooms and, all being well, do as they are told.
What is the difference between a website and the server it is hosted on?
A server hosts a website. In fact, a server can host several websites – thousands, if it has the capacity.
If a server 'hosts' a website, it means that the files, logic and databases that make up the website live on that machine.
Let's go back to the kitchen. The staff and produce represent your website. You rely on their expertise to process the ingredients and produce the results that the customers expect. Without them, the kitchen is just a room.
The kitchen gives the staff the tools to do their job. Factors like the quality of the utensils, the temperature of the oven, and whether or not the architecture allows the waiter (or 'Internet connection', in this metaphor) easy access to the chef all affect the performance of the kitchen. Developers are equally dependent on their client's chosen hosting solution. Let's look at some examples.
Too much traffic!
The restaurant is full beyond capacity. Orders are coming in at an alarming rate. The present kitchen environment only allows the staff to process 50 orders per hour – a more advanced kitchen would allow them to manipulate the space-time continuum, slow time down for the diners, and double their productivity. As things stand, orders are missed or take ages to come back to the customer.
This is pretty much what happens when a server experiences a sudden, unexpected spike in traffic. If the bandwidth and processing power are not sufficient to deal with the amount of people requesting to view a particular website, the server will fall over.
Airports in particular need to think very carefully about the hosting solutions they purchase, as they need to be able to handle huge spikes in traffic during an emergency, but don't necessarily require that kind of power for more than a few days of the year.
Configuration
The oven stops working. Nothing that needs to be cooked in an oven can be served. Roast chicken, Beef Wellington, and cheese cake are out of the question. Hundreds of things can break down or malfunction in a kitchen, and the same is true of a server.
Hosting a website isn't as simple as uploading some files and hoping for the best. There is quite a lot of configuration to be done – you may have heard developers talk about IIS, Apache, permissions, rewrites, ports, and more. Without proper configuration, any one of these things could stop a website from working. If a software update (servers are just computers, after all) changes the security settings on a particular file, rendering it inaccessible to the website's code, it will crash. If port 80 is not open, nobody will be able to access your site. Sometimes, websites can 'hang' – just like regular computers lag for no apparent reason. It all depends on the quality of your server, and the people that maintain it.
What should I think about when picking a hosting solution?
Servers are more than just something you buy and forget about – especially if you don't give your requirements enough thought before picking your hosting solution.
More often than not, the developers you work with will have a favourite hosting provider that they will recommend – they will usually be managed hosting solutions, meaning your money pays for a specialised team of people to take care of the server for you. With the right hosting provider, things might break and be fixed before your users even notice.
Here are a few things that you should think about before settling on a hosting solution. Have a read through, and remember to involve your developers in this process – they will have a better idea of what your server requirements are going to be.
Scalability, bandwidth, and server load
How much traffic are you expecting per day, and will your server need to be able to handle unexpected surges in traffic (for example airports or news websites)?
Environment
What is your website built in? Consult your developer, and make sure you haven't purchased a Windows server when you needed Linux.
Up-time guarantees
Does your hosting provider guarantee that your site will be up and running 99.9% of the time? What happens to your website during server maintenance? Does it go down for half an hour?
Backups and redundancy
How often is your data backed up? How quickly can it be recovered? Is off-site backup (copies of your data in a completely different location) available?
Support and maintenance plans
Personally, I think this is one of the most important factors to consider when choosing a hosting company. Do they offer 24/7 support? Do they perform proactive maintenance (a bit like checking cholesterol levels on a regular basis)? Read through the service agreement very carefully – make a point of asking what it does and doesn't cover.
Remember that you have a direct relationship with your hosting provider – you are their client, not your developers. If you do not want to liaise directly with your provider, ask your developers if they would be willing to draw up a support contract that makes them responsible for that relationship. Again, you need to consider what happens outside of office hours. If your site goes down in the middle of the night, are the developers contractually obliged to get out of bed?
It's important to define where the responsibilities lie. You could have a heavy-weight champion of a server, but that doesn't count for much if you don't know who to contact when it misbehaves. In an ideal world, server problems are resolved by a geeky exchange between developers and server administrators before you've had a chance to raise the bug yourself, but it's up to you to make sure that these agreements have been set up before they're needed. In a busy kitchen, you would keep your warranties up to date and have a repair service on speed dial – your server setup is no different.
At 3Sixty, we have clients that leave their server support to us, and others whose IT departments prefer to take on the responsibility themselves – it's entirely up to you. The important thing is that you have some idea of what a server does, what is involved in maintaining it, and who is responsible for what. Giving these questions proper thought will save you a lot of pain when your homepage is replaced by a yellow error message at 2:30am on a Saturday morning, and a programming error is not to blame.