EANOG - Cloud computing demystified! or for dummies if you like:-)

I copied this mail verbatim from Phare's mail blast to eanog, I take no credit for the jokes, Im not funny at all:-)

Does the term cloud computing cloud your thinking? Do you associate cloud computing to overcast weather? Are you tired of marketing buzzwords that are never explained like 'SaaS' (You read it as 'Sasa', a common Swahili greeting), PaaS (you assume this means a man from Western Kenya has had enough of his fowl), IaaS (Frankly, simply confuses you) etc?

As EANOG (East Africa Network Operators Group), we have taken it upon ourselves (Yep, we are just nice guys :-) ) to explain and demystify these concepts. Think of it as the class in University you should have been taught, but were not. Think of it as MITx, by regular Wananchi, who speak your language!

Who will be speaking?

Simple people:

1. John Gitau - Nice guy. Loves farming, hiking, talking to people, taking long walks off short piers, a regular guy, who just happens to have a great understanding of networking (a Cisco CCIE, works for Safaricom, usual accolades, but speaks your language, from the grandmother, to the server room geek, he gets you).

2. Phares Kariuki - Again, nice guy. Loves his coffee, music, books and failed attempts at sarcasm. Tries to cook, but tragically succeeds in making dogfood (everything roasts). Happens to work in the virtualization field (has for the last five odd years), as a Business Manager for VMware in Westcon Africa, previously did pre-sales for VMware at Westcon Africa. Can additionally have a conversation with your great aunt and your geek about cloud computing.

We at EANOG believe in keeping things simple. Keeping things straight forward. We will serve coffee. We promise to be simpler and more accurate than our esteemed Kenyan Meteorological Department :-).

When? The 18th of February, 2011, at the iHub, from 10.15 am.

And yes courtesy of one Aaron Mbowa of DataPosit, we'll be providing free snacks. How awesome is that.

Register below!

http://cloudsmadesimple.eventbrite.com/

*DISCLAIMER -  Conversation may veer off anticipated topic, unfortunately an effect of Coffee & ADHD. Forgive us. There will be rules on how to get us back talking about clouds :-).

Third world networkers view on the data center - again

So yesterday I wore a different hat for a few minutes. I was a scribe. I was requested to just sit in and later advice the business team after a meeting they were having with one of our bigger customers. The requirement was basic, they would like to move their applications to our cloud at some point. Cloud as its commonly known is an interesting service with an even more interesting support model.

The desire for designers to avoid single points of failure for critical applications so that catastrophic errors don't occur runs deep. Such failures lead to huge financial losses and a diminished corporate brand for all parties involved.

I hope their  admins/cio has adviced the business accordingly. Since in this case I was on the provider side, I figured it might help someone if I gave a few tips on what to look out for if coming or going for critical hosting services from one of the cloud providers: Also note I am more interested in storge and networking issues in the data center for now - we just begun). If you buy some virtual machines and run applications well....so some tips follow:

Test disaster recovery. It is probably the most difficult one but ensure that you have a solid disaster recovery plan. So lets assume you want to port/move 10 applications to the cloud:

As a client; make a thorough analysis of each application before even engaging a provider. This analysis should give direction to the service provider on how to port and test the applications in the cloud, if you'll do it, the use it as a guide.

Your plan when executed should test the basic applications in the cloud, the service provider's configuration (what is needed for all ten applications) and also the additional functionality needed for a successful disaster recovery of those applications. Sadly no one in Kenya will do this for you. Well no one that I know of.

Use whatever you get from the tests above to build an SLA. Don't blindly walk into an SLA. And don't walk out without one. Confirm in any way you can that there is at minimum architectural reliability.

Interrogate the person selling the solution, do they look clueful? Ask if you can get independent audits of the cloud infrastructure. Good providers will let you do it. What should be analyzed first? How do you gain confidence that the SLA you come up with covers all the various types of failure by the service provider?  Performance metrics are still needed for each supported application. And please ensure you have before and after porting/migrating statistics to use for comparing whether things are better or worse off.

I'll throw in some sample questions to ask and maybe just maybe someone will benefit from them:

Storage:
How many vendors are used for all application storage?
Is de-duplication addressed?
How is the SAN switching done?
Is only one SAN switch vendor used for all of the applications?
How many vendors are used for data replication, encryption to encrypt data for all of the applications?
which encryption algorithm is in use, for which tool?
how many PKI vendors to manage certificates?
and lastly where are the damn certificates stored?

You can go deeper (sorry I've been working overtime trying to figure out data centers of late so this will be lengthy)

For the network find out what routers/switch are used within the data center?
are they redundant?
which firewall, IDS/IPS, load balancers, can they steer traffic between redundant data centers?
can you test this?
are the load balancers redundant?
who is/are the ISP's for internet connections, is it on redundant fiber?

As a client you at least need to know something about your apps:
what is the application's best user response time?
response time under load at a certain number of concurrent users, what is the peak number of users expected?
How long does the application need to recover from a failure before it affects your operations and leads to loss in any form? at what point do you lose your  job? get sued?:-)
Is there any component that could affect the application - eg an application tied to a mac-address?
etc etc....

Finally for each application, throw in a grid of information, maybe a row per application into the SLA. So here you probably want to have functionality requirements, performance metrics and financial penalties for the various types of downtime errors per application.

While cloud providers are not obligated to deploy identical architecture as the clients ie same products and software and models and releases as the client's, the provider must meet similar functionality and response times. Areas where this deviation is a risk needs to be documented and the risk of downtime calculated and documented. This also includes the risk of brand loss and potential for law suits.

Some performance data for each application also needs to be collected to complete the SLA. Just so you can say - hey it used to be like this, now its worse off....or better off...

This will be fun......

Cloud what?

Look If you are one of those bozo CIO,CTO,CCC,CKT or whatever acronym that will make me rich by moving your stuff to a cloud while concurrently being thoruoughly clueless about it, please:

1: Get my contacts right. You might forget it during a meltdown and I need the money.....
2: And this is important, learn,read up on cloud services, what they are, what to do when the clouds go 'poof' automagically. Just because jesus rode one doesn't make them fool proof.

Seriously guys, you still need redundancy, you still need to think about the design and you most definately need regular audits no matter who is providing the service to you. Yet another reason I don't advocate for Kenyan companies hosting anything outside our borders....especially if its mission critical like those idiots who installed systems that monitor 'patients pacemakers' in the 'clouds'.

If you are a network admin, get clued in on this 'cloud thing', its gonna be bread and butter alongside IPv6. Start small, install vmware, mess around with esx, steal a nexus switch or oh well justlearn something to sound intelligent when the friggin' cio/cto wants to talk cloud....
http://www.standalone-sysadmin.com/blog/2011/04/the-silver-lining-of-amazons-cloud-issues/
I especially liked this one:
http://evilrouters.net/2011/04/29/the-ec2-ebs-outage-what-amazon-didnt-tell-you/