- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Cloud Hosting why/when?

by Steven Baker

I've had quite a lot of experience helping teams who use both cloud-based and physical-server hosting. The promise of the cloud is that you can start/stop servers to meet dynamic demand. In the simple case, run ten servers during the day in your timezone, and only one at night to keep the lights on. In a slightly more complicated case, have some software tools (that you probably have to write yourself) that spin up and add new servers to the pool when server load reaches a certain threshold. In the usual case, spin up new servers to do computationally intensive background workers. Since you typically pay for cloud services by the running hour, very careful management of this can lead to lower costs. In theory. In practice, people don't really do this. They spin up some servers, deploy their stuff. When they need more, they spin up some more, and never really manage growth or two to manage expenses. In fact, because it's *so* easy to spin up a new server, folks will often end up with far more than they need very quickly. My experience has been that the average non-profitable startup will spend between $10,000 and $30,000 per month on their cloud hosting. For hosting that can be adequately served by two $2500 servers for $250/mo in co-location fees. I have literally gone to clients, moved them off of cloud provider to real hardware for significant and nearly immediate gains. One month of their hosting fees can typically pay for my time (and I'm not cheap), the new hardware, and a year of co-location fees. There are rare cases when this is reasonable. Also, since I'm in Canada, companies typically can't store their data in the US because of the Patriot Act, and that makes Rackspace Cloud one of the few options we have. Finally, you can install VMware's vCloud Director (or similar; they have many products) on your own hardware and have "the cloud" on your own hardware. It's amazing. That said, there are some good reasons to us cloud-based services: hardware management, backups, security. - Hardware management is the most obvious. When you use a product like Rackspace Cloud, you don't ever have to think about disks, servers, locations, network configurations, etc. When you want more power, you click a button. Someone else manages all of that. When there's a bad disk, you don't notice, because it's someone else's job to swap out the bad one and make sure that everything was redundant. - Backup and reliability are a really important feature that cloud providers offer. All will offer redundant disks and the like, but most go further than that. Most cloud providers have multiple datacentres and can spread out your servers, or move your data between them quickly. In Canada, we have one cloud provider who will transparently fail over your stuff from Vancouver to Toronto and vice versa. - Security is probably the most often overlooked point. Most cloud providers will manage firewalls, and do the "infrastructure bits" of PCI compliance and related things which significantly reduces the work you have to do yourself. In the end, it depends on the business. My experience is that it's foolish to use cloud providers for anything more than small VPSes without taking a hard look at the costs. Most businesses will have someone on staff who can manage the building and deployment of these servers, and well managed servers don't need babysitters anyhow. Plus, as software developers, we'll automate everything (they call that Devops now) and make it even easier. I have recommended two past clients switch to the cloud. They had a rack full of aging servers, and were paying a staff of four system administrators ~ USD$80k/yr to manage those. Moving to the cloud was cheaper for them in both the short and long term. But it's rare. Finally, when your stack is "simple Rails app running on MySQL", which is a completely boneheaded stack in the first place, it's *easy* to scale and can be done nearly transparently. Plus, do you really want the Rails kids touching infrastructure bits? Some things are best left to the experts, and using a cloud provider makes that easy even if it is more expensive. Cheers! -Steven On 2013-06-21, at 8:29 AM, Stephan Eggermont <stephan(a)stack.nl> wrote: > When I see the enthousiast reactions to the cloud hosting tip, > I often wonder why? What do you see as the advantages, > and where does it provide a good fit? I can understand the > 5 euro/month vps for a single instance case. > > As soon as I need redundancy, monitoring and scaling, > I still need to understand so much of the underlying infrastructure > that the step to DevOps seems awfully small. Neiher Heroku, > nor AWS make scaling transparent, AFAIK. That is to say, they'll > start up new instances just fine. That only helps when processing > is the problem, not internal bandwidth. And solving the wrong > problem only leads to high costs. > > The cost figures I've seen published on the web suggest that most > larger scale usage would be better of with at least their regular demand > covered by dedicated servers. I know hosting in the US is much more > expensive than in Europe. Digitalocean at least seems to give more > reasonable price/performance. AWS vs Hetzner seems uncomparable > > Your thoughts? > > Stephan > > >

June 24, 2013

Re: [Pharo-dev] Cloud Hosting why/when?

by Stephan Eggermont

Another issue is, at least in the EU, the Data Protection Directive. AFAIK no cloud provider from the US or with US ownership can currently comply with that. Stephan

June 24, 2013

Re: [Pharo-dev] Request to update Seaside build

by Sven Van Caekenberghe

