Server Offering

1. Types of servers

We like Linux Ubuntu cloud based servers with native MySQL databases. The specs of a server will vary based on project needs. If the scale of a project requires or would benefit from an isolated database instance, this can also be executed. The recommendation would be to keep the database in the same account as the server or utilize a cloud based database such as Parse if appropriate.

2. Hosting Providers

Salva O'Renick prefers Rackspace, Media Temple, Digital Ocean, and Amazon Web Services as hosting providers. There are many pros and cons to all providers and the selection is made based upon the requirements of the project.

3. Infrastructure

We recommend setting up a server for developing on and a live server that the public sees. We call these stage (development) and production (live). During the intitial web build, stage and production are spun up at the same time. Development is done on stage and will be pushed to production for client review. Once the requirements of the project are met, the domain name will be pointed at the production server and can be publicized to the world. Stage becomes the server for new web functionality and features, bug troubleshooting, and content review. Stage will always maintain a no-index-no-follow code so that search engines do not index its content.

For content sites and web apps that will contain a large amount of assets, we also recommend the presence of a Content Delivery Network (CDN). Amazon S3 is our preferred provider of choice.

screen shot 2014-11-06 at 11 10 15 am

The benefit of this infrastructure model is it helps minimize risk or dependency on the server. If a server goes down, it is easier to take a back up, apply it to a new server and then point the CDN at the new server--all files are not lost.

4. Code Repository

We use Github as a central repository for hosting code and version control.

5. Backups

Salva O'Renick recommends setting up daily images of the production server. This recommendation is reflected in the cost of servers.

6. Server ownership

Server ownership is considered on a per project basis, but ownership options and terms can be either:

  • Salva O'Renick owns and bills client
  • Client owns and Salva O'Renick has full administrative access

6.1 Salva O'Renick owns and bills client

Salva O'Renick prefers to setup servers in their own hosting provider account (which is purchasing the servers in S|O's name) for projects and bill the client. This is to help with easier administration and quicker access to the elements we need to build, as well as insuring fidelity of the server being used. However, root login access can be given to the client upon request.

When servers are in S|O's name, a 5% charge is added to the client's billing for administration and liability.

6.1.1. Migration

If after the terms of the development timeline and 90 day code warranty, the client does not have subsequent phases or a maintenance agreement in place, S|O will scope out migration costs and execute migration upon a signed SOW. Migration methods can vary and depend on the extent of where the source code is moving to. Common methods are: sharing access to source code via Github, FTP of files, or access to the server via SSH.

Once migration is done, Salva O'Renick will keep both the staging and production servers until instruction from the client to shut down the S|O owned servers. This is done out of an abundance of caution for any issues that may occur during or post migration process. Post migration hosting will continue to be billed to the client if instruction to shut down the servers is not received.

6.2 Client owns and Salva O'Renick has full administrative access

The client will create an account with the hosting provider (example Rackspace and Amazon Web Services) so that the billing will be in the client name. Client will create a user for Salva O'Renick with full administrative access, or share the necessary credentials to execute.

6.3 Maintenance Terms

Besides building the project on top of the server, there are two types of work that are done: proactive and reactive. During development, proactive work is done to insure that code base and server are up-to-date for launch. During the 90 day code warranty, reactive work is done only on the project code base bugs or on server defects as a result of misconfiguration (this does not include any server dependency upgrade releases or vulnerabilities/viruses as these actions are scoped separately.) After the warranty is expired, a proactive or reactive maintenance agreement will need to be in place for S|O for continued work or S|O hosting.

7. Billing

If Salva O'Renick hosts servers, billing terms will be spelled out in the SOW, but should not exceed twice a year. Billing for server will begin at the beginning of the development process for the amount of the estimated development timeline and 90 days for code warranty. A second billing for server ownership will initiate after this time for the remainder of the calendar year if Salva O'Renick will continue hosting. Continued hosting after the calendar year will be billed for the duration of the full calendar year in December to be paid January 1st.

7.1 Project Delays

If a project is delayed during development and the new timeline exceeds the initial billing, the client will be billed for the server ownership for the rest of the calendar year.

7.2 Example infrastructure cost scenario

The following model is based on Salva O'Renick preferred infrastructure model and using Rackspace and Amazon S3 as hosting providers. The assumption will be a three month development build with a 90 day code warranty.

Stage and Production server

Linux Ubuntu server at a Managed Infrastructure level through Rackspace at 1 GB RAM and 20 GB SSD System Disk ($23.36), 200 Mb Bandwidth ($0.24) = $23.60 a month. Multipled by 2 to represent stage and Production is $47.20 a month. Add the Rackspace $50 service cost and that equals $97.20.

Images

Images of the production server should be put in place on a daily frequency to help minimize risk of servers going down. Images are $0.10/GB/month. For example, taking an image daily of a 1 GB site could be around $3.00 a month. This particular model uses an estimated 3 GB site.

3 GB x 0.10 for 30 days = $9.00  

Content Delivery Network (CDN)

Amazon S3 is preferred as a CDN. The benefit to storing images and files through a CDN rather than natively on the application server is to help reduce the risk if a server goes down. Amazon offers the first 5 GB in their free tier and it is $0.03 for the next terabyte. We estimate $0.03 a month.

Cumulatives

$97.20 for servers
$9.00 for images
$0.03 for CDN
5% markup on servers in S|O name ($5.31)

$111.54 per month

For development cycle of 3 month + 90 day code warranty = 6 months ownership. Cost is $669.24.

If continuing on the remaining 6 months of a year, total would be:  
$1338.48 a year

NOTE: This is an EXAMPLE cost for an average build. Verify costs with Digital PM before quoting hosting costs in an SOW.

8. S|O Doc for reference

November 2014 matrix for server billing discussion. Need to have uncommonsense google apps access for view.