Skip to main content

Impressions from a SaasCon – CloudCon


Header_stripI’m sitting at CloudCon III – SaaSCon 2011.  It’s marketed as a Cloud Conference with a focus on Software as a Service.  Here’s what I’m seeing…

a.  Computer hardware vendors selling small footprint office workstations.  It’s not a surprise that computer vendors for the office have finally decided to abandon the standard desk-drawer PC box for a cigar sized box.  (Anyone who opens a standard PC box will find the components would fit in a cigar box anyway, the rest is open space or fans.)  The surprise is it took so long and that they’re selling them as “cloud workstations” and spending their money trying to market them at a Cloud Conference.


b.  Network hardware vendors selling the next speed in network infrastructure, 10 gigabit.  Apparently since everything’s “in the cloud” you need yet more network bandwidth to get to it.  This is some nice marketing fluff since Cloud doesn’t increase your bandwidth needs, it just shifts it from inside your internal network to some external vendors as well – to which your network connections are inevitably slower simply due to WAN costs.  As far as the internal network goes, network storage devices, SOA and web services and heavy application infrastructure has already resulted in the massive network speed and capacity increases.  Not that I’d complain about deploying apps or integrations on a 10gbit network, it certainly makes non-local devices respond even more as if local.  But again, not new, not “cloudy”, just another marketing ploy.


Anyone notice I haven’t mentioned anything Software as a Service oriented yet?


c.  Consulting vendors.  “We’ve got Cloud experience and expertise.”  Sure you do.  Reminds me when early in my career I was seeing advertisements for “5 years of Visual C++ programming experience” when Visual C++ had only been general release for 1 year.  On the serious side, I did have a conversation with a major consulting vendor division VP who told me they have started recommending the use of some “private cloud” resources – which they translate to mean some storage or computing resources hosted in the consulting vendor’s data center.  So for some consulting vendors Cloud means outsourcing a customer’s storage or computing requirements to the vendor data center and/or hosting the customer’s applications for them in the consulting vendor data center.


d.  Utility service vendors.  Symantec “virus protection as a cloud service”, somebody offering Fax as a Cloud service (there’s something incredibly weird about offering a 1980’s technology as a 2010’s cloud ability), central Email management as a Cloud service, and Telephony as a Cloud service.  The last one is kind of interesting though again not what I think of when I think Software as a Service.  Since the PBX moved to VOIP (voice over IP) and the office phone handsets moved to TCP/IP network connected digital devices (the less technical may not have noticed over the last 5 years their office phone moved from being connected to a phone wire to being connected to the office network), it makes sense you could move the PBX to a Cloud service.


e. The Big Vendors.  Did you know IBM offers cloud services?  IBM Smart Cloud!  It’s IBM, it’s Cloud, it’s Smart.  Marketing at it’s best.  Not much to actually say or show beyond “we’ve got lots of data centers and cloud offerings around the world”.  Ok, we know it’s IBM and they’ll (probably) make just about anything you want work…if you’ve got money and time.


f.  Data center hosting vendors.  They can host your servers, they can virtualize for you, they can host your storage, your backups, your network services…oh and by the way they’ll host your Private Cloud (which for them is just your collection of servers in their data center).  A minor twist on what they already do.


f.  Far off in a little corner by themselves were a few real Software as a Service vendors.  A CRM vendor, a Project Management vendor, real life Software as a Service vendors offering their applications and their abilities and various pricing models.


Net net, it tells me that Cloud and Software as a Service remains a confusing poorly defined poorly understood tech space.  Every IT business marketing department is trying to take advantage of it and rebrand their abilities “Cloud”. 

But like the hype cycle for SOA, many try but not that many are offering actual value in the space.  The Cloud and Software as a Service market has a lot of growing to do and maturity to gain before it stabilizes.  There’s definitely value to be gained right now, but also the possibility to be taken by ridiculous claims and expensive products and services offering marginal value.

Popular posts from this blog

Integration Spaghetti™

  I’ve been using the term Integration Spaghetti™ for the past 9 years or so to describe what happens as systems connectivity increases and increases to the point of … unmanageability, indeterminate impact, or just generally a big mess.  A standard line of mine is “moving from spaghetti code to spaghetti connections is not an improvement”. (A standard “point to point connection mess” slide, by enterprise architect Jerry Foster from 2001.) In the past few days I’ve been meeting with a series of IT managers at a large customer and have come up with a revised definition for Integration Spaghetti™ : Integration Spaghetti™ is when the connectivity to/from an application is so complex that everyone is afraid of touching it.  An application with such spaghetti becomes nearly impossible to replace.  Estimates of change impact to the application are frequently wrong by orders of magnitude.  Interruption in the integration functioning are always a major disaster – both in terms of th

Solving Integration Chaos - Past Approaches

A U.S. Fortune 50's systems interconnect map for 1 division, "core systems only". Integration patterns began changing 15 years ago. Several early attempts were made to solve the increasing problem of the widening need for integration… Enterprise Java Beans (J2EE / EJB's) attempted to make independent callable codelets. Coupling was too tight, the technology too platform specific. Remote Method Invocation (Java / RMI) attempted to make anything independently callable, but again was too platform specific and a very tightly coupled protocol. Similarly on the Microsoft side, DCOM & COM+ attempted to make anything independently and remotely callable. However, as with RMI the approach was extremely platform and vendor specific, and very tightly coupled. MQ created a reliable independent messaging paradigm, but the cost and complexity of operation made it prohibitive for most projects and all but the largest of Enterprise IT shops which could devote a focused technology

From Spaghetti Code to Spaghetti Connections

Twenty five years ago my boss handed me the primary billing program and described a series of new features needed. The program was about 4 years old and had been worked on by 5 different programmers. It had an original design model, but between all the modifications, bug fixes, patches and quick new features thrown in, the original design pattern was impossible to discern. Any pattern was impossible to discern. It had become, to quote what’s titled the most common architecture pattern of today, ‘a big ball of mud’. After studying the program for several days, I informed my boss the program was untouchable. The effort to make anything more than a minor adjustment carried such a risk, as the impact could only be guessed at, that it was easier and less risky to rewrite it from scratch. If they had considered the future impact, they never would have let a key program degenerate that way. They would have invested the extra effort to maintain it’s design, document it property, and consider