Pages

What Programming Language Should I Use to Build a Startup?

Often entrepreneurs ask me 'What technology should I build my startup on?' There is no right or wrong answer to this question. It's a decision every company makes for itself, depending on what it's trying to build and the skills of its cofounders. Nonetheless, there are a few rules that one should adhere to. We discuss them in this blog post.

Incident Response Policy

What happens in your company when a production incident occurs? Usually in a typical startup, you will see engineers running around frantically trying to resolve the problem. However, as soon as the incident is resolved, they forget about it and go back to their usual business. A good incident response policy can help bring order into chaos. We provide a sample template in this blog post.

Why Software Deadlines Never Make Sense

We discuss why software deadlines usually don't make sense.

Analyzing Front-End Performance With Just a Browser

We discuss a number of freely available online tools which can be used to analyze bottlenecks in your website.

Why Smaller Businesses Can't Ignore Security and How They Can Achieve It On a Budget

In this article, we show that security is both important and achievable for smaller companies without breaking a bank.

Wednesday, August 28, 2013

Security Industry is Fundamentally Flawed - NYTimes, Twitter hacked via DNS

Yesterday, New York Times and Twitter DNS records got hacked by Syrian hackers loyal to President Assad's regime.   A phishing attack against Melbourne IT DNS register was used, where an unwitting employee downloaded an email with a Trojan which stole his credentials.
What's interesting is that Melbourne registry has been fairly careless about its security (it appears) - in XSSed database, there are several cross-site scripting vulnerabilities reported about them which haven't been fixed for two years.
This is yet another proof that security product industry is fundamentally flawed - it's focusing on the wrong things.   Security awareness should be at the top of the agenda for all the companies instead of investing millions of dollars into useless vulnerability scanners.  Secondly, the companies focus on protecting themselves but they don't enforce any security standards on 3rd parties that they deal with.
More information in an article in Huffington Post where I got quoted:

Such an attack happens often and is not very sophisticated, experts say. "What they did was pretty simplistic," said Aleksandr Yampolskiy, a security expert and chief technology officer at Cinchcast, a webcasting provider. "But what’s scary is if they were smarter they could have done more damage."
For example, the hackers could have redirected visitors to The New York Times to another website that installed malicious software on users' computers, Yampolskiy said.
http://www.huffingtonpost.com/2013/08/28/melbourne-it-hacker_n_3829593.html

Monday, August 26, 2013

Auto-scaling your Amazon EC2 instances


(NewRelic diagram illustrating autoscaling from CodePen.IO)



In the past, companies would have to purchase 10 hardware servers, if at peak time 10 servers were needed to handle the traffic volume. For the rest of the day, the servers would sit idle. This is no longer needed. One big advantage of the cloud (like Amazon EC2) is elasticity, an ability to scale up and down the number of your server instances on the fly depending on the traffic load. In this article, I describe how you can automate spinning up instances when a CPU usage on your web servers exceeds 80%. I assume that you installed a typical EC2 Linux instance with a web server running on it (I used Ubuntu OS + installed Apache/MySql/PHP/Wordpress combo).

 The steps to auto-scale your instance are as follows:

STEP  1.   Preliminaries
Unless, your EC2 instance already contains Autoscaling command-line tool, you should download it: http://aws.amazon.com/developertools/2535  You can build the toolkit through the ./configure followed by make followed by make install incantations. Go to that directory and type.
AWS_AUTO_SCALING_HOME=`pwd`
export PATH=${AWS_AUTO_SCALING_HOME}/bin;$PATH

Set up a new EC2 key + certificate and copy them to the directory. You can generate them in your management console http://aws.amazon.com/.
declare -x EC2_CERT="/home/ec2-user/AutoScaling-1.0.61.2/cert-amazon.pem"
declare -x EC2_PRIVATE_KEY="/home/ec2-user/AutoScaling-1.0.61.2/pk-amazon.pem"

