[Novalug] Fwd: cloud computing (and CIO mag article)

[greg pryzby]

Different from beowulf, sorta.

In a cloud, I don't need to know or care where it runs. I have a job and 
I need an answer.

For beowulf, I need to code to something that can be run in parts-- mpi 
or mpich usually. I can't take a program that generates my invoices and 
run it in on a beowulf cluster as is. I need to make code changes.

In the cloud, I can say, "generate invoices given this set of data" and 
the 'engine' figures out what resources are needed to get an answer and 
runs the request and returns the answer.

In a perfect world, KVM is loaded on the server, the image that is 
needed to run the invoice tool is delivered (a VM via AMQP), the image 
runs and the results are sent out. Finally the VM is stopped and 
'cleaned' (whatever clean means).

Ken Kauffman wrote:
> This time for novalug... -_-
> 
> ---------- Forwarded message ----------
> From: *Ken Kauffman* <kkauffman at headfog.com <mailto:kkauffman at headfog.com>>
> Date: Sun, Jun 7, 2009 at 11:14
> Subject: Re: [Novalug] cloud computing (and CIO mag article)
> To: Pete Nuwayser <nuwayser at gmail.com <mailto:nuwayser at gmail.com>>
> 
> 
> Here's the EC2 Amazon cloud stuff (http://aws.amazon.com/ec2/).  It's a 
> great solution for temporary batch job work at scheduled points in a 
> month.  For people that do a lot of business intelligence work, 
> licensing the cloud MAY be a faster way of getting the job done 
> quickly.  Rather than mung through terabytes of data over hours and 
> days, you can conjure up a cloud configuration and get it done fast 
> giving you more time to actually use the information you extract.  
> Retail does a lot of this I know.  I've also had experience using 
> Netezza where you can get the same effect, but that's another topic 
> since the data warehouse can crunch the numbers hard (ELT vs ETL).
> 
> Now I realize you are probably more interested in the "how do I build 
> one", but I've always thought of cloud computing as not much more than a 
> beowulf cluster.  So you could use the Google App Engine to program your 
> own and not need to build out the infrastructure.
> 
> So, unless someone else has a different view on this, cloud computing is 
> the same as beowulf to me, but some marketing guy figured out how to 
> actually use it and market it under a new name.
> 
> Ken
> 
> 
> On Sun, Jun 7, 2009 at 10:53, Pete Nuwayser <nuwayser at gmail.com 
> <mailto:nuwayser at gmail.com>> wrote:
> 
>     On Sun, Jun 7, 2009 at 10:17 AM, greg pryzby<greg at pryzby.org
>     <mailto:greg at pryzby.org>> wrote:
>      >
>      >
>      > Doug Toppin wrote:
>      >>
>      >> "Cloud computing" is a subject we've been going over in my class at
>      >> various points.  That topic has a variety of meanings but they all
>      >> pretty much boil down to less custom software (and thus
>     licenses) and
>      >> requiring less labor to administer (and thus fewer people) installed
>      >> on individual user platforms (laptops, desktops, ...).  When we made
>      >> the jump from big machines with dumb terminals to PCs on each desk a
>      >> significant increase in IT-related staffing was required to
>     administer
>      >> them (an artificially induced increase really).  As those costs have
>      >> increased over the years it's become apparent that something
>     needs to
>      >> happen to reduce them.  Cloud computing puts us right back to
>     multiple
>      >> people sharing big machines (via virtualization or whatever) with
>      >> fewer people needed to administer them.
>      >
>      > Back to time-sharing mainframe type days. Yep... what goes
>     around, comes
>      > around.
>      >
>      >> A recent article on this subject can be found at:
>      >>
>     http://www.cio.com/article/493502/Early_Cloud_Adopters_Ride_Out_Hype_Cycle
>      >>
>      >> At the end of the article you'll see: "Adopting cloud whole hog
>     could
>      >> cut IT staff by 10 percent to 15 percent".  There are numerous side
>      >> effects to moving to a cloud environment but it's clear the
>     intent is
>      >> to reduce some of the mundane aspects of IT.
>      >
>      > Interesting point.
> 
>     Nah, it's just written to help generate sales and inflate the hype.  :-)
> 
>      From a Fed perspective, the half-dozen agencies that are already
>     Shared Service Providers who also purport themselves to be current or
>     potential cloud providers are not sure exactly what their strategy
>     will be.  They're all looking at themselves and their as-is states,
>     saying, "Could we at least /call/ ourselves a cloud provider just to
>     keep from being marginalized?  We're already a shared services
>     provider, so, what the heck?"  Until these guys and gals figure out
>     what to tell their customers, the most they can do is answer the
>     question, "Do you have something like salesforce.com
>     <http://salesforce.com> or EC2" with
>     "yeah, sure, we can do that" or "we have a pilot in the works."
> 
>      >
>      > Being right in the middle of this (while @ Novell and again at
>     Red Hat), I
>      > am not sure I agree. I agree that the level of knowledge for the
>     IT person
>      > will need to increase and the 'mundane work' will be less, but
>     there will
>      > still need to be people to do the work. Much like with the industrial
>      > revolution, the skill set will change. I don't need people to sew
>     by hand, I
>      > need people to fix the machines.
> 
>     You should expect to learn how to virtualize every component of
>     whatever it is you support now, be it the app layer, OS, network,
>     storage, etc.  Otherwise, I don't think much will change.  Are you
>     splitting time between infrastructure, OS and app support?  If your
>     supported app were partially or wholly virtualized, how much of your
>     job would really change?  Clouded or not, Linux is still Linux.
> 
>      > With cloud, there is a need to design and care and feed the
>     infrastructure.
>      > There is the need to gather requirements and build the machines
>     (VMs?) for
>      > the cloud. Someone has to build the knowledge into the system to
>     allow the
>      > allocation/release of resources although the allocation and use is
>      > 'automated' via tools.
> 
>     Since so much of "cloud" just means OS virtualization (for now,
>     anyway), these activities have mostly to do with classifying workloads
>     as good or bad candidates for virtual environments.  You look at I/O
>     contention, CPU loads, RAM ballooning, affinity and anti-affinity,
>     capacity planning, stuff like that.  E.g. most people don't expect to
>     stick a SQL database in a cloud without also understanding what other
>     parts of the solution stack are nearby.  Become an expert before you
>     are asked!
> 
>     I also think it's very important to grasp customer-side expectations
>     of clouds, either by vertical or horizontal.  For example, how much
>     autonomy might your customers want, say from a provisioning
>     perspective?  Are you offering Infrastructure as a Service (IaaS)?
>     Wouldn't it be great to let your customers stand up something with
>     little more effort than entering a Remedy ticket?  How could that
>     happen?
> 
>      > You are right that you need to keep your skills sharp and grow.
>      >
>      >> The strongly waving flag here is to keep your skills tuned to beyond
>      >> those required for mundane IT.  Find ways and learn how to plan,
>      >> implement and manage future environments in all sorts of situations.
>      >> Be amenable (and enthusiastic) to change in the workplace.
> 
>     Word.
> 
>      > For those of us who were around in the 90s and early 00s, if you were
>      > breathing and weren't afraid of a keyboard, you could get a 'job in
>      > computers'. There were smart people (they are still around and in the
>      > business), but there were lots of people that who did it for the
>     money and
>      > didn't really grasp what they were doing. They could follow a
>     script or
>      > decision tree, but if there wasn't a case to handle the
>     situation, they were
>      > lost.
>      >
>      > It happens in EVERY field when there is a jump in 'technology'.
>     It is coming
>      > again for the IT field. However, these things tend to be slow
>     (bleeding
>      > edge, fast adopters, fast followers, etc...) and there are
>     companies that
>      > will stay way behind the curve (IT for stores) for years.
>      >
>      > Of course I could be wrong. But don't say nobody told you what is
>     coming.
> 
>     Well, don't say nobody told you /something/ is coming.  I think Doug
>     (and the rest of us) would like to know exactly what that is!  :)
> 
>     Pete
> 
>     --
>     Pete Nuwayser

-- 
greg pryzby                              greg at pryzby dot org
                                          http://www.linkedin.com/in/gpryzby
BLOG: http://restonartistree.blogspot.com/
WEB:  http://www.RestonArtisTree.com/
TWTR: gpryzby