Everybody wants an “Enterprise Cloud” these days, even if they work for a smaller business, but what exactly does that mean?  What is an enterprise cloud solution?

Here’s a list of 5 key features to look for in a cloud solution that will help you decide if it’s enterprise ready:

Choice

• Description: In the enterprise, there is never a one-size-fits-all solution.  For any problem.  Ever.  This is why nearly every large enterprise has one of everything.  They have applications running on multiple databases, operating systems, and programming languages.  Their developers run many different IDE’s.  There’s no reason to think the cloud space will be any different.
• Tip: The enterprise cloud solution you choose must support multiple deployment clouds, both public and private, as well as multiple programming languages, components, and stacks.  The one true deployment stack, programming language, or cloud today will only be one of several in a few years.  Embrace this diversity and use the right tool for each job.

Reusable Library

• Description: Once you have an application or stack tuned and ready to use on your cloud of choice, you need to have the ability to save it and share it with peers.  Once you find a shared stack, it’s critical that you’re able to modify it further in case your use case is slightly different from the original creator’s.
• Tip: Your solution should have some private area for your company, departments, and individuals to save their stacks and applications.  It should be easy to share, modify, and reuse stacks on any cloud.

Cost Control

• Description: Nobody wants to get a huge public cloud bill out of the blue and have to explain it to their boss or Accounting.  Even private clouds are frequently using chargebacks (billed to your department) and showbacks (reports distributed to department heads – think “peer pressure”) to keep particular apps and departments from hogging all the shared resources.
• Tip: Make sure your cloud solution helps you visualize spending across all clouds, public and private, and applications running on them.  Automated budget enforcement is even better.

Integrated Monitoring

• Description: If business users can’t tell if their applications are up and running happily through a self-service web portal, they’ll have to call IT to get the information they need.  At some point, they’ll tire of this process and try to get around it by going elsewhere for their cloud solutions.
• Tip: An integrated monitoring and management solution, even if it’s basic, brings business users closer to IT.  Make sure your cloud solution will let end users know how well their stacks and applications are doing through a simple web page.

Support

• Description: Over time, your company will undoubtedly deploy applications into multiple clouds.  You may start with a public cloud today and eventually use a private cloud, or vice versa.  You may change programming languages, application servers, or databases.  In any case, enterprises and their business users demand support at every level.
• Tip: Try to find support vendors that continue to help if you change stacks, components, programming languages, or clouds.

If your solution provides each of these key features, you’re in good shape.  Your users won’t feel locked in to any particular technology, yet they’ll get the support they need to move forward quickly in an enterprise-friendly manner with appropriate controls.  Your enterprise cloud solution will make you and your internal customers happier and more productive in no time.

Subscribe to The Enterprise Open Source Blog via email

Follow @openlogic
Follow @CloudSwing

This work is licensed under a Creative Commons Attribution 3.0 Unported License
.

So, why does Open PaaS rock?  I’ll tell you, but first a little background.

As of today, a quick search of OLEX, Github, and SourceForge shows a total of 4,028 cloud-related open source projects in the world.  Google Code shows 163 million results when searching for “cloud”.  That’s a whole lot of cloudy open source.

Open source is ubiquitous and the cloud is ubiquitous, so it’s not surprising that there’s a lot of open source in the cloud (most public clouds are built on components such as Xen) and a lot of cloud in open source (projects like fog and OpenStack).  In this context, it makes sense that there are a number of providers talking about “Open PaaS”, a marriage of open source and the cloud that allows developers to rapidly deploy their applications in a cloud while avoiding restrictions related to proprietary vendor licenses and the like.

I think it means more than that, however.  In a previous post (How Open is Open? A PaaS Scorecard), I established some criteria for judging open PaaS solutions that I’ll summarize here:

Open PaaS makes it easy to deploy open source stacks in the cloud of your choice, either public or private, without constraining you to particular components or versions or locking you in to a particular vendor’s proprietary technology.  You also don’t have to worry about having your data held hostage because an Open PaaS implementation gives you direct access to your data at all times – no barrier to porting or exporting.  Finally, you can get development and production support on the open source components you deploy from any vendor you choose.

In a nutshell, Open PaaS is all about protecting your freedom to choose.

