Apps

Building an enterprise application on Amazon EC2

Nick Hardiman begins the process of building an application on the Amazon EC2 machine.

I want to install an enterprise application on my EC2 machine. An enterprise application is software aimed at business users, not domestic users.

I use the Apache HTTP Server application as an example here, which is a bit of a cheat because Apache does not provide a business solution in itself. It has no obvious use to an accounts department, a sales office, or a production line. However, this server is well known as a building block - it is a central pillar of many enterprise applications and powers over three hundred million web sites - and it is an example of a well written application.

Salesforce.com customers enjoy one of the benefits of the SaaS revolution - they do not have to install an application. Installing enterprise application software is an IaaS task, not a SaaS task. SaaS vendors build the vehicles and SaaS users do the driving.

The four parts of an enterprise application

From the IaaS point of view, every enterprise application has four parts.

  • Machine. This is the business logic that poor programmers fried their brains over.
  • Configuration. The wheels, knobs and dials that steer the machine are found in separate files, such as the Windows registry and .conf files.
  • Product. The things that the application is meant to work on. Things include photos, documents, music and everything else that can be converted to a digital form.
  • Report. The application writes its activity to logs and produces management information summaries. When an application goes wrong - and all applications go wrong - this is where the support technician looks for help.

When an application is not running, it is a collection of four sets of files. An AWS AMI is a collection of files. A running application, like an instance of an AMI, delivers a virtual world of possibilities that the real world is exploring.

The Apache HTTP Server application is composed of a huge amount of moving parts, including these files.

  • Machine: /etc/init.d/httpd (this starts the daemon when the machine boots)
  • Configuration: /etc/httpd/conf/httpd.conf (this is the main configuration file, thousands of lines long)
  • Product:  /var/www/html/index.html, /var/www/cgi-bin/index.cgi (two examples of a web site home page)
  • Report: /var/log/httpd/access_log,  /var/log/httpd/error_log (the two primary activity logs)

Installation tasks

Installing a new enterprise application is a series of four tasks - install, configure, run and check. Like a car gearbox, you have two flavours of installation - manual or automatic.

Historically these tasks were all manual - system administrators had to really work an installation to get the application up to enterprise speed. Over the years these tasks have become increasingly automated so today the human doing the installation often sees only the first step - the rest is handled by the system. Installing the entire Windows 8 OS in only 11 clicks will be a marvel of automation.

People with a love of control, complexity, and the bleeding edge stick with manual tasks. A development team may grab the latest, greatest, brand new binary files from an application's web site, or even compile from source code for ultimate stability and flexibility.

  1. Install. Every OS has a package manager which makes this step simple. Installation usually means copying an install package from a repository and unpacking files into your file system.
  2. Configure. Time spent on configuration varies. An artist using a Macintosh hates this step so Apple strives for zero configuration, by including automated configuration instructions in the install package. Enterprise  applications capture complex business logic and require a fair bit of coaxing to make them work, involving a lot of manual configuration.
  3. Run. Start your engines. A new application is often started by the package manager as a post-install step.
  4. Check. Perform a basic "did it start or didn't it" test. Developers with utter faith in their code skip this step.

Install the Apache HTTP Server.

When I install Apache HTTP Server  on my Amazon machine I will install one of two Apache HTTP Server packages, depending on the architecture. I don't get the choice so I can't cock it up. There are both 32 bit (i386) and 64 bit (x86_64) Apache install packages called httpd.i686 and httpd.x86_64. The command uname -i tells me which one I will get.

This procedure uses text, not windows. If you want to work at the IaaS level there is no avoiding this kind of nerdy English short-hand - it is at the core of all Internet infrastructure. Despite being a short procedure, it requires a little knowledge of several technical areas - heredocs, homepages, HTTP protocol, and so on.

1. Open a CLI.

2. Use the super-user account (sudo su -).

3. Install. This package depends on a few other APR (Apache Portable Runtime) packages which are also installed.

[root@ip-1-2-3-4 ~]# yum install httpd
...
Install       6 Package(s)
Total download size: 1.4 M
Installed size: 3.3 M
Is this ok [y/N]:

4. Configure. I don't touch the main configuration file here. Instead, I use a heredoc to create a "hello world" page. This technique is older than the Rolling Stones and a lot less famous.

[root@ip-10-228-249-173 ~]# cd /var/www/html/
[root@ip-10-228-249-173 html]#
[root@ip-10-228-249-173 html]# cat <<EOF > index.html
> <!DOCTYPE html>
> <html lang="en">
>  <head>
> <meta charset="utf-8">
> <title>Hello World</title>
> </head>
> <body>
> <h1>Hello World</h1>
> <p>Hello from $HOSTNAME.</p>
> </body>
> </html>
> EOF
[root@ip-10-228-249-173 html]#
5. Run. /etc/init.d/httpd start or service httpd start

6. Check.

[root@ip-10-228-249-173 conf]# wget -O - -q --save-headers http://localhost/
...
<p>Hello from ip-10-228-249-173.</p>
</body>
</html>
[root@ip-10-228-249-173 conf]#

This check with the "wget" command shows both the HTTP and HTML text messages sent by Apache.

7. Close the CLI.

Missed a piece?

Follow the entire journey of working in the Amazon Web Services cloud from initial sign-up to building applications and beyond.

About

Nick Hardiman builds and maintains the infrastructure required to run Internet services. Nick deals with the lower layers of the Internet - the machines, networks, operating systems, and applications. Nick's job stops there, and he hands over to the ...

0 comments

Editor's Picks