Friday, April 29, 2011

Using Other's Article On Your Blog or Writing Reference

Sometime we just copy and pest other's article which might be license under someone else. Sometime we do it as the Internet is not stable and nobody can assure that the article URL will be there in future.

Mr. Shahriar Tariq, Volunteer, Bangladesh Linux Users Alliance ( check our forum: wrote some nice word regarding this topic.

Bellow is his writings: (Copy & Pest)

If you are using someone else article as a reference

1) Check the license, most open source related articles are licensed under open license (such as Creative commons)

 2) if the article is not licensed it won't hurt to politly ask the author whether you can use it. most author won't mind giving permission since they wrote it to let people know the content in the first place

 3) be sure to give due credit to the original author. If you are not aware who is the author at least mention where you have collected the article

If you find that someone else is using your article without proper credit

1) don't jump on and attack the person, keep your tone checked all the time, if you start heated argument its more probable other person is also gonna reply angrily

2) It may be the case that the person who is using your article without credit are actually not aware of licensing issue. Its not uncommon in Bangladesh, most people don't understand piracy then how come they will understand licensing issue? Make him/her understand licensing issue

3) if reminding them properly does not work then take it up to the concerned team, in case of forum talk to the moderators, in case of community website, the owner is the person you need to talk to, if its personal blog take it up to the hosting company (given they are reputed hosting company).

Simple solution is not it?

Thanking you
Shahriar Tariq

Founding Member, Amigos Clothing

Tuesday, April 26, 2011

Lessons to Learn From Amazon's Recent Outage

