Re: [squid-users] Cacheing in the cloud

 On Tue, 08 Nov 2011 08:02:29 -0600, David Brown wrote:
> Hello, with all of the SaaS, PaaS and the like running on clouds
> everywhere with packaged deployments that can't be tinkered with
> where
> does Squid and cacheing come into the game?

 In the "other" category AFAIK. (My knowledge of cloud details is low,
 so this may be so much hot air YHBW).

 Depends on what you call "cloud", though.

 If you are talking about VM style stuff where things float around
 between CPUs and physical machines. the cloud is done at the individual
 packet level. Squid is not even close to relevant at that level.

 If you are talking about the SaaS side of clouds. Where services use
 AJAX / XHR / RESTful HTTP for APIs and interactions. Squid is one of the
 engines that can be used to move traffic around and provide scalable
 capacity. Integrating with ESI and ICAP services to provide pluggable
 capabilities. We are adding the real-time controls to integrate it
 better with the new shiny toys and management systems, so the abilities
 are both a bit clunky in older Squid and flexible in feature support as
 the releases get more recent.

 If you mean something else, ... um. !?

>
> Does squid run in these types of environments?

 It runs usually as the foundation software for scaling out HTTP based
 SaaS systems, but can also run as a VM on top of the other types of
 cloud.

 IIRC there is an Amazon EC based "Squid device" floating around
 somewhere for use as an easily scaled CDN in that cloud.

>
> If so, is the cacheing advantage realized the same as in traditional
> stand-alone hardware?

 If by "the same" you mean the same way. Yes.
   Squid has not changed much in its storage criteria since clouds
 became popular again.

 If by "the same" you means the same amount. Unknown, the cloud
 benefits/problems fade beside the variability in site designs.

   For example, at the two extremes we have Wikipedia designed to be
 cache friendly and general visitor traffic scales to 100% (many TB per
 minute) with little change in the internal service resource usage.
 Whereas YouTube is designed to be cache unfriendly and can blow out even
 a clouds bandwidth capacity under the same type of popularity.
   AJAX, XHR and RESTful requests tends to be less cacheable by their
 dynamic nature. But not necessarily so. Getting the cache benefit out of
 them requires expertise which a lot of the current web-devs seem not to
 have or at least not to think about when building things quickly.

 This is specific to the caching features though, others like load
 balancing and traffic handling are not affected.

>
> I ran some searches @ squid-cache.org but I did not find any real
> good
> reading on this subject.

 IMO that is because cloud and the related terminology are just the new
 words for stuff Squid and other software have been doing for decades.
 The documentation has not caught up to the re-wording, or description of
 how the traditional proxy cluster and cloud concepts map together. Terms
 like "routing" I used above, in the Squid context it has nothing to do
 with BGP or packets, but maps easily to the cloud concept of channel
 management. Or caching, in the SaaS cloud is somewhat between an
 aggregating buffer and a data source.

 PS: blog/whitepaper/ web articles welcome if anyone with more knowledge
 in both areas wants to try their hand at writing something up properly.

 Amos
Received on Wed Nov 09 2011 - 00:19:14 MST