Sunday, November 21, 2010

Azure management

In the last days of October, Microsoft announced that it is going to release remote desktop access to Azure instances.
That is very nice. However, despite the fact that you will be an admin on the instance and will be able to install and do anything, all changes will be ephemeral.
There is no way to save the modified image, and the next time it is restarted all changes will be gone.

This is worse than Google App Engine, who which gives your applications the illusion of a single hypercomputing instance. You don't have a VM for every role, at least not knowingly. By decoupling the application runtime from running VM instances, Google is ready to use whatever computing platform innovations that will happen. Azure, on the other hand, still gives you the responsibility to manage scalability by yourself.

This is also worse than EC2. In EC2 you have the option to bundle a running instance to a private image, so any modifications you make can be saved for future sessions.

The only good thing about this feature is the ability to debug your application, and I don't underestimate this new capability.

Monday, October 18, 2010

Red vs Blue

A couple of days ago, I had the privilege to listen to a webcast by Hasan Rizvi, Senior Vice President for Oracle Fusion Middleware and Java Product.
Hasan spoke about the new Oracle Exalogic product, and about how this new product is going to revolutionize the datacenter and provide cloud computing capabilities.

Unfortunately Mr. Rizvi's talk was not about cloud computing, public or private. Neither it was about datacenters. All I could see was a sniper rifle targeting IBM's mainframe business.

Oracle and IBM have a long lasting relationship, framed by both intense rivalry and business cooperation. Although they competed in the database market, an Oracle database running on AIX was a favorite enterprise configuration. This stable state of affairs was not heavily disturbed when Oracle started foraging into the enterprise integration business. It's SOA family of products, running off the Oracle Application Server, were mostly used by heavily committed Oracle shops, and were no match for the stability, configurability and performance offered by IBM's WebSphere brand and the other leaders of the pack.

All of this changed since 2007, with the acquisitions of BEA and Sun.
BEA's dowry included the WebLogic server, vastly superior to Oracle's OAS, and the AquaLogic suite, which was a better line than Oracle's own. Both lines offer real competition to the WebSphere brand. BEA's legacy also included Jrockit and Tuxedo.

Tuxedo deserves a special consideration: It is used to offload applications from IBM's mainframe into distributed systems, and combined with Oracle's aggressive marketing organization it may now pose a real threat to IBM mainframe business.
However, not all mainframe shops run CICS. Many modern mainframe workloads are today based on Java, specifically on the WebSphere Application Server for the z/os. Until now, there was no real substitute for the benefits of MIPS, integration and security of WebSphere based Java on z/os.

And then came Sun... With the merging of Sun, Oracle now has full control over Java, and a private line of servers and storage. This doesn't spell like good news for IBM, that is heavily invested in Java based technologies, and is a major storage vendor.
It all culminated in the aforementioned Exalogic webcast. All of the comparisons, benchmarks and jargon used, were aimed at either current IBM mainframe users or mainframe wannabes who want to have the power of a mainframe on distributed systems. Even the price/performance table on slide 21 compares Exalogic with IBM's Power 795 server. Who else is likely to dole out $1,075,000 for a piece of hardware?

And what did IBM do? It ditched its support of the unassociated Java development in the Apache Harmony project, and went into the Java bed with Oracle.


See the recorded webcast and the slides here:
http://w.on24.com/r.htm?e=244865&s=1&k=7C946C00C82CA0F93EA4E95A5A6BA196

To download only the slides use this link
http://event.on24.com/event/24/48/65/rt/1/documents/slidepdf/webcastexalogic1012b.pdf

IBM gives up on Apache backed Java and joins Oracle
http://www.sutor.com/c/2010/10/ibm-joins-the-openjdk-community/

Oracle sues Google over Java standards
http://news.cnet.com/8301-30684_3-20013546-265.html

Friday, October 1, 2010

Cloud Security Architecture Matters

Not all cloud services are created equal. Clouds are architected by flesh and blood men and women, and because the are no cloud standards yet, the architectural choices are invariably different.
A couple of months ago I was looking for differences between various cloud vendors' API implementations, to show at a local OWASP meeting.

And differences I found. The most important difference is in the way users present their credentials to the service, and how the service ensures that it receives a valid request.

To make things comparable, let's look at the way 3 leading cloud vendors (Amazon Web Services, GoGrid and RackSpace) authenticate and authorize usage of their cloud resources.

We care about the way the service ensures that it receives a valid request, because we want to minimize the risk of account hijacking, and to minimize the risk of action replay.

A hijacked account means that a third party does unintended actions using resources that are tagged as belonging to the account owner. The third party can use the account for unwanted activity, such as distribution of illegal materials or promotion of spam, and the bill is handed out to the account owner.

Action replay means that someone may repeatedly send identical commands to the cloud infrastructure on behalf of the account owner. At best it is just a nuisance that may cost a little.
At worst, it may enable a third party to replace valid content with invalid, or even malicious content.

I am going to compare the basic action of listing the contents of the cloud objects container.
To make long things short, here is a brief description of the results.
  • All APIs make use of the HTTP protocol, with some custom extended headers.
  • All APIs require a public access identifier and a secret key shared between the account owner and the vendor.
  • AWS does not need the secret key in plaintext. It requires a unique signature for each request, making it extremely difficult to do any harm to the account, even if the request is somehow intercepted on the way.
  • GoGrid does not need the secret key in plaintext. It requires a signature as part of an authentication request, and returns a security token that is valid for a period of 10 minutes, and for all actions within 10 minutes. 
  • RackSpace requires the secret key in plaintext as part of an authentication request, and returns a security token that is valid for a period of 24 hours, and for all actions within 24 hours.