I have just started working on an application for a client that requires integration with a credit card provider to take online payments. Nothing challenging here it seemed until I read the protocol specification of the payment provider my client is using. I wanted to deploy this application to the cloud to gain the benefits that this would bring – the pay per use, auto scaling, ease of provisioning etc. The payment provider, requires any applications that make payment requests to have a static ip address as part of its security policy – the ip address needs to be configured on the payment account.
Since I am developing this application in Java, my preferred deployment option is Amazon’s Elastic Beanstalk. This comes with a built in load balancer and can auto start extra application machine instances to handle increases in demand. However, a load balancer – or elastic load balancer cannot be allocated a static IP address under the Amazon Web Services facilities. On further investigation, I looked at the Google App engine and Microsoft Azure and these too, have no static IP address facility.
So, where do I go from here. Amazon does have a static IP address service – but the addresses are allocated directly to machine instances not load balancers, hence the auto scaling is lost. I now intend to look at other providers such as RackSpace to see if they offer static IP addresses on load balancers.
The above problem is not unsolvable, and I will find a cloud based solution, even if it may not have all the advantages of a full cloud computing platform service. I think the problem this highlights is less with the cloud computing providers, and more with the credit card payment providers requirement for a static IP address. I will let you know what solution I use.