We blogged about it last year, envisioning a service to do this for other businesses. In this post, we take it a step further and describe the implementation.

The implementation uses an Amazon EC2 instance as a proxy server. There are three parts to setting up the proxy:

1. The foundation. A couple of years ago, Brad Larson described the process of setting up an EC2 server. His purpose was different but the first steps of our process are the same as what he described. Following his lead, bring up an instance of a CentOS AMI. A couple of AMIs we have used are ami-0193f760 in US-East and ami-e32273a6 in US-West (both from RightScale). Snap a 1GB EBS volume to it and attach an IP address. See Brad’s article for details.
2. The components. Squid requires just two components: mod_ssl and squid. Install them both using yum (or apt-get if you are using a different version of Linux).
3. Integration. A few steps to this:
   • Make sure to update /etc/hosts and add the line 01.23.45.67 www.abc.com www_abc.
   • Optional: for speed, add Google nameservers (or others good ones for your locale) to /etc/resolv.conf. To accomplish this, add the lines nameserver 8.8.8.8 and nameserver 8.8.4.4 to that file.
   • Finally, Squid Wiki Configuring SSL Reverse Proxy does a great job of walking through the steps of configuring the reverse proxy. We won’t reproduce the steps for creating a certificate. Here is the config file we use. Not much to it, declaring the SSL connection to the browser and to App Engine and tightening the security parameters.

   acl all src 0.0.0.0/0.0.0.0
   acl Safe_ports port 443
   acl gae dstdomain abc.appspot.com
   
   visible_hostname www.abc.com
   https_port 443 cert=/path/to/cert key=/path/to/key defaultsite=abc.appspot.com
   cache_peer abc.appspot.com parent 443 0 no-query originserver ssl sslflags=DONT_VERIFY_PEER name=appspot
   cache_peer_access appspot allow gae
   always_direct allow gae
   
   http_access allow gae Safe_ports
   http_access deny all
   
   debug_options ALL,1

4. Debugging. For the novice, Squid can be a little cryptic. It was built for speed, not programming ease. Here are a few hints on what to do when things don’t work according to plan:
   • If squid won’t even start, squid –N –d l -D can be useful in figuring out why.
   • If it starts but does not behave as you would expect, that last line (debug_options command) can be used to control the level of detail that is logged. Reading those logs can be a bit of a black art. Use your favorite search engine and the Squid book for help.
5. Operation. Once you have a basic configuration running, tighten up the security and optimize it for performance. We will be adding to this section in the future but here is a good starting point: Six Things First Time Administrators Should Know.

1. Cloud Computing. The hardware cost for development was less than $750. That figure included the cost of a laptop. In an economic climate where startups have to do more with less, how can you beat that?
   • We used Google App Engine for the most part but not exclusively.
   • For confidential documents, we used Amazon S3, preferring to go directly between the browser and Amazon, bypassing Google. Any doubts about whether Google will mine those documents were neutralized.
2. Staying conceptual with the implementation.
   • Google App Engine was great for helping us stay conceptual. They take care of scalability, backups, OS versions, patches. All the stuff that drags you down.
   • Amazon EC2 is too low level. One has to worry about scalability, backups, OS versions, patches. So we go up a level with Rightscale and BitNami.
   • For the same reason, we would consider Amazon RDS over doing our own database management.
3. Open Source Software. Most notably, jQuery. Their slogan is “write less, do more”. The reality matches the slogan. A rich milieu of available software allowed us to assemble components rather than write code. A couple of times we were bitten by it too. A month after we had integrated a component, the developer decided not to support it any more. We switched away. So one has to stay agile but that’s the name of the game anyway.
4. Staying conceptual with the requirements. This was the second-biggest factor: working with a team that trusts you, things don’t need to be written down to an excruciating level of detail. You hear the requirement in vague terms, you implement it, and if you had misunderstood, well, change quickly. Keeping the Agile Manifesto in mind.
5. Tracking shifts in business strategy. This was the biggest factor. The business strategy changed at least a couple of times during the project. The development was continuous, however. We were surprised to discover that the changes forced us to re-factor the code as it was re-purposed to fit the changing strategy — but very little of the code was thrown away. The re-factoring may have made it more modular, actually. By the time the business strategy had settled, we had software components that were well-tested already. Only the final integration was left to do.

Your mileage will vary, of course, but these are the factors that made us successful for this project.

Ingredients

When you sign up with RPX and register your application, you get:

1. A application ID,
2. An iFrame widget and
3. An API token.

When signing up, the domain names need to be provided. These are domain names from which an authentication request may originate. In our case, that includes localhost and www.example.com.

Recipe

Create a login page and place the iFrame widget on it. The iFrame will point to something like

src="https://example.rpxnow.com/openid/embed?token_url=appRpxURL"

where appRpxURL is a URL served by the application. When a user interacts with the login page, RPX calls the application at this URL with a token and the application is expected to turn around and request information about the user. This Google App Engine code fragment illustrates the interaction (to access it, you will need to use an OpenID login). At this point, the application knows the user id. This part is documented in a number of places on the web.