Without further ado, here are the Top 3 Reasons Why Open PaaS Rocks:

• Any cloud – deploy wherever you want, including multiple public and private clouds
• Any technology – Rails, Tomcat, LAMP, Node.js, Django, Redis, memcached, you name it – and no limits on components or versions
• No lock-in – no proprietary scripting languages, no data stranglehold, no friction to porting or exporting anything, multiple support options

OpenLogic’s CloudSwing is an Open PaaS that helps get you up and running with the open source stack of your choice on the cloud of your choice in a matter of minutes.  Don’t worry about being restricted to just a few stacks or open source packages because you can add anything you like.  After all, it’s your application.  You should be able to do anything you want with it.  You’ll also get direct access to every virtual machine you deploy, which means you can take your code and data with you at any time.  We respect your freedom to leave so you’ll have the confidence to stay.  You can also get developer or production SLA-backed support from us on any of the 700+ open source components we certify or you can get help from another vendor or internal staff.  As always, the choice is yours.

What do you think – is Open PaaS the perfect solution to life in the cloud?
Follow @openlogic
Follow @RodCope

Subscribe to Enterprise Open Source by Email

In this post, we attempt to define and score key criteria that should be used to measure and assess how well a particular Platform-as-a-Service (PaaS) offering meets the standard of “open”.

We examined five PaaS platforms: Cloud Foundry (from VMWare), DotCloud, Force.com, Google App Engine and OpenShift (from RedHat). We scored each against five criteria for openness: choice of infrastructure, choice of platform, portability, choice of support and open source licensing.

Cloud Foundry, DotCloud scored at the top with a B- on our open PaaS criteria. OpenShift was a little behind with a C+. Despite the fact that all three vendors claim to be Open PaaS, they still fall short on some of our key criteria of open source. In many cases they have announced the intent to provide for more choices and openness in the future. Google App Engine and Force.com don’t claim to be open, and not surprisingly scored a D and D-. Detailed explanations of the grades are provided below.

A Closed Beginning

As cloud computing has evolved, the early adoption has come primarily in the Infrastructure-as-a-Service arena. Early Platform-as-a-Service offerings (Google App Engine, force.com) gave developers little choice of languages, frameworks and runtime platforms. In addition, most of these PaaS offerings were tied to a particular IaaS provider, creating lock-in for those that chose them. As a result, developers and users gravitated towards more open IaaS offerings that let them pick and choose stacks and languages to meet their particular needs.

The Move to Open PaaS

The battle for adoption has now shifted, as a variety of vendors and cloud providers work to win hearts and minds of developers, thereby attracting developers and users to their offerings. Vendors in the PaaS arena are looking to define their offerings as “Open PaaS” – implying that they provide developers with choice and flexibility. However, current PaaS offerings still fall short of many of the criteria that might be expected for an “Open PaaS” label. In some cases, these early PaaS offerings have announced roadmaps that would expand their level of openness.

Criteria for Open PaaS

Below are the five key criteria that we used to score PaaS offerings.

• Choice of Infrastructure
  PaaS offerings claiming to be open should allow developers a choice of infrastructure. This includes not only choice of cloud, but also choice of operating system and virtualization technology.
• Choice of Platform
  Open PaaS offerings should allow developers choice of language and platform stack. Developers should be able to pick and choose stack components from web framework to application server to database. Developers should also be able to customize the platform, adding in additional components as needed.
• Portability
  Open PaaS offerings should provide for portability, allowing developers to move data, scripts, and applications to other PaaS or IaaS offerings.
• Choice of Support
  To fully realize an open PaaS offering, developers and users should not be locked in to maintenance and support contracts that have been common in the world of proprietary software. Developers and users should be able to choose self-support or get support on software components from a different vendor.
• Open Source Licensing
  In order to ensure portability, the components and tools in an open PaaS offering should be under open source licenses. This guarantees developers can move to other platforms without requiring costly re-tooling of applications.

Summary

Open PaaS is a new, and we think positive, development in cloud computing. There are several offerings that are beginning to deliver on the promise of open PaaS, but there is still some room for improvement. Do you have other criteria that you would use to measure open PaaS? Would you grade some of the offerings differently? We’d love to hear your thoughts and ideas.

