Why did I compare “Cloud” to “SOA”?

November 21, 2008 Leave a comment

Color me busted. Don’t I look good?

Right after publishing “Is the Cloud Getting ‘Clouded’” I got a ton (well; a lot for me) of email questioning my analogy of “overloaded terms” as comparing SOA to the Cloud.

Some on the mails were from CTO-types and techies of companies with whom I am working (thanks for reading! Click on my ads and buy a lot of something!!).

To avoid giving my opinion multiple times in emails, I’ll state it here. To those of you who emailed me: expect this link when I respond. Please note: this is not by way of defense, but rather of discussion .. I stand ready to receive all flames and pragmatic corrections to my words. With more brains and opinions, we are smarter overall.

First: I am not comparing “SOA” to “Cloud”. Some infrastructure and integration bits aren’t too far off though, a number of parallel technologies and methodologies exist:

  • Remote (from your application perspective) processes and data.
  • Calls made via Web service to gain access to the remote processes and data.
  • Services that expose processes and data on the remote system.
  • Return values from the web service calls.

Your application makes the calls and then acts on the return values to continue the work you need to accomplish .. but that really wasn’t my point.

By way of background, I published “Services Orientation – The Architecture Formerly Known As SOA – Introduction” a few years ago. In this post, I made the statement that I felt the term “SOA” was misused as a noun. I feel SOA to be a paradigm or a methodology, rather than the modified noun usage, e.g., “Our enterprise sports a ‘services-oriented architecture’”.

Yeah: let the grammar police arrest me for nuance. I will smile and nod.

In the same way, the purposes of the “Clouded” post was to point out my feelings that “Cloud” is being misused, although not quite in the same way: Cloud has become the “catch-all” phrase for services in the sky, however, at the 100,000-foot level:

The same “Cloud” (services and storage in the sky via the Internet), but different implementations, requiring different development architectures. However, similar web service access methodologies between the three. Clear as mud? Write me and I’ll connect you to the right folks on our side.

P.S.: On SOA, why just an “Introduction”, you might ask. You might also ask “where’s the rest of the posts”? To be frank: I got busy. By the time I got back to that series, many of the questions I raised were being answered by myself and by others. It is totally my fault for not connecting the bits together. Write me, and I’ll send you links that help, or take a call with you to help sort it.

Filed under Architecture, Cloud, Reference Posts

And the Space Needle Cowered in Fear ..

November 21, 2008 Leave a comment

.. from the onslaught of two noses.

SpaceNeedleCoweredInFear20081121

With apologies to fellow Evangelisto, Steven Woodward .. someone caught us in a candid (and spirited) chat whilst on an offsite in August 2006. A boat was involved, but obviously not a hairdresser. I was 20 pounds heavier at that time.

Steven and I have sent out an APB for the camera-carrying offender.

Filed under Fun and Games, Reference Posts

Is the Cloud Getting “Clouded”?

November 20, 2008 1 Comment

A bit. Not only is the term getting overloaded, dramatically-different offerings are being lumped into the single term: “Cloud”.

A hazard of bleeding edge technology, I guess .. remember how SOA was / is similarly overloaded?

Caveat: by the time you read this, it will already be out of date as the players are modifying their offerings and new players are entering the market.

Windows Azure, Google AppEngine and Amazon EC2 have different approaches and have staged server some level of service functionality in the sky. IBM has made announcements, and so on.

At the 100,000-foot view:

  • Windows Azure approaches the paradigm through database, workflow and ambient (user-specific or general) services that leverage our rich development platforms. If you’re already a .NET developer, Windows Azure is a natural extension of your skills. If you’re not, we’ve a variety of free tools, sample code and support to get you going.
  • Google AppEngine provides a large number of APIs-in-the-sky that connect to larger Google services like Google Maps, YouTube and more. Behind the APIs are other services, file and data storage, etc. PHP developers will find this environment to their liking.
  • Amazon EC2 allows you to stage discrete, scalable servers in the sky. Want a Windows Server with SQL Server 2008? Point and click, and you’re provisioned quickly. Linux fan? Point and click; you get the idea. Developers can code to their desired platform, deploying their applications to remote servers as they would in a data center. Amazon also has offerings for simple databases and file storage (both in beta) and recently announced an edge service.

VCs, angels and investors can benefit from Cloud offerings in a many ways:

  • No data center hardware investment. The Cloud provides the equivalent of a potentially unlimited data center for your use.
  • No fixed cost for co-located servers; if you own the machines within a data center.
  • No fixed cost for leased or shared servers at a data center.

Some thoughts:

  • No hardware helps lower costs for startup companies. This translates to the ability to use resources to make your application better, create more applications, invest in marketing, and so on.
  • Is your application going viral? The cloud offerings can expand capacity as your application needs and customer base grow.
  • Is your application underperforming? Tear it down and put up another.

Which approach is right for you and your company?

Filed under Cloud, Reference Posts

Traffic Data Collection via Cell Phone Signals

November 18, 2008 Leave a comment

Traffic monitoring is nothing new. The passive collection of data using cameras, radar and other devices has been going on for years.

Mapping services from Microsoft  (Bing Maps), Yahoo! (Yahoo Maps) and Google (Google Maps) even provide convenient overlays for the state of traffic atop their maps.

Oh. Bing Maps and Google Maps also shows traffic on secondary roads, giving you a true opportunity to select a different route.

I posted “Tracking Movement and Progress via Bluetooth” back in May, citing the intent of the Indiana DOT to track vehicles and pedestrians using Bluetooth transmissions. Even though Bluetooth is a very close-range signal (less than 10 meters in most low-power situations), sensors could be placed to collect information from passing vehicles (or people).

This kind of crowdsourcing is very powerful; big globs of data collected by ambient means (sensors listening for signals) can be presented to a system ready to aggregate and report status in real time.

Note that I didn’t say “analyze”. Real-time analysis is left to the user (you need to look at the roads you might travel and decide which routes to avoid). Ideal use of mobile device, I’d say.

Analysts and engineers could rehydrate and create models with the collected data after the fact. Performing BI and data mining operations, they could advance some hypotheses to improve traffic.

Long story short: the better the data (quality and quantity), the higher the likelihood analysts the opportunity to evaluate current patterns and applying this knowledge, make improvements to the traffic systems.

  • To improve quality, we want reasonable accuracy (over time) of a signal’s direction and location. From this, we can calculate average speed over distance. Knowing this speed will help analysts decide if there are enough lanes based on volume and average speed.
  • Applying ambient and environmental data will also improve data quality: the time of day, weather conditions and events / activity at the traffic endpoints will help analysts identify anomalies that may affect overall averages.
  • To improve quantity, we want more signals. We can improve this with more sensors and with collecting multiple types of signals. Rather than limiting collection to Bluetooth signals, add GPS and Cell signals to the dataset.

Comparing improved quality and quantity metrics to existing data collection methodologies will improve the ability of analysts and engineers to design better solutions and speed us on our way.

Filed under Leap Frogs, Reference Posts