Re: Storage Backend for MediaTemple's ProCDN?
Thanks for your input. I currently use Rackspace's CDN, their
cloudfiles. So far it works nicely with django using the cumulus
storage backend. Cumulus supports virtual directories in a container,
and for the most part works. I have not yet tried Amazon's S3, as
currently all my services including servers are hosted on Rackspace.
Today I was looking into the pricing of various CDNs and server
providers, and I do like what Rackspace provides, a nice price, fast
cloud servers, and they are adding new features all the time.
I think I'd suggest using Rackspace CDN over MT CDN, as it's supported
nicely in django, and I have current experience with it. Although the
app they plan on launching is movie streaming service, and that's
where it get complicated... I will need to judge more than just
pricing and API, Bandwidth is also a big one, especially for the
initial buffering of the stream.
On Oct 22, 4:32 pm, Kurtis <kurtis.mull...@gmail.com> wrote:
> Hello,
>
> I never heard of MediaTemple or their CDN until I read your post. I
> tried to look at their site for your information and it seems to be
> hidden.
>
> We just went through this same thing but starting with Rackspace and
> then moved to Amazon.
>
> One thing I ran across is that they (MT) use "Objects" for their CDN.
> If this is anything like Rackspace, you may run into troubles. For
> example, on Rackspace, you can only create Objects in a "root
> directory" of your buckets and have to fake a file system if you want
> multiple directories. Without performing some kind of a simulation of
> a heirarchy within a flat-directory structure, you'll have a pretty
> difficult time managing your files. It really depends on what you plan
> on using the CDN for, though.
>
> We started with Rackspace and loved them. But, that one feature drove
> us to try out Amazon's S3. Amazon provided the ability to store files
> in a directory structure. And from there, publishing that "bucket" (I
> forget what they're called on S3) to the CDN was extremely easy. The
> main downside to Amazon's Cloudfront is the TTL Caching -- but I
> honestly haven't tried that hard to invalidate or set lower refresh
> times for objects in the CDN. The thing I loved about Rackspace was
> their *excellent* support -- but with Amazon you have a huge community
> which sort of makes up for that.
>
> I would suggest doing a complete evaluation of the three products.
> Include components like pricing (hosting & CDN), development time, and
> support. Then, present these to your boss and let him/her see why a
> specific provider might be the best to use. Sure, MediaTemple *might*
> be the cheapest to host (I don't know, just assuming) but if there's
> no existing tools to use them as a storage backend, it might cost your
> boss thousands of dollars (equivalent to years of hosting costs) to
> have you build this thing.
>
> Sorry I couldn't compare MT CDN with the others but I hope that offers
> a little help.
>
> On Oct 22, 5:11 pm, Kevin <kveron...@gmail.com> wrote:
>
> > I have a client who is suggesting that I look into MediaTemple's
> > ProCDN. I currently only have experience with RackSpace's CloudFiles
> > CDN, and only know of it and Amazon S3 for django storage support.
> > Furthermore, I cannot seem to access their API pages without having a
> > login, so this complicates it, as I'd like to see what sort of REST
> > API I'd be looking into implementing.
>
> > Has anyone had any success with managing a MediaTemple ProCDN with
> > Django? Or rather, as anybody used MediaTemple's CDN at all and what
> > are their reviews over other popular CDNs such as S3 or Cloudfiles?
>
> > Thanks.
--
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to django-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
0 Comments:
Post a Comment
Subscribe to Post Comments [Atom]
<< Home