Lawrence Lessig’s speech at Italian Parliament: Internet is Freedom

I started observing how people usually hate learning and using too many different tools (except possibly for us geeks), this happens because we have limited resources and look for the maximum utility (this happens most at the cross of the business and consumer markets).

Uncertainty also plays a role in forming our decisions as users, where the perceived value of a new application is decreased by the lack of knowledge about how well it can fit the problems that we need to solve.

This has a few consequences: resistance in adopting new tools since it takes a too big effort to learn and preference for generic tools since they are perceived as more flexible and adaptable to our needs.

To overcome this we may reduce the visible part of the application to a level where the user stops noticing while making sure the user can easily reach the value we add. In the end it will all be about finding a way to give increasing returns for the same effort.

One way to follow this path is leveraging the tools that people are already using, integrating into or with them thus giving new ways to use those “old” and generic applications to do new things. Our invisible application will integrate within the flow of information that the user is receiving, it will remove modality from the interactions and augment the context around the documents and data that the users already handle to enrich the interaction with the same old services. Also, an important role will be played by allowing deep adaptation of the interface, whether automatically or via manual customization by the user (for the italian readers, look also at this presentation by Luca Mascaro).

I am using Parallels to be able to do testing of the apps I’m writing on IE (one site I’m working on has more than 1/3rd of users still IE6…) and to be able to recompile and package an old J2EE application using a proprietary framework and builder that works only on Windows :-(

Until upgrading to Parallels 4.0 (which I did yesterday), generating the EAR for said application was taking more than 25 minutes, now it’s just down to less than 5 minutes! The big improvement seem to be in the (shared) filesystem access but also everything else seems snappier and the VM feels lighter on the system.

Overall a highly recommended upgrade to anyone using the product.

The key to reach this flexibility is the API that gives developers the ability to startup a server, configure it, use it and shut it down. There are libraries for many programming languages but I like the way the boto python library makes it really simple do these things (and a lot more).

Here I’ll show how to use boto to start a server instance then how to send a file to the instance and execute a command on the remote server, and finally I’ll show how to terminate the instance.

To use the boto library you’ll need to install it locally (on your computer) and to use the EC2 api you’ll need to import them:

from boto.ec2.connection import EC2Connection

As with  other AWS services you’ll need to pass the access key and the secret access key to the library (in this case when creating a connection). You can get the keys from the Amazon Web Services “Access Identifiers” page. It’s possible to just set two environment variables holding the keys or you can pass them in to the method calls, I’ll assume for this example that the keys are written inside the script and passed to the methods:

AWS_ACCESS_KEY_ID = 'yourkey'
AWS_SECRET_ACCESS_KEY = 'yoursecret'

conn = EC2Connection(AWS_ACCESS_KEY_ID,
AWS_SECRET_ACCESS_KEY)

First step is to make the connection, Once the connection is created we can use the run_instance to start an instance of an EC2 server image. You can think of a server image as a pre-built virtual server that’s idle waiting to be run. There are public images we can choose from (I’ll use the base Linux Fedora for this example), but any user can customize a running instance and build a private image from that ready to be used.

reservation = conn.run_instances('ami-5647a33f',
                               instance_type='m1.small',
                               key_name='mykey')

instance = reservation.instances[0]

while not instance.update() == 'running':
  time.sleep(5)

the run_instances can take various parameters but only the image is required. Here I’m passing in also the instance type (in this case the “Small” instance type) and a key to use. The key to be used should have been previously generated and/or uploaded to EC2 (e.g. using the AWS Management Console).

The run_instances methods returns a reservation object representing the instance(s) startup request. This also holds the list of instances that are going to be started (we may launch more than one instance in a single run_instances call), in this case (since we are launching just one) we take the first one.

Each instance object has an attribute status which returns its current status, to check for the current status we need to call the update method (which itself returns the current status). When the instance is running it is given a public IP and a public dns name, which we may use to connect.

EC2 has a very flexible shared firewall whose rules and permissions may be manipulated via the API, for instance to enable or disable  connecting via SSH. Different security groups may be defined, to partition our instances into different logical sets e.g. web servers versus backend databases, and each group can be assigned different permissions. All the instances are assigned the ‘default’ security group if not otherwise specified.

With a call to the authorize_security_group method we can allow a specific connection for a given group. E.g. with the following call we  allow SSH to any instance in the default group from the specified IP.

conn.authorize_security_group('default',
                ip_protocol='tcp',
                from_port='22',
                to_port='22',
                cidr_ip='%s/32' % our_ip)

with the following call we can revoke the SSH permission

conn.revoke_security_group('default',
                ip_protocol='tcp',
                from_port='22',
                to_port='22',
                cidr_ip='%s/32' % our_ip)

Once the instance is running and the permissions are setup to allow connecting via ssh, we can connect to it and to run a script on the instance we may simply scp the script and then connect via ssh to run it.

When we are done with the work we can stop use the stop method of the instance object to shut it down:

instance.stop()

For a simple, yet complete example here is a script that can be used to run the benchmarks for the redis key-value store on EC2. In the archive, together with the python script there is a shell script which is copied to the server which downloads the redis code, compiles it and runs the benchmarks:

redis-bench-ec2.zip

That’s all!