J2EE has been with us since 1999 and a reasonably standard model for application architecture has been developed. The application is split into two parts: the one which handles the user interaction and presentation layer (webserver), and the second which provides the implementation of the business logic (appserver). The appserver exposes the business logic through EJBs. The webserver and appserver communicate via RMI-IIOP (Remote Method Invocation-Internet InterORB Protocol) or AJP13. Here's an old (and admittedly basic) diagram of the typical application component layout:
The actual implementation uses a load-balancer/firewall which is public-facing and only permits requests on ports 80 and 443 (HTTPS). Beyond that is the de-militarized zone (DMZ) which contains the webserver(s). After data passes through a second firewall it reaches the appserver layer. One of the primary considerations with this architecture is scalability. Each of the components can be, and frequently are, clustered. As you can imagine, depending on the number of clients anticipated, you start looking at a significant financial investment for the server farm you need to create for a high-volume site.
You also have to consider the other costs of "rolling your own". You need multiple 'net connections for redundancy, obviously a UPS, physical security, etc. You also need to create a plan for how to recover from disasters. Finally, the number of servers needs to be able to actually support more than the expected traffic volume since incoming requests tend to be "bursty". If you're running an e-commerce site then you have additional requirements for data security if you store credit card numbers; you'll need to be PCI-compliant and that can be an expensive certification.
In this "traditional" model, the webservers don't need to be particularly powerful so they can be inexpensive. They also out-number the appservers which have to be considerably more powerful, hence more expensive. The appserver and webserver functionality can also be co-located but, again, that would require more expensive servers. The advantage of this approach is that the webserver and appserver components can communicate via local EJBs, providing significantly improved performance. Hopefully you can now better appreciate the complexity involved in designing and implementing an enterprise application environment.
That's why the advent of the "cloud" model is so exciting. In addition to not requiring a substantial initial investment, it provides the scalability and flexibility required for enterprise applications. I previously mentioned e-commerce sites. More people these days are making their Christmas gift purchases on-line rather than braving the crowds at "brick and mortar" outlets. There's an interesting graphic of these seasonal variations on Google Trends here. One of the huge advantages of the cloud model is that one can secure additional capacity and only pay for how much they use. Adding additional capacity to handle seasonal variations such as Black Friday and Christmas is relatively painless.
Amazon EC2 is a mature platform which provides many features which contribute to deployment flexibility. Once you have a server provisioned with all required software configured, you can take a snapshot of the instance, making deployment of clones fast and easy. You can create custom security configurations (firewall rules) and use them when new instances are provisioned. Amazon's infrastructure is so flexible that they can even provision a private VPN. You can create reserved instances and pay only for the time that they're up and running. They provide monitoring capabilities and can even generate e-mail alerts when servers cease responding. You can provision load-balancer instances with fixed IP addresses. There's too much to mention here but they provide a free tier so that you can familiarize yourself with the various capabilities.
But the cloud model also requires you to re-think how your application is structured. As mentioned earlier, the webserver and appserver functionalities can be co-located on a single server or instance. This approach actually works rather well in the cloud because you don't have the overhead of using RMI-IIOP or AJP13 for communication between the webserver and appserver. But you also have to carefully consider the functionality provided by the appserver. Compute-intensive operations, such as document conversion, can be off-loaded to a few extremely powerful instances which are shared by all the appservers. Similarly, e-mail generation can be delegated to an instance and requests queued via JMS. So the cloud is not a panacea; there's still work to be done before deploying your enterprise application to this (relatively) new platform. But you can also think about it as an opportunity to really analyze your application requirements before deciding on an optimal configuration.
One final point. In addition to sizing of the instance, you have to decide which operating system to provision. Amazon provides a number of different Linux distributions as well as Windows®. The pricing is higher for Windows instances because of the licensing costs; many Linux distributions are still free. But different Linux distributions have different feature sets. Some provide MySQL, some don't, for example. It's easier to select a distribution based on your requirements than to add the components needed with yum or rpm. There are also performance considerations. Linux has a significantly smaller "footprint" than Windows and generally provides better performance on identical hardware. I appreciate the ability to run remote commands with ssh and believe that the investment in learning Linux and the powerful command-line tools is worthwhile. But for those shops which are more comfortable with the Remote Desktop Connection then they won't have to incur the Linux "learning curve" by choosing a more expensive platform. But never forget that Windows is less secure than Linux and you have to be able to accommodate updates which might require a reboot, knocking the instance temporarily off-line.
Copyright © 2014, 2015 by Phil Selby