Building Applications in the Cloud: Making Software a Service
- Tools Used in This Book
- What Does Your Application Need?
- Data Layer
- Application Layer
- HTTP and REST
- Authorization Layer
- Client Layer
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Developing your Software as a Service (SaaS) takes you away from the dark ages of programming and into the new age in which copyright protection, DMA, and pirating don't exist. In the current age of computing, people don't expect to pay for software but instead prefer to pay for the support and other services that come with it. When was the last time anyone paid for a web browser? With the advent of Open Source applications, the majority of paid software is moving to hosted systems which rely less on the users' physical machines. This means you don't need to support more hardware and other software that may conflict with your software, for example, permissions, firewalls, and antivirus software.
Instead of developing a simple desktop application that you need to defend and protect against pirating and cloning, you can develop your software as a service; releasing updates and new content seamlessly while charging your users on a monthly basis. With this method, you can charge your customers a small monthly fee instead of making them pay a large amount for the program upfront, and you can make more money in the long run. For example, many people pirate Microsoft Office instead of shelling out $300 upfront for a legal copy, whereas if it were offered software online in a format such as Google Docs, those same people might gladly pay $12.50 a month for the service. Not only do they get a web-based version that they can use on any computer, but everything they save is stored online and backed up. After two years of that user paying for your service, you've made as much money from that client as the desktop version, plus you're ensuring that they'll stay with you as long as they want to have access to those documents. However, if your users use the software for a month and decide they don't like it, they don't need to continue the subscription, and they have lost only a small amount of money. If you offer a trial-based subscription, users can test your software at no cost, which means they're more likely to sign up.
Tools Used in This Book
You need to take a look at some of the tools used throughout this book. For the examples, the boto Python library is used to communicate with Amazon Web Services. This library is currently the most full-featured Python library for interacting with AWS, and it's one I helped to develop. It's relatively easy to install and configure, so you can now receive a few brief instructions here. boto currently works only with Python 2.5 to 2.7, not Python 3. It's recommended that you use Python 2.6 for the purposes of this book.
Signing Up for Amazon Web Services
Before installing the libraries required to communicate with Amazon Web Services, you need to sign up for an account and any services you need. This can be done by going to http://aws.amazon.com/ and choosing Sign Up Now and following the instructions. You need to provide a credit card to bill you for usage, but you won't actually be billed until the end of each month. You can log in here at any time to sign up for more services. You pay for only what you use, so don't worry about accidentally signing up for too many things. At a minimum, you need to sign up for the following services:
- Elastic Compute Cloud (EC2)
- Simple Storage Service (S3)
- SimpleDB
- Simple Queue Service (SQS)
After you create your account, log in to your portal by clicking Account and then choosing Security Credentials. Here you can see your Access Credentials, which will be required in the configuration section later. At any given time you may have two Access keys associated with your account, which are your private credentials to access Amazon Web Services. You may also inactivate any of these keys, which helps when migrating to a new set of credentials because you may have two active until everything is migrated over to your new keys.
Installing boto
You can install boto in several different ways, but the best way to make sure you're using the latest code is to download the source from github at http://github.com/boto/boto. There are several different ways to download this code, but the easiest is to just click the Downloads button and choose a version to download. Although the master branch is typically okay for development purposes, you probably want to just download the latest tag because that's guaranteed to be stable, and all the tests have been run against it before bundling. You need to download that to your local disk and unpack it before continuing.
The next step will be to actually install the boto package. As with any Python package, this is done using the setup.py file, with either the install or develop command. Open up a terminal, or command shell on Windows, change the directory to where you downloaded the boto source code, and run
$ python setup.py install
Depending on what type of system you run, you may have to do this as root or administrator. On UNIX-based systems, this can be done by prepending sudo to the command:
$ sudo python setup.py install
On Windows, you should be prompted for your administrative login if it's required, although most likely it's not.
Setting Up the Environment
Although there are many ways to set up your environment for boto, use the one that's also compatible with using the downloaded Amazon Tools, which you can find at http://aws.amazon.com/developertools. Each service has its own set of command-line-based developer tools written in Java, and most of them enable you to also use the configuration file shown here to set up your credentials. Name this file credentials.cfg and put it somewhere easily identified:
AWSAccessKeyID=MyAccessKey AWSSecretKey=MySecretKey
You can make this the active credential file by setting an environment variable AWS_CREDENTIAL_FILE and pointing it to the full location of this file. On bash-based shells, this can be done with the following:
export AWS_CREDENTIAL_FILE=/full/path/to/credentials.cfg
You can also add this to your shell's RC file, such as .bashrc or .zshrc, or add the following to your .tcshrc if you use T-Shell instead:
setenv AWS_CREDENTIAL_FILE=/full/path/to/credentials.cfg
For boto, create a boto.cfg that enables you to configure some of the more boto-specific aspects of you systems. Just like in the previous example, you need to make this file and then set an environment variable, this time BOTO_CONFIG, to point to the full path of that file. Although this configuration file isn't completely necessary, some things can be useful for debugging purposes, so go ahead and make your boto.cfg:
# File: boto.cfg # Imitate some EC2 configs [Instance] local-ipv4 = 127.0.0.1 local-hostname = localhost security-groups = default public-ipv4 = 127.0.0.1 public-hostname = my-public-hostname.local hostname = localhost instance-type = m1.small instance-id = i-00000000 # Set the default SDB domain [DB] db_name = default # Set up base logging [loggers] keys=root,boto [handlers] keys=hand01 [formatters] keys=form01 [logger_boto] level=INFO handlers=hand01 [logger_root] level=INFO handlers=hand01 [handler_hand01] class=StreamHandler level=INFO formatter=form01 args=(sys.stdout,) [formatter_form01] format=%(asctime)s [%(name)s] %(levelname)s %(message)s datefmt= class=logging.Formatter
The first thing to do here is set up an [Instance] section that makes your local environment act like an EC2 instance. This section is automatically added when you launch a boto-based EC2 instance by the startup scripts that run there. These configuration options may be referenced by your scripts later, so adding this section means you can test those locally before launching an EC2 instance.
Next, set the default SimpleDB domain to "default," which will be used in your Object Relational Mappings you'll experiment with later in this chapter. For now, all you need to know is that this will store all your examples and tests in a domain called "default," and that you'll create this domain in the following testing section.
Finally, you set up a few configuration options for the Python logging module, which specifies that all logging should go to standard output, so you'll see it when running from a console. These configuration options can be custom configured to output the logging to a file, and any other format you may want, but for the basics here just dump it to your screen and show only log messages above the INFO level. If you encounter any issues, you can drop this down to DEBUG to see the raw queries being sent to AWS.
Testing It All
If you installed and configured boto as provided in the previous steps, you should be able to launch a Python instance and run the following sequence of commands:
>>> import boto
>>> sdb = boto.connect_sdb()
>>> sdb.create_domain("default")
The preceding code can test your connectivity to SimpleDB and create the default domain referenced in the previous configuration section. This can be useful in later sections in this chapter, so make sure you don't get any errors. If you get an error message indicating you haven't signed up for the service, you need to go to the AWS portal and make sure to sign up for SimpleDB. If you get another error, you may have configured something incorrectly, so just check with that error to see what the problem may have been. If you're having issues, you can always head over to the boto home page: http://github.com/boto/boto or ask for help in the boto users group: http://groups.google.com/group/boto-users.