Welcome!

Security Authors: Yeshim Deniz, Peter Silva, Liz McMillan, Pat Romanski, Hollis Tibbetts

Related Topics: Cloud Expo, SOA & WOA, Web 2.0, Security, Big Data Journal, SDN Journal

Cloud Expo: Article

Are Legos the Building Blocks of the Cloud?

Building cloud applications is about leveraging the bricks in the existing PaaS and SaaS services

Legos have been a part of my life for as long as I can remember. Some of my earliest, fondest memories involve Legos - starting from a small car made from a couple of simple bricks to very complex spaceships and wild creatures. I'm always amazed at how nicely and cleanly they snap together to create something solid, functional, and - in the case of the Millennium Falcon - amazing. Let's be honest, I'm not the only one occasionally sneaking down Target's Lego aisle to discover what new theme they've cooked up from the same core concept: clicking bricks together.

It's magical what happens to the brain when snapping those colorful, simple blocks into place. Visions of larger, cooler creations are conjured and we find ourselves scrambling for additional blocks to connect to create something that has a whole new purpose or function.

Okay, okay, where am I going with this?

Snapping Legos together is a perfect analogy for where cloud application development is headed. Just like IaaS has abstracted the infrastructure world into a single button push and PaaS abstracted the operating systems and database software support world into a simple and portable platform, SaaS provides a world of building blocks (or bricks) from which amazing applications snap together.

A new abstraction layer is the dotted line between PaaS and SaaS. Picture the various SaaS services you are using in applications as Lego bricks. You may have a brick for an email service like SendGrid, one for SMS text messaging like Twilio, and one for document storage like Dropbox. Combining these different building blocks empowers cloud application developers to quickly and inexpensively provide functional application components. Best of all, it allows the team to focus on building unique application functionality rather than fussing with replicating pre-existing capabilities such as messaging, payments, or documents.

Okay, now for the dark side. Lego's advantage is that it very tightly controls the spacing and size of those little bumps on every Lego piece ensuring that they easily snap together. Each piece must be manufactured to an exacting degree of precision - with tolerances in the 10 micrometers range. When two pieces are snapped together they must fit firmly, yet be easily disassembled and repurposed into something new. Other building block companies such as Mega Bloks and KRE-O have different tolerances and brick sizes - not all of the different manufacturers' bricks plug and play with Lego's. When it comes to plastic bricks, you're stuck picking a single manufacturer so all creations interconnect. Tying this back to SaaS, consider the bumps on each brick as a cloud service API. Different manufacturers' APIs are not typically interchangeable as there is no uniform, shared standard.

This is the dotted line between SaaS components and PaaS layers mentioned earlier. It represents an aggregation of the inconsistent vendor APIs into a single uniform set of calls organized by category into a single hub.

Say what?

Think of it this way - how cool would it be if a cloud Messaging Hub provided a single set of uniform API calls into the various email cloud service providers such as SendGrid, aWebber, MailChimp, Mailgun, and Postmark, as well as cloud SMS services including Twilio, Plivo, TeleStax, and Tropo? Hubs would be available for multiple categories such as storage (e.g., Dropbox, box.net) and for Payments (e.g., Paypal, Amazon FPS, Authorize.net). Hubs would be analogous to brick sets from different manufacturers, each providing a cool end product to play with - and to connect with one another.

The difference in this scenario is that the hub provides a single set of interlocking standards for ensuring the blocks function together. Once you integrate to SendGrid through the Messaging Hub, you are also immediately integrated to Mailgun and aWebber without adding a stitch of code. Call me a geek, but that is a beautiful building block creation. It saves development, test, and maintenance time - and that translates to money in the bank.

Let's take this a step further - something I've always wished Lego would do: add "smarts" to the bricks. Imagine if you snapped the Paypal and Twilio bricks together via the Payments and Messaging hubs, and they instantly knew that you wanted to send an SMS text message to a customer when a payment failed to be posted. Boom!

In my mother's words, that is "good and good for you".

These smarts can also be applied to failover. What if when you snapped two email provider bricks together (within a hub) such as SendGrid and Mailgun, with SendGrid as the main provider and Mailgun as the backup? See where I am going with this? You'd get a 2-fer deal - the smart bricks would automatically know how to:

  1. Failover to the secondary service should the main provider have a service interruption
  2. Pause the main service and switch over to the secondary service when capacity has reached (or is near reaching) its subscription service limit

Like those amazing building bricks sets from Lego, Mega Bloks, and KRE-O, building cloud applications is about leveraging the bricks in the existing PaaS and SaaS services whenever possible to reduce the time and cost to get an application to market.

The time has come to take that a step further and standardize across the building blocks (or bricks) from different manufacturers (cloud service vendors). When done correctly, it translates to 30%-50% reductions in the time and cost to build and maintain cloud applications.

I'm off to Super Target to see if Lego has released Iron Man 3 as a part of its new Lego super hero collection. Oh, wait, I mean to get some milk and eggs. :)

More Stories By David Honan

David Honan, vice president of product management at Cloud Elements, has a Masters degree in Computer Engineering from the University of Colorado. He started his career as a developer for an aerospace company and, in 1996, joined InfoNow Corporation (now Channel Insight) as its 6th employee: first as a developer and project manager, then with the sales engineering and product Management teams. Before joining Cloud Elements, David managed a cloud-based surgical procurement product at GHX. He, his wife Michelle, and three teenaged children live in Louisville, Colorado.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.