OT: Cloud Computing is coming to ...
Christopher A. Williams
chriswfedora at cawllc.com
Fri Jul 23 05:28:35 UTC 2010
On Thu, 2010-07-22 at 18:58 -0700, Les wrote:
> On Thu, 2010-07-22 at 09:25 +0200, birger wrote:
> > But if it works and it means
> > we (the back-end admins) can continue to override the users wishes and
> > provide what they need instead of what they ask for, I'm all for it
> > (like when DBA's come with very specific orders detailing raid type and
> > stripe width for their data and log volumes and we give them everything
> > from our standardized raid 5 pools)
> This is one of the issues. You have decided on what they need. You may
> be right from the viewpoint of storage, but from the access point you
> could be way off the mark. A database's access speed is directly
> related to the disk locations of the various fields and structures.
> True you have given them storage at minimal cost to you, but what have
> you cost the customer? Do you even have a way of benchmarking the
> search times you have impacted? Do you truly understand the DBA's tasks
> and the amount of data they have to search?
Gosh - so much I could say here... If you are doing things correctly,
the answer is yes, absolutely! We work directly with the DB Architects -
not just the DBAs - when optimizing database applications on cloud
infrastructure. There's nothing about it that says you can't or
> When you are moving data around, do you examine the lifetime of the
> storage, or do you know the level of urgency when when that particular
> piece of data is needed or how it should be accessed? These parameters
> are the areas I have had to deal with in corporate settings when some IT
> person decided I didn't know what I was doing, and was sure they knew
Short base answer to this one too. Yes. Explanation: The same base rules
to storage tiering and data / information life cycle management apply in
cloud environments too. In my experience, that "some IT person" you
mention is a storage architect - and yes they absolutely do know better
based on your usage patterns, storage performance reports, and other
history from watching how your system / application has been running.
That information is all tracked and preserved.
> What happens in a parallel processing situation when you move the VM?
> If the IP address changes, the tight binding of resources will be
> disturbed, and that will result in a web search to find the new
> location, rebuild the linkages, and what happens to the computation
> while that is going on?
Well, first, the IP address doesn't change. Go back and read up on Live
Migration (aka vMotion in VMware). Next, in a parallel processing
situation, a VM gets scheduled for the appropriate number of CPUs along
with everything else by the hypervisor. But, again, you're confusing
virtualization techniques that support cloud with old style task
switching and parallel computing. They're not the same.
> > For networking it seems a bit cloudy yet how this will work out. There
> > are so many security implications.
> Precisely!! Not to mention the transfer of responsibility and
Actually, networking in the cloud is simple - once you understand it.
The level of networking separation and security is just as strong as
ever, and has some unique properties that physical networks are just now
starting to explore. The bureaucracy of networking guys is a different
mystery to solve.
> > If I open up the possibility for my internal customers to host computing
> > services in the external cloud, I would like to make sure everything
> > they order has to be verified against company security policies. Those
> > security policies will also need a rewrite to accommodate these new
> > services.
> Like private pipes, SVM services, encrypted RPC links etc??? Oh and my
> personal favorite (retired military, you know) bureaucracy and red tape.
> > Conclusion? Cloud services are very interesting.
> There is a common misconception that what you find interesting users
> will love. I really doubt that that is a good basis for this drive to a
> known bad technology with poor history.
Bad technology with poor history? How so? It seems you are the one with
the common misconceptions. There are public cloud providers in place
today that provide PCI and FIPS level security and compliance, running
government systems. Example: Terremark (http://www.terremark.com). No -
I don't work for them either.
> > The potential
> > implications on interoperability within my own server room? That's the
> > big one. Will it just add to the complexity, or is this so hyped up now
> > that everybody will support new standards at a low level so we can
> > actually simplify internal operations? Will it ever become what the hype
> > promises? Nobody believes that, I think...
> And now we introduce IP V6, soon to be followed with IPV6A or IPV7.
> What happens then?
This has nothing to do with cloud. Network protocols are network
protocols, regardless. We will deal with these kind of issues regardless
of the underlying physical or virtual infrastructure.
> What costs will this pass on. If you put my systems in the cloud will
> I be paid for their processing time? At what par value?
That depends. Do you own the cloud infrastructure? What are the terms of
the contract you negotiated? If it's running on someone else's
infrastructure, why should they pay you for the compute resource? It
should be you paying them, shouldn't it? The market will determine the
rate (which right now is high enough that, unless it's a micro
deployment, building your own private internal cloud is cheaper).
> I know that I am such a boor for pointing these things out, but without
> boors like me, where would we really be?
Answer: A lot further along, because boors like you are clearly
demonstrating that they don't really understand this technology, are
making assumptions that it is something that it isn't (or vice versa),
and casting judgment as if they do understand it.
Some good advice: Never hold a strong opinion on something you know
"You see things as they are and ask, 'Why?'
I dream things as they never were and ask, 'Why not?'"
-- George Bernard Shaw
More information about the users