One of the reasons they put ingredient labels on food is so you can make sure you won't eat something that might kill you.

Why don't we do the same thing with software?

Okay, maybe it won't kill you, but it could make you sick to find out that the software you installed contains an ingredient (sub-component) with critical security vulnerabilities or licensing terms you can't stomach.

With open source, you're able to discover all the ingredients, but it can take some work.  For example, many popular packages contain dozens of other open source components inside, often using a number of different licenses.  The top-level project frequently won't declare all the details of the dependent projects, some of which might violate your own legal or technical policies.

And what about your own code?  Do you know every open source package you use?  What about code coming in from developers in other groups?  Off-shore partners?  Have any of them copied and pasted code from the open source community into code they give you?

Make sure you're able to put the right label on your code, too.  You don't want to serve up anything to your end users and customers that might cause an allergic reaction.

One impact Cloud will have on open source is that it’s a new niche to be filled with a new ecosystem of OSS projects. Over the last 10 years, especially, whenever a new sandbox appears, it creates a flood of new projects. Think web servers (Apache, Nginx), web development frameworks (Struts, Rails), app servers (JBoss, Zope), NoSQL databases (Redis, MongoDB), map/reduce (Hadoop, HBase), virtualization (Xen, VirtualBox), mobile (Android, Funambol), and now cloud (DeltaCloud, Open Stack).

And because there can be any number of "competitors" in the open source world for a given niche, we'll see projects optimizing for different criteria.  In the cloud, this might be horizontal scalability, ability to run on a small footprint, ease of management, pluggability of PaaS-like services, security, performance, etc.

With so many new moving parts to experiment with and optimize, I expect to see open source explode in popularity due to success in high-visibility applications in and around the cloud.

There are now so many options when deploying to the cloud, enterprises are being faced with a Tyranny of Choice.  

They can get an IaaS (Infrastructure-as-a-Service) solution from:

• Amazon
• GoGrid
• Joyent
• Rackspace
• Savvis
• Slicehost
• SoftLayer
• Terremark
• VMware vCloud
• many others

Or they can roll their own IaaS by starting with:

• Cloud.com
• Eucalyptus
• OpenStack
• VMware
• many others

If they require services over and above basic IaaS, they can get a PaaS (Platform-as-a-Service) solution from:

• Amazon
• Azure
• EngineYard
• Google App Engine
• GridGain
• Heroku
• VMware/SalesForce
• many others 

And now Red Hat with their JBoss-based PaaS solution for cloud computing.  Underlying this solution is an Apache-licensed open source package called Deltacloud, which intends to abstract cloud provider API's to increase solution portability.  (The cloud is built on open source, you know.)

But Deltacloud is not the only cross-cloud enabler out there.  Not by a long shot.  There's also:

• fog
• jclouds
• libcloud
• libvirt
• lots more

That's a lot of options to get the basics up and running.  What if I want monitoring, security, disaster recovering, or other sprinkles on top?  Don't worry, there are lots of choices:

• AppDynamics – cloud monitoring console, performance stats
• BitNami – software packages, multi-cloud deployment
• Cloudkick – tagging, monitoring, multiple clouds, web terminal
• Cloudscaling – services around building private clouds
• CloudStatus – tracks Amazon EC2 and Google App Engine for outages, performance
• CloudSwitch – migrating enterprise apps to the cloud, VMware-based
• enStratus – management, governance
• InMage – cloud-based disaster recovery (DR) solutions
• New Relic – cloud monitoring console, performance stats 
• RightScale – auto-scale, management, deployment
• rPath – packaging, deployment, updates
• Scalr – auto-scale Amazon EC2, database backup & replication, monitoring, stats
• Standing Cloud – software packages, multi-cloud deployment
• Ylastic – Amazon and Eucalyptus monitoring

Wow.  With all those implementations, it would be great if there were industry standards to rely on so interoperability and portability were realistic goals.  Or maybe at least some cross-vendor groups focused on working together, even though some people think it's way too early for cloud standards.  No problem:

• Cloud Commons – Trip Advisor for the cloud
• Open Cloud Manifesto – let's all play nice
• Open Cloud Consortium – interoperability, testing
• Open Cloud Initiative – OCP (Open Cloud Principles) – definitions
• Open Cloud Computing Interface Working Group – IaaS interface API's

