✡ In the last 6 months I have spent time figuring out how to get java applications running in the cloud – EC2, private, or otherwise. While there seems to be a great deal of progress in making this easier for me as the developer/deployer there still seems to be a problem with the way many java applications have been developed.
First, I will say I do not have as deep a knowledge on how MS products operate in this space, but I would imagine that some of the same things I have observed and learned do apply.
Next, in reference to the blog post I pasted in above, Resin won out in a “taste test” for some rather complicated applications I have worked on recently. It is also used on some pretty heavy weight sites – CNET, Evite, SalesForce.com, etc… they continue to push the envelop to make it easier to deploy, control, and monitor applications as they spread out in the cloud. This is one way to set the baseline infrastructure in a more flexible/cloud model – through autolearning, autodeployment, and other means to push the elasticity up into the application layer. That said, this is a leap forward, but might be unnecessary in the beginning because traditional applications and most app servers can scale vertically and horizontally with relative ease these days. If all you can manage is to drive saving into the setup by buying a flexible CPU model that still should get you somewhere, but not to the holy grail of utility compute (pay as you use, like electricity).
The real issue that I have seen is that applications need to be broken up into functional service chunks better. This will allow each service to scale as needed. Because to reduce costs and increase system function on demand we need to drive granularity into both the infrastructure – from a systems & billing POV as well as granularity into the application to match.
The physical analog that I have been using to describe this when I have a white board in front of me is a mixing board. If you have fixed hardware and fixed software you are in effect pushing all the levels up at once, there is zero fine tuning. When you have granularity driven into every level of the system you can push individual levels up and down as needed. In case I am not conveying this correctly, when a level is at 10 it might be 1000$/hour and when it is at 1 it might be 100$/hour.
The CTO of an e-commerce vendor I spoke to recently, as well as a solutions architect at a major cloud provider, have reinforced what I have noticed as I tested this out. The e-commerce site has over 30 services, some as a private cloud vendor and some on EC2. When you combine this with Akamai you end up with a radically different notion of what an applications is. No longer a simple deployable war/ear/etc… with collateral content, it is many components spread around the world.
The next big question is how do you test such a distributed new style application? That is where good decoupling, unit testing, TDD, and other agile testing methodologies come in.