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.

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.

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?

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^†.

Before going further, I want to review the Powell Doctrine. (Here is the original for your reference). Why Powell? Because business is war and we need to learn from one of the best. The Powell Doctrine, interpreted (by me) for business:

1. What problem does your business solve? Is it a problem worth devoting several years of your life to?
2. Do we have a clear attainable objective?
3. Have the risks and costs been fully and frankly analyzed?
4. Are there other, less painful, ways of solving the problem?
5. Is there a plausible exit strategy to avoid endless entanglement?
6. Have the consequences of the business been fully considered? Who will benefit from it — are they worth benefiting? Who will be hurt by the business?

And now to the main point of this post. Business involves choices. If you’re unclear about your core business,

1. How will you decide who to compete with and who to cooperate with?
2. When you are cooperating, is it capitulation or is it two parties joining together to achieve a common purpose?
3. What will you buy and what will you build? Obviously, you want to build what is the core value of your business. You want to buy what is not core.
4. If you’re going to raise money, and for your own purpose too, you will need to know what your market share is. Knowing market share involves knowing who to include and who to exclude when doing that measurement.
5. Can you practically assure your stakeholders — investors, customers, yourself, your family — that you can deliver? Recall the other Powell Doctrine: Overwhelming Force in pursuit of your core mission†.
6. Will the people your business benefits know what they will get for their money and what they won’t? Will they give it their support? Their love? Their money?

The real point is, a business is not an endless series of pragmatic decisions. You have to know why you’re doing it and what your business stands for.

† Thanks to Larry Grumer for his comment reminding me of this point.

A word of caution: OpenID idea has enjoyed less than spectacular success. Still, a consensus seems to be evolving and a number of announcements this year suggest that perhaps the industry is arriving at a consensus.

A vision of the login sequence using IDs from other providers, is shown on the right.

The table below shows user counts that the UI vision above would target. They were compiled from Comscore stats for internet properties (MySpace is under Fox Interactive Media) and from a different report which zeroes in on email addresses.

A key question that remains to be asked is what are the stats for your users. Of course, you won’t know the answer to that question until you have gone live, so perhaps it is best to cast a wide net in the beginning.

Here are a few references for implementation:

1. Some background material: What is OAuth and how does it work?
2. If you want to do the programming, a recipe for OpenID 1.1 from Plaxo, instructions for using Yahoo! as an identity provider, using Google’s OAuth.
3. If you want to use a third-party solution, RPX service for OpenID 2.0 from JanRain.

Of course, this only addresses the authentication question. How your users will be given entitlements to do what they need to do, and only what they need to do, remains an implementation decision.

With e-learning, the attention wanders, Outlook flashes incoming messages, some auto-update thingy on the PC comes to life and it’s over.

In-class learning is a little better because we learn not only from the trainer but also from the discussion. But how many of us really remember what was discussed a week after we come back from the training?

Ironically, the last time I had an effective learning experience was on-line but it wasn’t an e-learning course. It was a series of exercises where at each step you had to add a level of complexity to a working piece of software and get it doing more things. Two-3 hours later, you had a fairly complex piece of software and you looked at it and said, wow!

My most effective classroom training situation was a management training course where teams were given a hypothetical company to run. Every few hours, we had to make decisions about actions to take, those actions had consequences on the hypothetical company, the external circumstances changed, and you had a new set of problems to deal with. Whichever team showed the best EBITDA at the end of 3 days won!

Whether the training is on-line or in person is the wrong question. The effectiveness of the training is determined by how much effort has gone into constructing it, how much fun you can make it, and the wow factor at the end.

If you want your team trained, and trained well, and trained so they know the material forever after, find inspired training.

• AWS Technical Documentation.
• Best practices on using AWS.
• How to throttle bandwidth (1) and (2).
• JetS3t (gatekeeper services, among other things).
• HIPAA compliance with Amazon Web Services.
• Amazon Web Services Security white paper.