On 24 Jun 2013, at 16:01, Camillo Bruni <camillobruni(a)gmail.com> wrote: > --groups=Core,Tests,Seaside will do AFAIK :) I don't think so. There is a double dispatch at MetacelloMCVersion>>#load: that works on Collection or String. But in the String case, the string is just wrapped in an Array, with no splitting going on...

June 24, 2013

Re: [Pharo-dev] Request to update Seaside build

by Camillo Bruni

>>> Could you please also do a Zn update and an install of the adaptor ? >>> >>> ./pharo Seaside.image config http://mc.stfx.eu/ZincHTTPComponents/ ConfigurationOfZincHTTPComponents --install=stable >>> >>> ./pharo Seaside.image config http://mc.stfx.eu/ZincHTTPComponents/ ConfigurationOfZincHTTPComponents --install=stable --group=Seaside >> >> both entries? stable and group Seaside separately? > > Yes, because the Seaside group is special: it is a hack as it does not depend on either Zinc or Seaside, both for technical MC reasons, while it actually should; in a way it just loads one package. > > If the config handler could load multiple groups, then the equivalent of > > ConfigurationOfZincHTTPComponents project latestVersion load: #('Core' 'Tests' 'Seaside') --groups=Core,Tests,Seaside will do AFAIK :) > would be fine (tests not really being needed). > > BTW, stable is not needed right, as it is the default ? actually true > Maybe, in the future, we could change ConfigurationCommandLineHandler > > installVersion: aVersionName > | metacelloVersion | > self inform: 'Installing ', self configurationName, ' ', aVersionName. > > metacelloVersion := (self metacelloVersion: aVersionName). > > (self hasOption: 'group') > ifTrue: [ metacelloVersion load: (self optionAt: 'group') ] > ifFalse: [ metacelloVersion load ]. > > Smalltalk snapshot: true andQuit: true. > > with > > installVersion: aVersionName > | metacelloVersion | > self inform: 'Installing ', self configurationName, ' ', aVersionName. > > metacelloVersion := (self metacelloVersion: aVersionName). > > (self hasOption: 'group') > ifTrue: [ metacelloVersion load: ($, split: (self optionAt: 'group')) ] > ifFalse: [ metacelloVersion load ]. > > Smalltalk snapshot: true andQuit: true. > > It is just so hard to testâ¦ Erwan has set up a Metacello test configuration, we will write some functional tests with it an see how it behaves. After that we can write decent tests for the Configuration command line handler...

June 24, 2013

Re: [Pharo-dev] Request to update Seaside build

by Sven Van Caekenberghe

On 24 Jun 2013, at 14:16, Camillo Bruni <camillobruni(a)gmail.com> wrote: > On 2013-06-24, at 13:26, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> Camillo, >> >> I think you set up the Seaside contrib build. >> >> https://ci.inria.fr/pharo-contribution/job/Seaside/47/PHARO=20,SEASIDE_VERS… >> >> I noticed that it does not contain a Zn adaptor. >> >> Could you please also do a Zn update and an install of the adaptor ? >> >> ./pharo Seaside.image config http://mc.stfx.eu/ZincHTTPComponents/ ConfigurationOfZincHTTPComponents --install=stable >> >> ./pharo Seaside.image config http://mc.stfx.eu/ZincHTTPComponents/ ConfigurationOfZincHTTPComponents --install=stable --group=Seaside > > both entries? stable and group Seaside separately? Yes, because the Seaside group is special: it is a hack as it does not depend on either Zinc or Seaside, both for technical MC reasons, while it actually should; in a way it just loads one package. If the config handler could load multiple groups, then the equivalent of ConfigurationOfZincHTTPComponents project latestVersion load: #('Core' 'Tests' 'Seaside') would be fine (tests not really being needed). BTW, stable is not needed right, as it is the default ? Maybe, in the future, we could change ConfigurationCommandLineHandler installVersion: aVersionName | metacelloVersion | self inform: 'Installing ', self configurationName, ' ', aVersionName. metacelloVersion := (self metacelloVersion: aVersionName). (self hasOption: 'group') ifTrue: [ metacelloVersion load: (self optionAt: 'group') ] ifFalse: [ metacelloVersion load ]. Smalltalk snapshot: true andQuit: true. with installVersion: aVersionName | metacelloVersion | self inform: 'Installing ', self configurationName, ' ', aVersionName. metacelloVersion := (self metacelloVersion: aVersionName). (self hasOption: 'group') ifTrue: [ metacelloVersion load: ($, split: (self optionAt: 'group')) ] ifFalse: [ metacelloVersion load ]. Smalltalk snapshot: true andQuit: true. It is just so hard to testâ¦ >> Then we should have an up to date and working Seaside image, I hope ;-) >> >> BTW, why are the other builds in the matrix empty ? > > Seaside exposes currently a known issue with Opal under 3.0, will be fixed > as soon as Clement and Marcus are back from vacation, so by the end of this week. > > The 31 Configuration is still buggy I assume / or not in the same location as the 30, > let me check once the build completed.. OK, no rush, Seaside 3.0.x in Pharo 2.0 is a good start. Sven

