Of course there is no point in doing anything other than "Hello World" if your not trying to solve some problem. There are plenty of problems out there but, if we think of The Cloud in terms of IaaS (Infrastructure as a Service), are there any benefits that can be derived from the introduction of The Cloud into our bag of tricks?
A common SOA use case we have seen involves a scenario in which an enterprise must marshal purchase orders(or any other type of document) from various trading partners into an internal enterprise system. Essentially:
- Expose network protocol based end points to get messages on to the bus
- Transform incoming data to internal format
- Route to the appropriate internal service
- Return a response
The diagram below describes the traditional approach. It uses an ESB to handle protocol translation, message transformation and routing. It has a lot of benefits in terms of flexibility and it gets the job done.
This standard approach satisfies the use case requirements but introduces a number of problems:
- Security - You've just poked a hole in your firewall to allow HTTP or FTP or whateverTP traffic into your enterprise
- Scalability - Is one ESB server enough? Or will success be your worst nightmare?
- Availability - What if you have an outage? Will your trading partner be able to resend? How many times can you ask them to resend before they start to think you may not be worth it?
- Cost - You need to buy the hardware, the space to host it, the power to run it and its got to be strong enough for peak load. During non-peak it just sits there. Doing nothing.
We're going to look at the specifics of how the infrastructure resources exposed by Amazon Web Services(AWS) provide an opportunity to address some of these issues (and raise a few new ones).
Okay, what did we do?
- Security - Trading Partners now communicate with SQS over SSL. They do not access your enterprise at all (no holes in the fire wall)
- Scalability - SQS is infinitely scalable. Additional EC2 AMI instances running the ESB can be spun up on demand as volume increases. More importantly they can be stopped when load decreases(see Cost).
- Availability - Redundancy across the AWS infrastructure. SQS is replicated across the infrastructure. In the unlikely event of an outage at Amazon your AMI can come up automatically at another Amazon site.
- Cost - If you process orders every day from 12:00am till 2:00 then run your AMI for 2 hours and bring it down. In coming traffic will queue up on SQS till your ready for it. You only pay for what you use.
Conclusion
AWS and IaaS are the best thing since whatever came before sliced bread. It solves all our problems, raises no new issues and even does your laundry. We can all go golf or fish or twitter or whatever.
No.
This is a new technology. Every new technology comes with its own set of gotcha's. So we'll start a new series of articles in which we'll implement our use case and see what happens. Some of the technologies we'll be using the following are:
- AWS Simple Queue Service (SQS)
- AWS Elastic Cloud Computing(EC2) Amazon Machine Image(AMI)
- Typica - A Java library that wraps the AWS API (Thank you David Kavanagh)
- Fuse ESB(ServiceMix) 4 - The ESB
- Hyperic - ESB monitoring
- JMeter - Testing(our "trading partners")
If You Find this Interesting
I'll be doing a presentation on it along with a full demo at the Emerging Technologies for the Enterprise conference being held in Philadelphia on March 26th and 27th. Hope to see you there.
Save This Page
