Hosting Options. White paper last updated January 2013 For more information: Or get in touch:

Transcription

1 Hosting Options Or get in touch: 1

2 Introduction When building an infrastructure for your web application, choosing a hosting provider is an important part of the process. This decision is often rushed into without due consideration to the many variables that must be taken into account. In this paper, we will look at these variables in turn, explain some of the terminology and attempt to provide an overview of each choice. At the end, we'll present a set of structured questions which will help guide the decision-making process. Or get in touch: info@scalefactory.com 2

3 Type of hosting Diferent types of hosting options are available, each with their own strengths and weaknesses. Not all types of hosting suit all types of application, and should be considered on their individual merits. Shared Hosting In this hosting model, customers get access to upload software assets to a platform shared by a number of other users. This might be a standard LAMP web hosting stack, or it might be a specialist application platform like Heroku. The supplier takes care of uptime, performance, scalability and security. The customer has no direct access to infrastructure. Customer applications must follow certain development standards dictated by the host in order that they work on the shared platform. Or get in touch: info@scalefactory.com 3

4 Cloud Hosting In this model, the customer rents virtual server space often by the day or hour. Cloud vendors tend to be very hands-of: all payment and provisioning operations happen through a web control panel or set of APIs, with no human interaction. Billing is performed on an as-used basis. Cloud servers come with a default operating system install, everything else is then the customer's responsibility. Cloud vendors ofer only limited customer support. Shared server hosting like this can be subject to resource starvation from other customers' use of the hardware. Applications with very specifc performance requirements might not be a good ft for cloud hosting. Or get in touch: info@scalefactory.com 4

5 Managed / Dedicated Hosting In this approach, the customer rents one or more whole physical or virtual servers by the month from a provider, then takes responsibility for everything that runs on those servers. The hosting supplier ensures that the servers are powered, available on the network, and that hardware issues are taken care of. In some cases they may also take some responsibility for monitoring, backups and operating system security patches. Some suppliers provide private network interlinks between a customer's servers, and will not bill for network trafc between these. Some will also provide load balancing and frewall services from some central piece of infrastructure. Hosting with a managed hosting supplier may restrict certain infrastructure design choices, as these companies will constrain their ofering so as to ensure consistency across their whole server estate and make supporting it easier. Cheaper managed hosting contracts may not ofer 24x7 support, or any kind of emergency contact number. Or get in touch: info@scalefactory.com 5

6 Co-location In this model, the customer rents rack space, networking and power from a data centre, then buys and deploys their own hardware into this facility. Contracts tend to run for a minimum number of months, making this a long-term commitment. Most colocation providers ofer remote hands support, with some number of support hours included in the monthly fee, however responsibility for operation and availability lies entirely with the customer. For a modestly sized web application, the monthly operational costs of a single rack solution is broadly equivalent to hosting with a managed server supplier. Up-front capital expenditure is highest with this type of solution. It can be tempting to buy low-end servers when co-locating, however this may be a false economy. Cheaper hardware tends not to provide sufcient network or power redundancy, and ofers no remote lights-out management. Co-location ofers the highest level of control over the hardware solution, and is likely to be the right choice for applications with unusual hardware requirements. Depending on requirements and availability in a particular Or get in touch: info@scalefactory.com 6

7 location, a customer may choose to deal with their own network by running their own block of IP addresses and the routing associated with it, and buying bandwidth from one or more upstream providers. This may not be necessary in the majority of cases and customers may choose just to take a block of IP addresses from the data centre operator. There are data centre options to suit a number of diferent budgets. Cheaper data centres tend to ofer fewer connectivity options, be less easy to get to, and have a lower standard of security. They're also likely to have made compromises on the redundancy of certain power, cooling or network systems that will afect their ability to withstand certain types of failure condition, as well as require planned outages for some types of maintenance. The Uptime Institute have a set of evaluation criteria for data centres that allow them to certify a facility by tier. The criteria aren't published, but are well understood to be the following 1 : Tier I Single path power/networking, have minimal or no redundancy. Yearly downtime is estimated to be marginally acceptable for mission critical applications. 1 Source: Or get in touch: info@scalefactory.com 7

8 According to industry benchmarks, Tier-1 data centres generally provide 99.67% availability. (33.2 minutes of downtime per week) Tier II N + 1 redundancy on components, but power and cooling still provided through a single path. Planned maintenance may not cause downtime, but unplanned outages will % availability expected (25.2 minutes of downtime per week) Tier III N + 1 redundancy on components, power and cooling % available (2.02 minutes of downtime per week). Tier IV 2 ( N + 1) redundancy on components, multiple redundant power and cooling paths such that two paths can be simultaneously active at any time for continuous operation % available (just over 1 minute of downtime per week). Or get in touch: info@scalefactory.com 8