June 24, 2013

Re: [Pharo-dev] Request to update Seaside build

by Camillo Bruni

On 2013-06-24, at 13:26, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Camillo, > > I think you set up the Seaside contrib build. > > https://ci.inria.fr/pharo-contribution/job/Seaside/47/PHARO=20,SEASIDE_VERS… > > I noticed that it does not contain a Zn adaptor. > > Could you please also do a Zn update and an install of the adaptor ? > > ./pharo Seaside.image config http://mc.stfx.eu/ZincHTTPComponents/ ConfigurationOfZincHTTPComponents --install=stable > > ./pharo Seaside.image config http://mc.stfx.eu/ZincHTTPComponents/ ConfigurationOfZincHTTPComponents --install=stable --group=Seaside both entries? stable and group Seaside separately? > > Then we should have an up to date and working Seaside image, I hope ;-) > > BTW, why are the other builds in the matrix empty ? Seaside exposes currently a known issue with Opal under 3.0, will be fixed as soon as Clement and Marcus are back from vacation, so by the end of this week. The 31 Configuration is still buggy I assume / or not in the same location as the 30, let me check once the build completed..

June 24, 2013

Re: [Pharo-dev] Smalltalkhub url

by Camillo Bruni

On 2013-06-24, at 14:03, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Currently copying and pasting a smalltalkhub link in a .tex file does not make Latex happy. It complains about the non-letter characters then use latex escaping: \footnote{\url{http://smalltalkhub.com/\#!/~Pharo/AsmJit}}

June 24, 2013

Re: [Pharo-dev] Smalltalkhub url

by Alexandre Bergel

Currently copying and pasting a smalltalkhub link in a .tex file does not make Latex happy. It complains about the non-letter characters Alexandre On 23 Jun 2013, at 05:54, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > On 2013-06-23, at 00:50, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > >> Hi! >> >> Just wondering whether urls do need to have #! and ~ in the url? >> E.g., http://smalltalkhub.com/#!/~ainfante/MemoryProfiler > > > Could be possible > 1) replace ~ with a subdirectory /users/ or so (though I don't see any advantage of this) > 2) replace the fragment-based navigation with something that uses history.pushState > > 1) could be done with relative little overhead, 2) is going to be more work. > >

June 24, 2013

Request to update Seaside build

by Sven Van Caekenberghe

Camillo, I think you set up the Seaside contrib build. https://ci.inria.fr/pharo-contribution/job/Seaside/47/PHARO=20,SEASIDE_VERS… I noticed that it does not contain a Zn adaptor. Could you please also do a Zn update and an install of the adaptor ? ./pharo Seaside.image config http://mc.stfx.eu/ZincHTTPComponents/ ConfigurationOfZincHTTPComponents --install=stable ./pharo Seaside.image config http://mc.stfx.eu/ZincHTTPComponents/ ConfigurationOfZincHTTPComponents --install=stable --group=Seaside Then we should have an up to date and working Seaside image, I hope ;-) BTW, why are the other builds in the matrix empty ? Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

June 24, 2013

Re: [Pharo-dev] [Pharo-fuel] Pharo 2.0: Review for Fuel fix integration required

by Martin Dias

Hi Max, A deadline was killing me, but finally I have time to review it! :D :D cheers, MartÃn On Thu, Jun 20, 2013 at 11:01 AM, Max Leske <maxleske(a)gmail.com> wrote: > Hi guys > > I created a new Fuel version that includes an important fix (in my opinion). That fix should be integrated into Pharo 2.0 (in my opinion); here's the integration request: https://pharo.fogbugz.com/default.asp?10730 > > Summary of the change: > Changes in the serialized graph during serialization do no longer affect serialization, i.e. the graph serialized it the graph as encountered during analysis. > This fix is important for the "Fuel out stack" feature in Pharo2.0 because of contexts that can reference processes (e.g. with Seaside). > > Since Marcus does not have the capacity to review everything in the inbox, I need one or two poeple to look at the request and green light it. > > Side note: we need more people to review changes. Simply assigning everything to Marcus doesn't seem to solve this problem :) > > Thanks for your time. > > Cheers, > Max > > _______________________________________________ > Pharo-fuel mailing list > Pharo-fuel(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel

June 24, 2013