Cloud Zone is brought to you in partnership with:

Eric is the Editorial Manager at DZone, Inc. Feel free to contact him at egenesky@dzone.com Eric has posted 804 posts at DZone. You can read more from them at their website. View Full User Profile

The Unified Theory of Cloud: Bridging the Linux/Windows IT Chasm with PaaS

08.19.2012
| 6454 views |
  • submit to reddit

The content of this article was originally written by ActiveState Cloud Evangelist Diane Mueller.

Have you noticed? Traffic on the bridge across the Linux/Windows canyon now moves in both directions. Microsoft has remade Windows Azure with Linux support, and has included support for Java, Node.JS, PHP, and Python.  Linux developers have long leveraged  Mono to craft .NET apps to run on Linux. The cloud isn’t narrowing the tech platform divide. It’s closing it.

Which is why it’s all the more troubling that some cloud computing industry leaders insist on maintaining the separation, even when enterprises are demanding cohesive platform agnosticism administered within a single management framework.

Their argument goes something like this: There will always be .NET shops. There will always be Linux (*nix) enterprises. And ne’er the twain should meet. And in the odd case where the twain does actually meet, well, that enterprise might as well maintain parallel application lifecycle management platforms for each universe. That means distinct cloud platforms, each using its own middleware to serve its individual purpose. The .NET clouds runs over here, and the *nix clouds runs over there. Two clouds. Two stacks. Two platforms. And twice the administration, maintenance, training, and costs.

Bridge-building: More than just a good idea

But here’s the reality: The chasm must be bridged. In the real world, enterprises must have the flexibility  to run Linux applications and Windows applications…within the same cloud. Both stacks need to be supported with unified, compliant workflows. The very real differences in each stack’s constraints must be considered and then managed in a coherent, unified manner.

For far too long, the .NET and *nix operations worlds have been divided by tools, monitoring, deployment, and culture. There will always be applications specific to the .NET platform, and apps specific to Linux. But establishing separate management workflows and systems to support the platforms independently only adds to overhead, and complicates life for DevOps teams.

Dynamic languages (like Python, Perl, or Tcl) bridge the gap between Windows and *nix platforms, enabling cross-stack (or multi-stack) application development. The chasm-crossing continues with HTML and the web, where the UI is defined more and more by HTML5 and the browser. This path is reinforced with consumers and enterprises choosing mobile or tablet solutions that encourage a rethink of (and an innovatively open mindset for) development frameworks and deployment methodology.

Some vendors (including—in the interests of full disclosure—my company ActiveState) offer multi-language, multi-stack Platform-as-a-Service (PaaS) middleware solutions that run on multiple cloud infrastructures. A best-of-breed PaaS that supports multiple stacks (.NET & *nix) helps organizations support that platform agnosticism with a single PaaS management framework. For example, CloudFoundry.com is a great Open Source reference implementation of a multi-language PaaS. Tier3-backed Iron Foundry even added .NET stack support to the Cloud Foundry open-source foundation project.

PaaS technology is a means to manage and scale the highly-divergent details of multiple applications across stacks (whichever stacks they might be) and across clouds (be they public, private, or hybrid deployments). Effective cloud middleware enables DevOps teams to manage both .NET and *nix worlds in a unified manner, watching over disparate infrastructure through a single pane of glass, if you will.

Multiple PaaSes running in parallel? What do you have against DevOps?

It’s no longer necessary to separate the .NET and *nix worlds. In fact, it’s downright silly. Good CIOs reduce cost center expenses and maximize profit center revenue. Cloud computing can introduce great efficiencies into enterprise IT, but only if it doesn’t arrive with the risk of ballooning support costs. The real-world enterprise demands the flexibility to support multiple stacks and multiple development languages. If that brings untenable (and not scalable) complexity to DevOps teams, then cloud computing’s value-added benefits disappear in a mess of additional long-term operational support costs. For instance, enterprises that maintain .NET and *nix systems on separate architectures should plan for additional management resources, added platform-specific training, double the support expense, and duplicate system maintenance workflows.

The cloud computing paradigm shift: Freedom from stack-building drudgery

Appsecute CTO Tyler Power recently noted that “Platform as a Service (PaaS) is a total paradigm shift when compared to traditional development and deployment models.” His comment is an astute one. But the key is that PaaS middleware technology works best when it bridges the .NET/*nix divide, not when it sustains the separation. PaaS frees DevOps from stack-building drudgery, giving IT the needed (and unifying) tools and practices to manage both Linux and Windows sides of the house.

Enterprises should not have to choose between .NET and *nix.  As enterprise IT teams take advantage of cloud computing,  PaaS adds agility to application lifecycle management and helps unify two previously disparate workflows.  That’s a far more visionary approach than using it to preserve old-world silos. Choice is good, and right: Supporting multiple platforms via a unifying middleware layer is the future of cloud computing, and the right thing to do for the real-world enterprise. As for which platform is the best one? That’s now a judgment enterprises can let their own developers make.

 

Published at DZone with permission of its author, Eric Genesky.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)