configure CDN - Githubissues

chadwhitacre commented 11 years ago

I have an account at MaxCDN that I'm planning to use for this, if there are no objections.

olivierlacan commented 11 years ago

Sounds good to me.

chadwhitacre commented 11 years ago

Okay, looked into this. Neither MaxCDN nor Fastly support apex domains. We would have to use http://something.shields.io/ instead of http://shields.io/.

Also, I'm not sure what's going on with pricing for SSL. I'm seeing $39/mo at MaxCDN for custom SSL (right?), but over $100/mo at Fastly for even shared SSL. I don't feel like I have a good handle on what the real costs for SSL are going to be.

chadwhitacre commented 11 years ago

@olivierlacan Here are two options:

Use a CDN. Two suboptions:
1. Serve the homepage from http://shields.io/, and PNGs from http://cdn.shields.io.
  Use http://shields.io/ as the origin server for PNGs.
2. Serve both the homepage and PNGs from http://www.shields.io/.
  Use http://origin.shields.io/ as the origin server for both homepage and PNGs.
Don't use a CDN. We could serve the whole thing from http://shields.io/, and expect to be able to afford to upgrade to AWS by the time we need it.

kookster commented 11 years ago

I think you can have an apex domain using the amazon cloudfront cdn in combo with their route 53 dns service. It is not as cheap as the rates I have seen for maxcdn, but an option perhaps?

Andrew Kuklewicz

On Fri, Sep 13, 2013 at 5:46 PM, Chad Whitacre notifications@github.comwrote:

@olivierlacan https://github.com/olivierlacan Here are two options:

Use a CDN. Two suboptions:

Serve the homepage from http://shields.io/, and PNGs from http://cdn.shields.io. Use http://shields.io/ as the origin server for PNGs.

Serve both the homepage and PNGs from http://www.shields.io/. Use http://origin.shields.io/ as the origin server for both homepage and PNGs.

Don't use a CDN. We could serve the whole thing from http://shields.io/, and count on CDN's to add ALIAShttp://support.dnsimple.com/articles/alias-recordsupport for apex domains by the time we really need it.

— Reply to this email directly or view it on GitHubhttps://github.com/gittip/shields.io/issues/52#issuecomment-24426878 .

chadwhitacre commented 11 years ago

Good look, @kookster, thanks! :-)

Amazon CloudFront now supports Custom SSL Certificates and Zone Apex, two features that make it easier for you to accelerate and deliver your whole website using CloudFront.

http://aws.amazon.com/cloudfront/custom-ssl-domains/

chadwhitacre commented 11 years ago

Pricing for Custom SSL Certificates is simple. We charge a fixed monthly fee of $600 [...].

O.O

chadwhitacre commented 11 years ago

@olivierlacan I'm afraid $600/mo is not in the budget that I can see. What do you think is the best way forward here?

chadwhitacre commented 11 years ago

@olivierlacan I've modified option two above to suggest that we could launch now without a CDN, and expect to be able to pay for AWS by the time we really need it.

chadwhitacre commented 11 years ago

@olivierlacan Let me know how you'd like to proceed.

kookster commented 11 years ago

I'm pretty sure that is the cost for adding an ssl cert, and has nothing to do with the apex domains except that they were 2 features announced on the same day.

Andrew Kuklewicz

On Fri, Sep 13, 2013 at 10:28 PM, Chad Whitacre notifications@github.comwrote:

Pricing for Custom SSL Certificates is simple. We charge a fixed monthly fee of $600 for each custom SSL certificate you associate with your CloudFront distributions, pro-rated by the hour.

O.O

— Reply to this email directly or view it on GitHubhttps://github.com/gittip/shields.io/issues/52#issuecomment-24435153 .

kookster commented 11 years ago

You can read more about it in this blogpost that shows the set-up - these features are related by timing only, you do not have to spend $600/mo to use cloudfront with an apex domain -

http://aws.typepad.com/aws/2013/06/custom-ssl-domain-names-root-domain-hosting-for-amazon-cloudfront.html

Andrew Kuklewicz

On Fri, Sep 13, 2013 at 10:47 PM, Andrew Kuklewicz < andrew@beginsinwonder.com> wrote:

I'm pretty sure that is the cost for adding an ssl cert, and has nothing to do with the apex domains except that they were 2 features announced on the same day.

Andrew Kuklewicz

On Fri, Sep 13, 2013 at 10:28 PM, Chad Whitacre notifications@github.comwrote:

Pricing for Custom SSL Certificates is simple. We charge a fixed monthly fee of $600 for each custom SSL certificate you associate with your CloudFront distributions, pro-rated by the hour.

O.O

— Reply to this email directly or view it on GitHubhttps://github.com/gittip/shields.io/issues/52#issuecomment-24435153 .

chadwhitacre commented 11 years ago

@kookster Sorry to not be clear: we need SSL. Since Shields PNGs will be used on SSL web pages, we need to make them available on both HTTP and HTTPS to avoid mixed-content issues. If I'm not mistaken, SSL is actually a stricter requirement for us than an apex domain.

olivierlacan commented 11 years ago

@whit537 It seems like a good idea to be thrifty if we can save $500 by using cdn.shields.io/... (although badges.shields.io seems like a better semantic option) instead of the apex, but it certainly hurts the whole clean URL aspect a little bit.

I'll defer to @nbibler (hoping he has time to chime in) since he's a lot more savvy when it comes to SSL than I am.

Launching without a CDN might be feasible though. I don't mind baby steps. :-)

chadwhitacre commented 11 years ago

@olivierlacan It sounds like your ideal would be to use http://shields.io/ for everything public-facing. Yes?

