Friday, August 1, 2008

Amazon Web Services

When the Amazon Simple Queue Service appeared about 2 years ago, I looked into it as a solution of message exchange between business partners. With its limited message size (only 4K) and message retrieval based on simple Amazon user accounts, I put the offering aside. The Amazon offering did however trigger me into wondering when the big Internet players (Google, Microsoft, Salesforce or Amazon) would enter the integration market.

But the 'big' players aren't entering the integration world (yet?). Alternatively, software vendors could cloud-enable their software. Or anyone could leverage the cloud and develop an integration system on system on top of it.

Some scenario's that I can envision, probably lacking some imagination here ;-)
  • upload messages to the cloud from which they can be polled and retrieved (e.g. some central FTP or JMS server)
  • service composition (something like Splice)
  • business processes managed in the cloud through BPEL process engine (like RunMyProcess)
  • service enabled integration solution (like Grand Central Communications once tried)
  • XML gateway/firewall that filters traffic, enforces policies and forwards requests to different back-ends
  • B2B hub (re-invention of the VAN)
  • SOA governance as a service (sharing services within a community)
  • Centralized SAML provider used by federation(s) of business partners
  • WS-Trust Security Token Service (STS)
To learn about cloud computing and see how it could be used for cloud based integration solutions, I went through the book "Programming Amazon Web Services" by James Murty.

Initial conclusion/impression after reading the book was that Amazon services still lack some important features. Some limitations of the Amazon services:
  • no fixed IP addresses, use of dynamic DNS required; with no URL pointing to the Amazon servers, own server in own data center required as main entry point
  • EC2 instances loose all state when they stop or die (partially addressed with backups at short intervals)
  • no SLA (except for S3), EC2 and SimpleDB are still "beta" (but so is gmail)
  • payment via credit card (no formal ordering/invoicing)
  • only forums to report and track problems, no formal communication channels
  • propagation latency of newly or updated S3 objects (without even guarantee that you retrieve the latest document yourself because there is no guarantee that S3 requests will be directed to the same location)
  • no transactions, e.g. when retrieving messages from SQS service
  • no relational database
  • no guarantees, everything on best effort
But since the publication of the book, a number of shortcomings were already addressed.
  • Elastic IP addresses now offer fixed IP addresses and do away with dynamic DNS. A single EC2 instance can load balance request to other instances.
  • Availability zones allow instances to be started in specific zones (read data center).
  • Persistent storage for EC2 now provides a real file system for EC2 surviving restarts (although file system can only be mounted by 1 instance).
  • And AWS Premium Support starts addressing the support issue.
So it seems that AWS can be used for some of my envisioned scenario's. Open source project will definitely offer their integration solution As A Service on the Amazon cloud. I'm curious to see if and when the 1st closed source integration vendor takes the same step.

No comments: