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 have come up with an interim solution. 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 75 msec to each access request.

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?

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.