STEP 2     Create a launch configuration

- Here, the input types are : image-id   (AMI ID pointing to a disk image that you'd like to clone) and instance-type (which EC2 instance type you want to spawn);  finally, you can reference an existing security key and security group when you create this instance.

as-create-launch-config alexLC --image-id ami-05355a6c --instance-type t1.micro --key alexkey --group AlexGroup


STEP 3     Create a group. 

The key things you specify is minimum number of EC2 instances to launch upfront and maximum number. You also specify the availability zone in which to launch.

as-create-auto-scaling-group alexG --launch-configuration alexLC --availability-zones us-east-1d --min-size 2 --max-size 10


STEP 4      Policy
In this step, you specify how many instances at once do you launch, and what's the cool-down period (when no changes are made). The cool down is designed to prevent against sporadic traffic spikes.
Here, I scale up by 1 and wait 5 minutes to cool down.

as-put-scaling-policy --auto-scaling-group alexG --name scale-up --adjustment 1 --type ChangeInCapacity --cooldown 300

STEP 5   Trigger
Finally you need to pair this up with Cloudwatch trigger to invoke the policy at an opportune moments.
The key input variables are 
a) period of an event measured in seconds - here we require that a spike in CPU usage is observed for 60 seconds
b) number of evaluation periods (1 period only is enough for our purposes; again this is designed to prevent against sporadic traffic spikes resulting in instance launches)
c) threshold for CPU (70%). I highly recommend not to exceed 70% usage for production instances
d) reference to the policy URI identifier. This URI identifier will be emitted by command in step #4.
mon-put-metric-alarm --alarm-name sample-scale-up --alarm-description "Scale up at 70% load" --metric-name CPUUtilization --namespace AWS/EC2 --statistic Average --period 60 --threshold 70 --comparison-operator GreaterThanThreshold --dimensions InstanceId=i-8a3441ef --evaluation-periods 1 --unit Percent arn:aws:autoscaling:us-east-1:032853316404:scalingPolicy:0674edb1-6a2f-4ccb-9a66-3ec9c0d4cd72:autoScalingGroupName/alexG:policyName/scale-up
This is it! If you followed all the steps, correctly then you've created a policy and a trigger which will be fired when a CPU on a web server reaches 70%.

TESTING IT
Option 1) One way to simulate a CPU spike is to launch a CPU-heavy activity like a clone of a large GIT/Mercurial repository.
yum install hg  (install Mercurial)
hg clone http://xenbits.xensource.com/xen-unstable.hg        (clone entire XEN VM repository - this will keep CPU at > 90% for minutes)

Option 2) Launch a simulated load test using Apache Benchmark, JMeter, Soasta, SIEGE or many other freely available tools.
For example, you could download SIEGE from http://www.joedog.org/siege-home/ and hammer your EC2 instance siege -c25 -t10M http://ec2-54-242-122-87.compute-1.amazonaws.com/




Tuesday, August 20, 2013

Self-Confidence for Entrepreneurs

The difference between successfull and non-successful entrepreneurs is : "They don't always have perfect, complete self-confidence but when confronted with major changes or challenges, they have the know-how and the skills to regain self-confidence." "Millionaire's mind" by Thomas Stanley Ph.d.

Monday, August 19, 2013

Are we in control of our decisions?

A great Ted talk by Dan Ariely (who later wrote a book "Predictably Irrational"). Most people don’t know what they want unless they see it in context. So most of them ended up selected option #3 (which had identical pricing to #2). When The Economist removed option #2, 68% of people chose #1 and only 32% #3.

Into the night with Gary Kasparov and Peter Thiel

A great, intimate conversation between Gary Kasparov (world chess champion) and Peter Thiel (a billionaire entrepreneur, and co-founder of Paypal). They talk about a wide range of topics ranging from human rights, chess, technology, and entrepreneurship. (thanks to Alan Levy for sharing initially with me)