On Sun, 12 Jun 2011, [email protected] wrote: > I'm on a new mail client and accidentally responded to just Derek. > > On Sun, Jun 12, 2011 at 02:00:58PM -0400, Derek J. Balling wrote: >> >> On Jun 7, 2011, at 8:40 AM, [email protected] wrote: >> >>> On Tue, Jun 07, 2011 at 07:25:23AM -0400, Evan Pettrey wrote: >>>> Greetings, >>>> >>>> I've been asked to put together a presentation on the pros and cons of >>>> cloud >>>> computing and a recommendation for what, if anything, can be moved to the >>>> cloud which will result in a net savings that will be worth any additional >>>> problems/headaches. >>> >>> I think the whole conversation is easier if you don't say "cloud" - instead, >>> say "outsourcing" - > >> Maybe. Maybe not. You could just as easily be running in a private cloud, >> inside your own facility, on your own hardware, where you virtualize your >> entire infrastructure for maximum versatility. Heard from a lot of people at >> the HP Discover conference this past week doing just that, and it's just as >> valid a definition of "cloud computing" as any other (moreso than many >> actually). > > while a good pxe setup is great, and really, the only reasonable way > to manage a fleet once it gets beyond a certain size, I think it's silly > to call it "the cloud" because that sort of thing has been the way it's > done at larger places for most of my career. (granted, 10 years ago when > I tried it for the first time, it still required flashing firmware > sometimes to make pxe work, but my point is that the technology has been > here for a long time.) If marketing wants to call it something else, > that's fine, but for the sake of our own sanity, we should call it > 'automatic provisioning' or 'pxe provisioning' or 'kickstart' or something > a little more descriptive that doesn't confuse the issue with virtualization. > > So yeah, instead of 'internal cloud' I say "automatic provisioning system" > mean, it's a good thing to have, essential once your system > gets beyond a certain size, but saying that this has anything to do with > the decision to virtualize, I think, is a mistake. If you do virtualize, > you should put effort into making the virtuals provisionable through the > same system as physical servers. Heck, cobbler does this out of > box. With both xen and VMware, I know you can use pxe to deliver > guest kernels, too. > > I think one great disservice all this 'cloud' talk does is relating > auto-provisioning to virtualization. Both technologies are great when > you need them, but you can have auto-provisioning without virtualization > and vis-a-vis. Personally, I think that automatic provisioning is > useful in more situations than virtualization is, but really you > should look at both technologies on their own; You are doing yourself > a disservice if you virtualize because you want automatic provisioning > capabilities.
This is what I am seeing from a lot of people, both in my company, and from the vendors talking to them. When they start talking about the benifits of virtualization, 90% of the time they are really talking about the benifits of auto-provisioning. the problem is that as companies grow, they usually don't start doing standard builds and auto-provisioning when they should (leading to very inefficient operation), and since it's next to impossible to do a 'virtualization strategy' without auto-provisioning, admins are getting trained to think that if they need auto-provisioning they need virtualization. if you need 100 identical servers to run a particular service, virtualizing those servers isn't the answer, auto-provisioning in the answer. Even if you just need 2-3 identical servers to run a particular service youprobably really just need auto-provisioning. David Lang > I think keeping some control over the jargon used in our work is > important; It's hard to do our jobs if we have to use marketing > terms that have no (or a large number) of operational meanings; this > is why I try to break it down in to real terms that have real meaning. > > _______________________________________________ Discuss mailing list [email protected] https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss This list provided by the League of Professional System Administrators http://lopsa.org/
