Out of curiosity, I had a quick try to see if VMWare can run on EC2. Before terminating the Win2003 (32 bit) server I had running on EC2, I installed VMWare client on it and launched image with it: got a nice error message telling that VMWare is not compatible with Xen hypervisor used by Amazon EC2.
Had a 2nd try with the open source VirtualBox (from Sun). When I launched a virtual machine in VirtualBox (install CentOS from ISO image), the whole EC2 image came to a halt. No problem, I was done with it anyway.
Lesson learned: running virtualization solution on EC2 doesn't seem to work
Note: it should be possbile to convert VMDK to AMI using QEMU
Saturday, July 25, 2009
Thursday, July 23, 2009
Loosely coupled: loosely defined, loosely understood
"Loosely coupled" is a heavily used term in SOA land. To me, loosely coupling means the use of a standardized contract/interface (aka canonical message format) and preferably also asynchronous messaging such as JMS.
Found an interesting presentation that describes the "facets" of loosely coupling. And it compares the different types of web services with relation to "decoupling".
Found an interesting presentation that describes the "facets" of loosely coupling. And it compares the different types of web services with relation to "decoupling".
Monday, July 20, 2009
Belgian weather and water keep Google cool
So Belgian cold weather also has its value: less energy required to cool the Google data center. Interesting to learn as well that the data center's location is nearby a canal to obtain cheap water.
For the location of Google's data center in Belgium itself (Mons): there must definitely be a relationship with the fact that Elio di Rupo is both president of the socialist party and mayor of the town of Mons.
For the location of Google's data center in Belgium itself (Mons): there must definitely be a relationship with the fact that Elio di Rupo is both president of the socialist party and mayor of the town of Mons.
Java Message Service - 2nd edition
JMS or Java Message Service is the basis and standard API for asynchronous, reliable messaging.
After 10 years, a new (2nd) edition of the book "Java Message Service" was recently published. Mark Richards reworked the original edition by David Chappell (ex-Sonic, now Oracle) and Richard Manson-Haefel.
Having just skimmed through the book, it did look very intersting. Obviously an extensive treatment of the API (and thus specification). But nice to see code samples based on ActiveMQ, some explanation of character encoding, use of non-JMS clients (.Net, C++), dynamic vs. administered queues, message driven beans (MDB) and Spring and Security.
Some topics that did not seem to be addressed:SOAP over JMS, REST-like access tot JMS providers, persistence mechanisms (database or file based),
Messaging solutions are still the core backbone for many ESB's and integration solutions. The JMS API remains the standard abstration layer for both Java (ActiveMQ, SonicMQ, OpenMQ, Fiorano) and non-Java based messaging (Tibco , WebSphereMQ, SoftwareAG WebMethods, Oracle AQ) solutions.
After 10 years, a new (2nd) edition of the book "Java Message Service" was recently published. Mark Richards reworked the original edition by David Chappell (ex-Sonic, now Oracle) and Richard Manson-Haefel.
Having just skimmed through the book, it did look very intersting. Obviously an extensive treatment of the API (and thus specification). But nice to see code samples based on ActiveMQ, some explanation of character encoding, use of non-JMS clients (.Net, C++), dynamic vs. administered queues, message driven beans (MDB) and Spring and Security.
Some topics that did not seem to be addressed:SOAP over JMS, REST-like access tot JMS providers, persistence mechanisms (database or file based),
Messaging solutions are still the core backbone for many ESB's and integration solutions. The JMS API remains the standard abstration layer for both Java (ActiveMQ, SonicMQ, OpenMQ, Fiorano) and non-Java based messaging (Tibco , WebSphereMQ, SoftwareAG WebMethods, Oracle AQ) solutions.
Monday, July 13, 2009
Cloud Application Architectures
Holidays in beautiful Umbria (Italy) give the opportunity to do some reading. With a strong interest in clould computing, I read Cloud Application Architectures by Georges Reese this summer. Around the same time last year (2008), I read Programming Amazon Web Services by James Murty.
The book "Programming Amazon Web Services" was really good in 2008. It describes the different Amazon offerings and how to invoke the API's using Ruby. But Amazon is extending its offering a a rapid pace, e.g. with fixed IP addresses and block storages (like NAS). So James Murty's book is in need for a 2nd edition.
"Cloud Application Architecture" goes up the stack to a higher abstraction level and explains how to deploy ("architect") application on the Amazon cloud. Georges Reese has gained practical experience while deploying the Valtira (Web Marketing) application on Amazon.
Reese covers some very interesting topics:
We may expect many more cloud books in the coming months but "Cloud Application Architectures" brings quality content well ahead of the pack.
PS: podcast with interview of George Reese available here, same quality and content
The book "Programming Amazon Web Services" was really good in 2008. It describes the different Amazon offerings and how to invoke the API's using Ruby. But Amazon is extending its offering a a rapid pace, e.g. with fixed IP addresses and block storages (like NAS). So James Murty's book is in need for a 2nd edition.
"Cloud Application Architecture" goes up the stack to a higher abstraction level and explains how to deploy ("architect") application on the Amazon cloud. Georges Reese has gained practical experience while deploying the Valtira (Web Marketing) application on Amazon.
Reese covers some very interesting topics:
- Load balancing with software load balancer in the cloud vs. HW load balancer on premise
- Cost comparison with sample calculation; : making the comparison with operating application on own hardware or in the cloud
- (High) Availability with some sample calculations
- Use of stateless application servers
- (Virtual) Machine images: outweihing generic vs. specific machine images; the use of startup-scripts with user-data
- Privacy: example on how to separate private information and encrypt it with key generated for each customer/partner/...
- Database management: outweighing clustering vs replication, whereby replication is usually considered the better option; the slave(s) can be used for read operations and backups; solutions for primary key generation and optimistic locking
- Data Security: e.g. through file system encryption
- Network security: security groups as alternative to firewalls, the fact that network intrusion detection cannot be used in Amazon context, why network level encryption still makes sense even if machine cannot see eachother's traffic at Amazon, system hardening (Bastille), Host intruction detection (OSSEC), anti-virus
- Disaster Recovery, backups, recovery, redundancy,
- Scaling & capacity planning, the non-sense of auto-scaling
We may expect many more cloud books in the coming months but "Cloud Application Architectures" brings quality content well ahead of the pack.
PS: podcast with interview of George Reese available here, same quality and content
Subscribe to:
Posts (Atom)