Integration

In a number of the applications we develop at Early Stage IT, the user id is stored in a session variable using GAE Utilities for the remainder of the session. The above-cited code fragment shows this also. The application is still responsible for determining what the user is entitled to do. The first thing to do in handling a user request is to verify that the user has the requisite application capability. This is illustrated in the last part of the sample code.

When the user logs out, clear the cookies by calling theSession.terminate()

If you use it…

…please cite this blog post. Feedback — positive or negative — gratefully accepted.

This post is my attempt at pulling together the cloud security-related resources in one place.

A recent article in Technology Review was quoted in NYT. The tone is more sensational than is warranted. The TR article is based on an experiment where researchers were able to discover whether a “victim” Virtual Machine was lightly or heavily loaded. OK, so you can tell when the server is busy — just like the pizza delivery guy can tell when folks are working late at the CIA office. It’s a long way from there to getting your hands on confidential information, IMHO.

Sensational or not the point of security is valid. If you are a cloud company your competitor may well use FUD (fear,uncertainty and doubt) against you. So how do we assure ourselves and our customers of the security of our cloud application? No silver bullets here, just old-fashioned common sense applied across the board. Keep in mind, security is more than IT security. If you have an ultra-secure IT infrastructure and your users leave passwords on yellow-stickies under their keyboards, the infrastructure was probably not worth the money you spent on it.

First, building security into the architecture, not as an afterthought. Amazon offers these guidelines for developing HIPAA-compliant applications. Whether you use Amazon or not, whatever your application’s security requirements, you need to have architecture guidelines for your application. And your implementation team needs to follow them.

Second, there are a number of assessment tools out there. Thanks to Steve Primost (his blog) for this link on the Microsoft Security Assessment Tool.

Third, if you were the customer, which would you find more compelling?

1. We did an assessment of our software and believe it to be secure or
2. We had an independent IT security firm go through our architecture and implementation and found it to be secure?
3. We had an independent IT security firm try to penetrate our security by hacking into our system. After a week, they gave up.

The level you choose depends on how important security is for your business and your customers. Well, of course it is important. But are you/they willing to pay for the extra cost of insuring that it is?

Google App Engine

This talk will introduce software engineers to Google App Engine.

Event Details:

• Google App Engine — Mass GTUG Meeting
• Location: MIT Campus, Building W92 at 304 Vassar St, Cambridge MA.
• Date: Tue, January 12, 2010
• Time: 6pm – 8pm
• To register, click here

It is not an introduction to web programming or a Google Apps session. It is assumed you know server-side web development — perhaps ASP, JSP or PHP. Please note, this session will be based on Python. Still, it is not a programming language session — the emphasis will be on learning the available APIs which are common between Java and Python on GAE. The idea is to familiarize everyone with the basic App Engine APIs.

We will create a toy bank and be able to transfer “money” between accounts.

Agenda:

1. Getting Started – What is App Engine
2. Structure of an App Engine Application
3. Data Store — the data store is common between Python and Java.
4. Template Engine — the Template Engine is unique to the Python environment.
5. Transactions — the transaction model is common between Python and Java.

Prep Work: To get more out of the meeting, you may want to

• Visit the Google App Engine Getting Started Guide.
• The Downloads page also has instructions on setting up a development environment such as Eclipse.
• Walk through the Hello World example ahead of time.
• Walk through this Data Modeling presentation presentation ahead of time.
• The design of the bank application is based on this blog post by Nick Johnson.

If you do some of the prep work outlined above, you may be able to ask more pointed questions. I will make sure to allocate plenty of time for questions.

Google App Engine

This Hackathon will introduce software engineers to Google App Engine. It will be free of charge, first-come-first-served but preference will be given to software engineers in the web development area.

Event Details:

• Location: Aprigo, 460 Totten Pond Rd suite 660, Waltham, MA. I would like to thank Aprigo for their sponsorship of this event.
• Date: November 6, 2009
• Time: 9:00 am to 4:00 pm
• Meeting capacity: 10 people
• Food/drink: bring your own / buy in the building.
• Sign up: Eventbrite.
  

It is not an introduction to web programming or a Google Apps session. It is assumed you know server-side web development — perhaps ASP, JSP or PHP. Please note, this session will be based on Python. Still, it is not a programming language class — the emphasis will be on learning the available APIs which are common between Java and Python on GAE. If you have any questions about whether you will get much out of the hackathon, please contact us.

Agenda The main goal is to familiarize everyone with the App Engine and how you can use it to build your web application “in the cloud”.

• 1 hr – Getting Started – What is App Engine
• 1.5 hrs – Coding
• 15 mins – Introduction to Users API
• 1.5 hrs – Coding/lunch
• 15 mins – Introduction to UrlFetch and Mail APIs
• 1.5 hrs – Coding
• 15 mins – Introduction to Images and Memcache
• 1 hr – Coding
• 45 mins – Let attendees present the apps they worked on/wrap up