Ouch.

There are now so many choices in all these areas that paralysis may set in.  Inevitably, consolidation and fall out will take place over the next few years, but anybody who wants to jump in today will need to navigate some fairly murky (cloudy?) waters.

Paula Bach over on Port 25 talked about how to go hybrid yesterday, but she's not talking about cars.

She's talking about how proprietary companies are borrowing techniques from the open source community and how certain successful communities are going commercial.

For me, the interesting part is that she specifically calls out usability as an area where open source is typically lacking.  I couldn't agree more. 

I think one of the key reasons people stay with proprietary software vendors is that they put a lot of work into the user experience whereas it's usually an afterthought (or worse) for the average open source project.

Apple's success in designing and selling beautiful hardware and software clearly shows that people are willing to pay a premium for an enjoyable experience.  That enjoyment comes in no small part from the efforts of talented user experience experts.  These people focus solely on the user and how he or she will perceive the feel of a product, the consistency across features, the use of empty space, the judicious application of color, the use of intelligent defaults, and the like.

At OpenLogic, user experience professionals help design new features for our OLEX site to make sure we convey a lot of information in a manner that doesn't overwhelm our users.  We also continue to hone our layout, style, and content over time to incorporate end user feedback. 

All this takes work takes time, effort, and a skill set that's not found in the average programmer.  I think this goes a long way to explain why open source projects have trouble in this area.

Perhaps up-and-coming user experience professionals will realize that, just like programmers, doing a good job on a very public open source project is a phenomenal way to show off their talents to the world.  It's a great way to get real-world experience and an incredible resume booster.

So, come on all you creative designers and usability people, pick an open source project and show us your stuff!

BTW, I'm not surprised to see Microsoft talking about usability in open source.  It's what I expected from them as it plays into their strengths.

As Abhijit Nadgouda says in "Benefits of Online Repositories", it only takes a simple command or two in Linux to download and install or upgrade a package. If necessary, even dependencies will be downloaded and installed and you don't have to know anything about these new packages to make it all work in a matter of seconds. And you don't have to use a browser or any kind of GUI to make this all happen.

Isn't this all just a little too easy?

Well, it's not if you're a developer trying to get a job done quickly or you're working at home and don't really think about licensing terms or other obligations.

But what if you're working in an enterprise or at an ISV where it really does matter what the license is for not just the top level project but all dependencies and their dependencies and so forth? Are you violating any of your company's policies around software acquisition, in particular the policies related to open source licensing and distribution? And what if one of those packages in the tree has an obligation requirement that your company can't accept or is not willing to meet? How do you go about getting production support and/or indemnification for all the packages in your new hierarchy?

I think it's pretty easy to see that in certain settings there can be real issues related to the ease of software acquisition in our world of open source ubiquity. This is a problem OpenLogic helps to solve through our library of over 400 certified packages backed by indemnification and SLA support. We don't want to take away the ability for a developer to quickly find and install open source packages, but we do want to provide a thin layer of enterprise control and management around the process. We want to make it easy for developers to research and find open source that not only does what they want, but is also compliant with existing policies so they don't have to waste time ripping and replacing "illegal" components later.

So although it's great that the logistics of acquiring open source packages has gotten far easier in recent years, it's important for enterprise decision makers to realize that too easy can lead to even more headaches than a slightly slower process that enforces reasonable constraints.

This year at JavaOne was the first time since 1999 that I actually got to attend a bunch of sessions, thanks to not having to man an OpenLogic booth.  Overall, it was quite good.  There were quite a few parallel tracks and always something interesting in at least one of them.

Perhaps unsurprising, but the major themes were:

• SOA
• AJAX
• Dueling component frameworks (JBI, SCA, OSGi)
• Scripting languages for the JVM (JRuby, Groovy, Scala)

SOA 

I expected to see SOA take off this year, but not quite to the extent I found at the show.  It seems that 2008 is truly the year that SOA goes from paper to reality.  There were a number of real users presenting case studies around their migration to SOA, performance implications, and lessons learned.  There was a separate sub-pavilion of vendors, both open source and proprietary, showing off their SOA-related businesses, tools, and services.  I think it's finally getting real.

AJAX

