After a review and comparison of various IaaS, PaaS and SaaS services, the talk then focused on details of Amazon's overall cloud offering. Finally he finished out the presentation with a discussion of software developer best practices - the primary reason I attended. More time spent on software development would have been a big plus in my view, but I can understand that he felt the need to get everyone in the room up to speed on Amazon's platform. It was a big crowd.

Cloud Computing Development Best Practices

The ten best practices Jorge espoused were:

1. Build cloud apps, not apps in the cloud
2. Virtualize the application stack
3. Design for failure and nothing fails
4. Design for scalability
5. Loose coupling lets you maximize plug and play
6. Design for dynamism
7. Build Security into every component
8. Leverage native cloud storage options
9. Leverage best cloud Management Tools
10. Don't fear cloud constraints

Of those ten, the two points that gave me the most pause for contemplation were to "build loosely coupled systems" and to "build security into every component."

Build Loosely Coupled Systems

"Build loosely coupled systems" brought a flash from the past, triggering a memory of a distributed operating systems class I had in the 1990s. The concept of loosely coupled systems was new for me back then and made a big impression, so I dug out my old textbook (yes, I kept them all!) to refresh my memory. The textbook was "Modern Operating Systems" by Andrew S. Tanenbaum.

Skimming through the material, even though it's dated, it's still relevant to today's cloud environment. While the Tanenbaum book was focused specifically on operating systems, Jorge's cloud development recommendations of "use independent components", "design everything as a black box" and "load-balanced clusters of black boxes" have much in common with a distributed OS design.

Tanenbaum offers much more detail in his section on design issues of distributed systems that seems relevant in this context, with the first being transparency.

• Location transparency - we want to design software so that the actual location of other resources is irrelevant. They could be in the same local Amazon zone, or they may be halfway around the world - it should not matter
• Migration transparency - not only must we not care where the resources are, we also must allow resources to move about seamlessly
• Replication transparency - we must be able to make additional copies of resources without side-effects
• Concurrency transparency - we should be able to share resources concurrently
• Parallelism transparency - Tanenbaum points to this as the most difficult to achieve, the ability to process in parallel seamlessly without the need to explicitly cause that to happen

We may be designing black boxes, but they need to be black boxes that can operate transparently with one another.

The other important design characteristics that Tanenbaum discusses are flexibility, reliability in terms of availability and fault tolerance, performance, and scalability. I think these points are a bit more obvious and won't add any further explanation.

Cloud Computing Security

The other main point I've been contemplating since the talk is in the area of security. Being the development security evangelist at my company, it was natural that I'd focus in on the brief security portion of the talk. I'm sure that an entire meet-up could easily be filled just on the topic of security, so the single slide on the topic rubbed me the wrong way.

Jorge's bullet points were as follows:

• Use de-perimiterized security model
• Create distinct network Security Groups for each Amazon EC2 instance cluster
• Use group-based network rules for controlling access between components
• Restrict external access to specific IP ranges
• Encrypt data “at-rest” in Amazon S3
• Encrypt data “in-transit” (SSL)
• Consider encrypted EBS file systems for sensitive data

While these seem like a good starting point, I want to delve into a little more detail on some of the points.

De-perimiterization, as I understand it, means moving the burden of security onto individual machines and applications. While this pushes the security to where the threat is, it seems to me that it also raises the maintenance overhead of security and I would think that could lead to a higher risk of not keeping all of the instances in-sync and current in terms of their security footprint. I suppose the next two bullet items are meant to address that issue to some extent by using security groups, but then doesn't the group somewhat defeat the idea of de-perimiterization? In a smaller network, relying on groups seems reasonable, but I wonder how well it scales unless a hierarchy of groups is introduced, but then it's no longer de-perimiterized. This isn't my area of expertise and I'm just speculating. I tried to find some writings on this topic by people more knowledgeable than me, but haven't found anything relevant yet. I'll update this post if I do.

The three encryption-related bullet points, "encrypt data 'at-rest' in Amazon S3","encrypt data 'in-transit' (SSL)" and "consider encrypted EBS file systems for sensitive data," all bothered me. I don't necessarily feel safe just because something is encrypted, especially if the storage device it's encrypted on isn't under my control. As Bruce Schneier wrote very eloquently, "As soon as you give up physical control of your computer, all bets are off." Always a good read, he further writes,

In the meantime, people who encrypt their hard drives, or partitions on their hard drives, have to realize that the encryption gives them less protection than they probably believe. It protects against someone confiscating or stealing their computer and then trying to get at the data. It does not protect against an attacker who has access to your computer over a period of time during which you use it, too.

Since Amazon's entire AWS infrastructure is basically a black box to us all, I'm skeptical that we should rely in any way on encryption for very sensitive data.

Closing

Overall, I really enjoyed the talk and wish the development points could have been discussed in much further detail.  It definitely gave me much to think about and highlighted topics for further reading. Hopefully, more meet-ups will be scheduled to delve into development issues for the cloud.

Definitely this is way out of my area of expertise, so I sometimes wonder why I'm being included in all of these discussions, but it's pretty fortunate that I am because it's been a great learning experience. I imagine that if all programmers had more visibility into the nuts and bolts of the network architecture they had to work with, they'd generally produce more secure, robust, better performing code. Most of the time, though, I think that's just not practical from a business operations point of view.

If someone had asked me, "hey, do you want to come to this meeting and discuss this blah, blah, blah network architecture stuff with us?", I probably would have rolled my eyes and said "yeah, right." I'm sure glad no one ever asked.