As of the latest update this afternoon on Amazon’s Service Health Dashboard, only a handful of customers are still waiting for their EBS and RDS instances to be restored after Thursday’s harrowing outage. But for everyone involved (not least Amazon’s own operations staff) it’s been a very long four days (see latest Techmeme discussion). What are the lessons to learn?
1. Read your cloud provider’s SLA very carefully
Amazingly, this almost four-day outage has not breached Amazon’s EC2 SLA, which as a FAQ explains, “guarantees 99.95% availability of the service within a Region over a trailing 365 period.” Since it has been the EBS and RDS services rather than EC2 itself that has failed (and all the failures have been restricted to Availability Zones within a single Region), the SLA has not been breached, legally speaking. That’s no consolation for those affected of course, nor is it any excuse for the disruption they’ve suffered. But it certainly gives pause for thought.
2. Don’t take your provider’s assurances for granted
Many of the affected customers were paying extra to host their instances in more than one Availability Zone (AZ). Amazon actually recommends this course of action to ensure resilience against failure. Each AZ, according to Amazon’s FAQ, “runs on its own physically distinct, independent infrastructure, and is engineered to be highly reliable. Common points of failures like generators and cooling equipment are not shared across Availability Zones. Additionally, they are physically separate, such that even extremely uncommon disasters such as fires, tornados or flooding would only affect a single Availability Zone.” Unfortunately, this turned out to be a technical specification rather than a contractual guarantee. It will take Amazon quite some effort to repair the reputational damage this event has brought upon it.
Justin Santa Barbara, founder and CEO of FathomDB was forthright in his blog post on Why the sky is falling:
“AWS broke their promises on the failure scenarios for Availability Zones … The sites that are down were correctly designing to the ‘contract’; the problem is that AWS didn’t follow their own specifications. Whether that happened through incompetence or dishonesty or something a lot more forgivable entirely, we simply don’t know at this point.”
While it’s easy to be wise after the event, Amazon’s vulnerability to this type of failure may have been visible on a deep-enough due diligence exercise. As Amazon competitor Joyent’s Chief Scientist Jason Hoffmannotes on the company’s blog, “This is not a ’speed bump’ or a ‘cloud failure’ or ‘growing pains’, this is a foreseeable consequence of fundamental architectural decisions made by Amazon.”
3. Most customers will still forgive Amazon its failings
However badly they’ve been affected, providers have sung Amazon’s praises in recognition of how much it’s helped them run a powerful infrastructure at lower cost and effort. Many prefaced criticisms with gratitude for what Amazon had made possible, such as BigDoor’s CEO Keith Smith:
“AWS has allowed us to scale a complex system quickly, and extremely cost effectively. At any given point in time, we have 12 database servers, 45 app servers, six static servers and six analytics servers up and running. Our systems auto-scale when traffic or processing requirements spike, and auto-shrink when not needed in order to conserve dollars.”
4. There are many ways you can supplement a cloud provider’s resilience
As O’Reilly’s George Reese points out, “if your systems failed in the Amazon cloud this week, it wasn’t Amazon’s fault. You either deemed an outage of this nature an acceptable risk or you failed to design for Amazon’s cloud computing model.” It’s useful to review the techniques customers have used to minimize their exposure to failures at Amazon.
Twilio, for example, didn’t go down. Although the company hasn’t explained exactly what its exposure was to the affected North Virginia Availability Zones, it has described its architectural design principles in a first entry on its new engineering blog by co-founder and CTO Evan Cooke. These include decomposing resources into independent pools, building in support for quick timeouts and retries, and having idempotentinterfaces that allow multiple retries of failed requests. Of course all this is easier said than done if all your experience is in designing tightly-coupled enterprise application stacks that assume a resilient local area network. Cooke’s post goes on to describe some of the characteristics that make Twilio’s architecture capable of operating in this more fault tolerant manner. To start with, “Separate business logic into small stateless services that can be organized in simple homogeneous pools.” Another step is to partition the reading and writing of data: “if there is a large pool of data that is written infrequently, separate the reads and writes to that data … For example, by writing to a database master and reading from database slaves, you can scale up the number of read slaves to improve availability and performance.”
Another site that didn’t go down is NetFlix, which runs all its infrastructure in the Amazon cloud. Again, it’s not clear how exposed its operations were to the affected Amazon resources, but a Hacker News thread usefully summarizes some of the principles employed.
5. Building in extra resilience comes at a cost
Bob Warfield describes how a previous company used infrastructure in a way that allowed it to “bring back the service in another region if the one we were in totally failed within 20 minutes and with no more than 5 minutes of data loss.” As he goes on to say, the choices you make about the length of outage you’re prepared to support have consequences for the cost your customers or enterprise must fund. “Smart users and PaaS vendors will look into packaging several options because you should be backed up to S3 regardless, so what you’re basically arguing about and paying extra for is how ‘warm’ the alternate site is and how much has to be spun up from scratch via S3.”
6. Understanding the trade-offs helps you frame what to ask
There are questions you should be asking to satisfy yourself that a cloud service you rely on is not exposing you to a similar failure (or at least that, if it is, you understand this and are willing to bear the consequences in return for a cheaper cost). Referring to NetFlix’s practice of randomly killing resources and services in order to test its resilienceBob Warfield adds this advice:
“That’s likely another good question to ask your PaaS and Cloud vendors — “Do you take down production infrastructure to test your failover?” Of course you’d like to see that and not just take their word for it too.”
7. Lack of transparency may be Amazon’s ‘Achilles heel’
Several affected customers have complained of the lack of useful information forthcoming from Amazon during the outage. BigDoor CEO Keith Smith wrote, “If Amazon had been more forthcoming with what they are experiencing, we would have been able to restore our systems sooner.” GoodData’s Roman Stanek called on Amazon to tear down its wall of secrecy:
“Our dev-ops people can’t read from the tea-leaves how to organize our systems for performance, scalability and most importantly disaster recovery. The difference between ‘reasonable’ SLAs and ‘five-9s’ is the difference between improvisation and the complete alignment of our respective operational processes … There should not be communication walls between IaaS, PaaS, SaaS and customer layers of the cloud infrastructure.”
Amazon’s challenge in the coming weeks is to show that it is prepared to give its customers the information it needs to build in that resilience reliably. If it does not meet that need and allows others to do better, it may gradually start losing its dominant position today in IaaS provision
Written ByPhil Wainewright, who has been a thought leader in cloud computing as a blogger, analyst and consultant.