Prep Work

• Attendees should plan to bring their own laptop.
• The Development Environment section of the above link suggests downloading Python 2.5 and the App Engine SDK. Please download these ahead of time.
• The Download App Engine SDK page also has instructions on downloading and setting up a development environment such as Eclipse. This is not mandatory.
• It is helpful to have walked through the Hello World example ahead of time. We will be going over it again in the first couple of hours of the session so it is optional, not mandatory, to have done this.

Example Applications. Attendees are welcome to bring their own application ideas to work on during the Hackathon. For the main example, we will work on an application in the spirit of Cafe Survey. Another possibility is to create a wiki or a blog application.

For some companies HTTPS access through their own domain is essential.

We at Early Stage IT use an interim solution — a proxy server. The pricing and reliability parameters are not fully set but we think it might cost about $35/month plus $0.30/GB for 3-nines availability. It would also add about 125 msec to each access request. We measured the delay at 75 msec but it may have been on a particularly calm day, internet-traffic-wise. Proxy servers terminate the SSL connection at the proxy with a yourdomain.com certificate, decrypt the message, re-encrypt it with a *.appspot.com certificate and send it along. The message can theoretically be snooped on while it is being transformed on that proxy server.

With these parameters, is this a service that would be of interest to your company?

Early Stage IT is in a unique position. On the one hand, we do work for clients and that puts us in a “supplier” role. On the other hand, as virtual CIO for our clients, we play a “client” role vis-a-vis other suppliers. With both roles in mind, we did a survey of billing practices people employ. In this search, we favored billing practices that align with agile development. To cite some models:

• 10 Contracts for your next Agile Software Project by Peter Stevens. It’s well written and concise, and a recommended reading for all. How many people’s blog entries get translated into a half-dozen languages?
• A 5-part series by Chris Parsons of Eden Development.
  • Parts 1, Part 2 and Part 3 argue that fixed price arrangements are inappropriate for software development because they’re implicitly set up to pit client and supplier against each other. This wastes valuable project budget and time on working out what to do when the project changes. I concur.
  • Part 4, argues that time and materials types of arrangements shift the risk to the client but the adversarial nature of the relationship remains. It’s not a good model for new relationships but can be OK once trust has been built up.
  • Part 5 describes what they actually do. The elements we like are (a) giving clients an expectation of the budget, (b) weekly billing, (c) setting weekly expectations and “gently” exceeding them and (d) no-surprises billing — meaning that things like management fees, infrastructure usage fees are blended into the programmer rate.
• The Vertical Slice by Lars Thorup. It’s beautiful in its simplicity and I like it. It ensures the supplier has a stake in the success of the client. The 50% number, however, does not fit the risk profile of Early Stage IT’s typical clients.

Of all the different models, we like three the best. In order

1. Peter Stevens’ Money for Nothing, Changes for Free
2. Chris Parsons’ Billing with Integrity
3. Peter Stevens’ Time and Materials with Variable Scope and Cost Ceiling

As always, feedback is welcome.

1. Cloud Development for Google App Engine
2. Cloud Development for Amazon EC2
3. Managing software delivery from outsourcers
4. Managing evolution of database configurations
5. Performance and Stress Testing
6. Security Testing

In this introductory post, I want to cover activities that cross all platforms. The premise of Cloud Development is that the company does not own any hardware. Under these circumstances, how does software development get done?

Tight control over source code is essential. This need does not go away with Cloud Computing. It becomes more important! It used to be that if you lost track of the latest source, you could always look at the working machine. No longer, not consistently anyway. In the Google App Engine support forum, there is a predictable weekly request from someone or the other for Google to help them retrieve their latest source code. The answer is always the same (no, can’t be done).  The team needs to use the source repository frequently to build from.  The source repository should be backed up, versioned and secure. What should be under source control? Everything! That includes source code (duh!), install scripts (Rightscale scripts, for example, for creating an environment), security settings,  even database configurations. This last item will require further discussion; more on it in a subsequent post.

The issue tracking database is the team’s second most important asset, after source code. It too needs to be backed up, versioned and secure^†.

One swallow does not a summer make, but consider this:

• Someone I was meeting with yesterday said that they were winding down their venture fund because they had incurred heavy losses and concluded that they needed to stay closer to their knitting.
• John Bennett makes the point in his blog that Cloud Computing offers unprecendented opportunities for small- and medium-sized businesses (SMBs).

What does this have to do with Venture Capital?

• Cloud computing makes it possible for startups to go after a niche SMB markets of the type John outlines.
• Such a startup may not have the infinite potential of a Google or Facebook, but making a $20-50M company out of a $1-2M investment is pretty nice returns, even for a VC.
• Seed-stage venture firms such as Launch-Capital have come into the market with a different model — and done well even in this economy. Their model is different in that they make more small-dollar deals rather than fewer large-dollar deals.

Might other VC firms go the same way? Your thoughts?