A Loosely Coupled Cloud
"Build loosely coupled systems." That was one nugget of recurring advice given last night by Jorge Noa, CTO of HyperStratus when he spoke at a meet-up titled "Amazon EC2 Cloud Computing and Application Design" held at HackerDojo (see slides here - pdf and I also found the same slide show already online here as an O'Reilly Media Slideshare).
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:
- Build cloud apps, not apps in the cloud
- Virtualize the application stack
- Design for failure and nothing fails
- Design for scalability
- Loose coupling lets you maximize plug and play
- Design for dynamism
- Build Security into every component
- Leverage native cloud storage options
- Leverage best cloud Management Tools
- 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.
VLANs and NICs and Switches, Oh My
I've been learning more than I ever wanted to know about the construction of VLANs for special purposes lately, i.e. maximize the performance of an application by working on one particular network bottleneck. By adding an additional nic card to the offending machines, putting those on their own VLAN, and routing particular applications through that rather than the usual load balanced route, we were able to profoundly improve on some network congestion issues. It's just fascinating to watch the network traffic on the various VLANs at the switch between the various machines and see exactly how these little tweaks can really make a difference.
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.
safe to click,
no evil Javascript on these links
Menu