9 Availability / Disaster Recovery Most customers have an expectation that their applications will be constantly available, however in the majority of cases some periods of unplanned unavailability can be tolerated. For the majority of applications, a guaranteed uptime of anywhere above 99.5%, which permits 50.4 minutes of unplanned downtime per week, is likely to be sufcient, but for commercial or other reasons, customers may wish to endeavour to guarantee a higher level of availability. Most hosting providers will ofer an SLA of at least 99.99% (1.01 minutes of downtime per week) on their network and power infrastructure, and pay out a percentage of their monthly cost if they fail to meet this. Uptime is not the full story. It is important to consider Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) when designing a hosting infrastructure. These objectives defne, in a disaster recovery scenario, how long we are prepared to be without service for; and how much data we can tolerate losing. A number of approaches are described here. Choice of a specifc availability approach does not rule out any of the Or get in touch: info@scalefactory.com 9

10 hosting options we've already listed, but may restrict choice of vendor. Single Site Approach In a single hosting facility with of-site backups, the minimum recovery time will be defned by how long it takes to rebuild from scratch in a brand new hosting facility. Depending on the complexity of the infrastructure and the extent to which deployment is automated, the time taken here could be measured in the order of weeks, which could well be too long for most customers. The RPO will be defned by how frequently backups are copied of-site. Single Site / Cloud Recovery Plan A relatively inexpensive way to improve the RTO for a single site solution is to build a semi-automated recovery path using a cloud computing supplier. In the event of catastrophic failure, automated tools can bring up a replica of the infrastructure in the cloud within a matter of hours. This recovery mode needs regular testing (perhaps monthly, or quarterly in a slower moving environment) to ensure that it is always ready to be used. Or get in touch: info@scalefactory.com 10

11 Dual Site Active/Passive Similar to the cloud recovery plan option, in this model the customer maintains a secondary site in a diferent geographical location. This site contains either an exact replica of the primary site's hardware, or as much as is required to maintain a temporary service until the primary site is available again. In normal operation, the primary site is where all trafc goes. This then replicates application state (database or fleserver content, for example) to the secondary location. If the primary site fails, the application is started in the secondary site, and DNS changed to send all customer trafc there instead. Live data replication to the secondary site means data loss can be minimised. This model appears wasteful of resources, however the secondary site can also double up as a staging or operational test environment. Dual Site Active/Active For the ultimate in availability, it is possible to serve some applications simultaneously from two or more data centres. If a pair of sites are less than 100km apart, and connected by a dedicated fbre network, databases and flesystems can be Or get in touch: info@scalefactory.com 11

12 synchronously replicated, and one site can use services in the other with minimal latency. This approach requires some form of global load balancing DNS solution, or use of anycast IP addressing, and these introduce additional operational complexity. Or get in touch: 12

13 Support One key diferentiator for hosting approaches and organisations is the level of support on ofer. Depending on the customer's own level of internal technical expertise, more or less support may be required. Most co-location providers ofer 24x7 access to their facilities in case their customers need to swap failed hardware. They also provide remote hands - access to an on-site engineer to perform reboots and similar on demand. An on-call network engineer may also be available in the event of network trouble Managed service providers generally ofer a support desk, but this may only be available during extended hours to customers paying a support premium. Support may only extend as far as the operating system, and not to any of the processes that run to make an application work. Cloud providers ofer a selection of commercial support plans, with costs increasing with level of service and speed of response. Third party service management companies may ofer to support applications running on other companies' infrastructure. Or get in touch: info@scalefactory.com 13

14 Providers may ofer a service level agreement on turnaround times for support issues, and this might vary depending on severity of issue, afected component, level of support or time of day. Support is a multi-layered concern, with each of the following needing some level of support: Customer apps Your Ruby/PHP/Java application itself the user facing components of this infrastructure. Infrastructure Software Database software, application containers, cache services. Operating System Virtualisation Layer Physical Hardware Network Data centre Linux itself, package upgrades VMWare, Xen etc. Servers, disc arrays, switches Internet connectivity, routing, frewalls, load balancers. Power, cooling, physical security Or get in touch: info@scalefactory.com 14