olivierlacan commented 11 years ago

Yessir.

On Sun, Sep 15, 2013 at 11:14 PM, Chad Whitacre notifications@github.com wrote:

@olivierlacan It sounds like your ideal would be to use http://shields.io/ for everything public-facing. Yes?

Reply to this email directly or view it on GitHub: https://github.com/gittip/shields.io/issues/52#issuecomment-24487100

chadwhitacre commented 11 years ago

Yessir.

In that case, I propose that we launch with our current Heroku setup, and move to Amazon when we're further down the road (more traffic, more money).

If this is agreeable, then here's what I think we want to do:

@whit537 renames our Heroku app from origin-shields-io.herokuapp.com to shields-io.herokuapp.com.
@olivierlacan drops the CNAME for origin.shields.io
@olivierlacan adds a CNAME for shields.io to shields-io.herokuapp.com.

Sound good, @olivierlacan?

chadwhitacre commented 11 years ago

@olivierlacan Actually, it'll be a different CNAME due to SSL at Heroku. Let me know if you want to proceed with this plan and I'll get you the right CNAME.

nbibler commented 11 years ago

For the time being, I would suggest using Heroku's SSL Endpoint ($20/mo) and a decent SSL certificate (GeoTrust QuickSSL Premium, for example.. one time per year, ~$100) and just running everything directly from Heroku under badges.shields.io or secure.shields.io or something. That still gives you the flexibility of moving to a CDN in the future by just moving the CNAME to the CDN hosts and migrating the certificate in the future.

olivierlacan commented 11 years ago

@whit537 I'm good to go, let me know which CNAME I should point to.

chadwhitacre commented 11 years ago

Thanks for weighing in, @nbibler. We're verified with StartSSL, so we can get unlimited certs (they charge for verification, not for certs). I think we should still be alright to launch with http[s]://shields.io/ and migrate hosting in the future. We can add origin.shields.io as a CNAME at that time (we'll only need it on http since we don't need SSL between the edge and the origin since we're not transferring sensitive data, only using SSL to avoid mixed-content warnings on the pages we're embedded on). Once that new CNAME propagates we can configure hosting w/ SSL at Amazon (or wherever we land) and then switch DNS for shields.io to point there.

nbibler commented 11 years ago

Sounds fine. My only concern is that you want to use whatever domain now that you anticipate using in the future. Because it's trivial to update the DNS for a CNAME, its far more difficult to have all the services and providers update their URL references in the future. Dedicating a subdomain to the "API"-built images sounds like a good idea to me to do early.

chadwhitacre commented 11 years ago

@nbibler Good call. If we decide in the future that we need to separate our marketing pages from the PNG API, we could always move the marketing pages to a subdomain like www.shields.io or even introducing.shields.io or something.

@olivierlacan has the final decision on this one, IMO.

chadwhitacre commented 11 years ago

Is it more semantically natural to have ...

http://shields.io/ <- marketing pages
http://api.shields.io/ <- PNG API

Or what?

chadwhitacre commented 11 years ago

It might not just be marketing pages, too. I suppose in the future we'll want to have traffic reports, etc., eh @olivierlacan?

nbibler commented 11 years ago

I presume at some point you'll want to track and report which badges are being requested, at what request rate, at what file size, etc. It would be useful to know what services are using this and what kind of load they put on your system.

If this ever moved to a pay-per-use model, you'll need to track that anyway and probably want to have a concept of what a reasonable usage is.

chadwhitacre commented 11 years ago

@nbibler Yup, I'm with you. :-)

chadwhitacre commented 11 years ago

My thinking at this point is that we should keep the PNG API and the marketing/admin pages separate.

http://shields.io/ <- marketing pages & admin app
http://api.shields.io/ <- PNG API

api. seems to me to be fairly universal. I don't think it will feel odd to have that in the img src urls. Though if we wanted the admin app to be single-page we would presumably want to use api.shields.io for the json api for that, and we might prefer not to conflate that with the PNG API.

@olivierlacan Do you see value in splitting our URLs or do you still want to use http://shields.io/ for everything?

nbibler commented 11 years ago

:+1: for @whit537. I would split them, they've got two different purposes and it allows you to do more interesting things on the api endpoint if/when necessary (rate limiting, caching, etc.) that do not affect the marketing pages.

chadwhitacre commented 11 years ago

If we wanted to save api.shields.io for the backend for shields.io, perhaps img.shields.io could make sense for the PNG API.

nbibler commented 11 years ago

You could act-as-if and just call it cdn.shields.io for now. ;)

olivierlacan commented 11 years ago

@nbibler I'm pretty anal about end-user semantics ;-)

Just for that I tend to prefer img.shields.io or badge.shields.io so that the URLs are self-evident (and created equal).

@whit537 I do like the idea of traffic reports down the line.

chadwhitacre commented 11 years ago

@olivierlacan Okay! So let's go with:

http://shields.io/ <- marketing pages & (eventual) admin app
http://img.shields.io/ <- PNGs

I'm going to proceed on that basis unless you indicate otherwise, @olivierlacan. Thanks for weighing in! :-)

nbibler commented 11 years ago

Any of them sound fine to me. I'm certainly a fan of not using the top-level for it... so whatever subdomain you guys decide on will give you the most flexibility, I think.

chadwhitacre commented 11 years ago

Yay for decisions! :dancer:

chadwhitacre commented 11 years ago

Okay! I've forked an img.shields.io repo, leaving this one as a static Heroku site for now using the PHP hack, with an index.html file as the homepage.

chadwhitacre commented 11 years ago

I've deployed both to Heroku, so we're ready for a DNS change, @olivierlacan!