The growth of AJAX (aka Ajax) continues to surprise me.  The number of AJAX-related open source projects seems to be increasing at a faster and faster pace lately.  Along these lines, I saw sessions pitching Javascript for both client and server, sites that allow pseudo-technical users to create their own mashups visually, a number of widget libraries that sit on common toolkits such as Prototype and Script.aculo.us, and sessions on improving the user experience.  I also attended a few sessions on advanced web security that should make AJAX implementation a lot more interesting for the average developer. 

One related presentation recommended that developers turn their application into a platform so ordinary users can create their own content and even deploy mini-applications a la the Facebook Platform.  This clearly doesn't fit every application, but it certainly helps increase your Network Effect when it does.

Dueling Component Frameworks

In the "too many ways to do this" department, I saw sessions on JBI, SCA, and OSGi.  Yes, they're all about integration, but they each have their own niche.  JBI seems to be about creating business components that can be integrated across vendors, SCA seems more about integrating your own components within an application, and OSGi seems to be about integrating components from multiple vendors in your application.  If that isn't crystal clear, it's not you.

In the OSGi arena, SpringSource has recently announced their Application Platform which is built on OSGi.  This has rightly set off a firestorm of responses as it means the company is placing a big bet against the traditional application servers.  It could win big, lose big, or simply be ignored.  Only time will tell.

Scripting Languages for the JVM

I've spoken on Groovy for years and on JRuby for a while now, but this year at JavaOne they both had a much larger following than I expected.  Each of them has improved so much in the last 12 months that it's truly hard to imagine how they did it.  Their feature sets, stability, and performance have gone from "interesting – keep an eye on it" to "wow, this is the real deal".  We now have JRuby on Rails versus Groovy on Grails, both of which are fast and easy to use.  Just like Java with its incredible JVM, your JRuby/Rails and Groovy/Grails code will continue to get faster, more scalable, and use less memory over time without any code changes on your part.  I can't wait to see how far they'll go by next year!

Parting Thoughts 

One last comment on the show.  It seems to me that Sun is really starting to get serious about making itself known in the open source space lately.  Of course, there's the MySQL acquisition and OpenSolaris, but there's also the fact that they have an open source tool that competes with VMware (VirtualBox).  They're also going to release a site soon that provides open source software project hosting similar to SourceForge.net or java.net.  Their IDE, NetBeans, is now arguably the best platform for development Ruby on Rails apps (or at least JRuby on Rails apps).  They've released a GUI that makes it easy to visualize MySQL performance on OpenSolaris through DTrace (there's also a NetBeans plug-in for DTrace).  The list goes on.

I think they've realized that they've never really been able to capitalize on software, so why not open source it and gain some attention via the halo effect?  They seem to be doing a good job of that lately, but we'll have to give the MySQL move some time before making the final judgment.

Microsoft just held their 2008 "MVP Global Summit" in Redmond last week.  This is an internal conference where they recognize awardees in a number of divisions and have over 400 technical sessions on a variety of topics.

The interesting bit for me is that Jamie Cannon reports that there's an informal meeting of Microsoft Rubyists going on at the event.  They're planning to discuss IronRuby, open source, and other topics.

Wow, Ruby is definitely getting some love lately.  I'm excited about that because OpenLogic has been a heavy user of Ruby, Rails, JRuby, and related projects for almost a year now.  The more people use it, the better it gets.  Once an open source project hits critical mass, it really takes off.

Speaking of which, I think JRuby will start to hit its stride this summer if they really do concentrate on Rails performance next as Ola Bini suggests.  I'm very much looking forward to having the option to deploy our OpenLogic Exchange (OLEX) on JRuby.  Mongrel is great, don't get me wrong, but I've always been a little suspicious of server processes that need to be monitored and restarted so frequently.  Call me crazy.

As we're on the topic of alternative Ruby implementations, I'm anxiously awaiting the first releases of IronRuby.  Will it really be the JRuby of the .NET world?  Will it be fast, reliable, scalable, and fully-compliant?  I sure hope so.  It would be great to have yet another deployment option even though I'd like to standardize on a JVM if I have a choice.

With Microsoft's growing interest in the world of open source and some internal Ruby programmers, I tend to think they'll get there.  Perhaps JRuby will have some real competition on Windows next year.