15 Elasticity Diferent applications have diferent workloads. Sites built for television shows, for example, can have extreme peaks around their time of broadcast. E-commerce sites are often busier in the weeks before the holiday season. One consideration when choosing a hosting approach is their level of elasticity. Elasticity is the ability for a supplier to add and remove server capacity on demand. Not all applications can scale this way application components which store state often can't easily scale horizontally, and traditional relational databases generally can't. If the bottleneck in an application is database performance, being able to deploy new application servers won't help, and could well make things worse. Cloud vendors are the most elastic available new capacity can be added within minutes, and automation tools exist to fex capacity up and down in the event of changes in resource consumption. Managed server suppliers generally keep spare hardware onsite and can often turn around increases in capacity within a couple of days. This may be sufcient if it is possible to predict Or get in touch: info@scalefactory.com 15

16 an increase in demand, such as around a specifc event or time of year. In the co-location model, to be sufciently elastic, it may be necessary to buy and rack spare hardware, and keep it powered of until such time as demand increases. Or get in touch: info@scalefactory.com 16

17 Security Most typical managed server hosts use a hard shell, soft centre approach to network security they use a perimeter frewall to prevent access to services other than those which are intended to be exposed to the outside world. This is sufcient for the majority of standard, public web applications buy may not be enough for some clients. Depending on the customer's requirements for data security, a multiple security zone approach to networking might be required. In the case of sites handling credit card details, PCI- DSS standards may need to be adhered to. Not all hosts will be capable of supporting all security approaches. With colocation, there's no real restriction on how you lay your network out, but if PCI-DSS is a requirement, the physical security of the servers will be an auditable concern. Some cloud suppliers allow confguration of sophisticated security groups, others have less fexibility. In a managed hosting environment, it may only be possible to have a single private network. In this case, per-host frewall rules can be used to create security groups, but this may not be sufcient if following security guidelines which require a Or get in touch: info@scalefactory.com 17

18 physical frewall device to be used to segregate network regions. Or get in touch: 18

19 Compliance Some customers, particularly those working with large, established businesses have specifc requirements around standards compliance. Organisations making use of ITIL practices will often require similar practices from their suppliers in order to maintain a consistent approach to service management. Some managed hosting providers use ITIL internally, Some organisations may require accreditation to ISO 9001 (Quality Management System) or ISO (Information Security Management System). Auditing to the standard of that accreditation is signifcantly easier if using suppliers who are themselves accredited, and this may infuence choice of supplier. Or get in touch: info@scalefactory.com 19

20 Making a Decision Application Type Which of these bests describes your type of application? Type Predominantly read-only (eg. content management system) Transactional (eg. E-commerce, online survey) Predominantly write (eg. Advert click-through logging) Availability: What is the minimum level of availability that your application can realistically cope with in the worst case? Availability Downtime / week Downtime / month < 99.5% > 50.4 minutes > 3.6 hours 99.5% 50.4 minutes 3.6 hours 99.9% 10.1 minutes 43.8 minutes 99.95% 5.04 minutes minutes 99.99% 1.01 minutes 4.32 minutes % 6.05 seconds 25.9 seconds Or get in touch: info@scalefactory.com 20

21 RTO In the event of catastrophic failure, how long are you prepared to have your application unavailable for in the absolute worst case? Unavailability This application cannot stand any unavailability at all A couple of hours' unavailability isn't the end of the world As long as we're back up within the week, we can cope The application could be unavailable for any amount of time without any real concern. RPO In the event of catastrophic failure, how much data loss would be problematic in the worst case? Data loss We must never lose any data at all Loss of a few minutes' data wouldn't be so bad Loss of up to an hour's data is acceptable Loss of up to 24 hours of data is acceptable Or get in touch: info@scalefactory.com 21

22 Demand: Which of the following is your expected application usage pattern? (one or more may apply) Pattern Consistent usage at all times Consistent usage during ofce hours Modest daily peaks of activity Occasional very high peaks at predictable times Occasional very high peaks at unpredictable times Seasonally variable demand (eg. Increase at Christmas period) Geography Which of the following best describes where your customers are located? Location Our customers will be primarily in a single geography Our customers will be in some known number of areas Our customers could be anywhere in the world. Or get in touch: info@scalefactory.com 22

23 Support Which of the following components are you happy to support using in-house resources? Components Customer apps Infrastructure Software Operating System Virtualisation Layer Physical Hardware Network Data centre Is it important that external support organisations follow an ITIL based service delivery model? ITIL Yes, all support ofered must be within an ITIL framework ITIL would be nice, but we're not wedded to it No preference Or get in touch: 23

24 Compliance Are you required to comply with any particular standard framework? Standard We have no requirement to conform to any standard We are required to conform to ISO 9001 We are required to conform to ISO We are required to conform to PCI-DSS We are required to conform to bespoke standards dictated by our organisation, or by our customer's organisation. We are required to conform to a standard not listed here Or get in touch: info@scalefactory.com 24