Hardware Requirements for AWS Developers

No matter how many services AWS offers, you still require some amount of hardware to use the services. The amount of hardware you require when working with services in the cloud is minimal because the AWS hardware does all the heavy lifting. When working with services locally, you need additional hardware because AWS is no longer doing the heavy lifting for you. Therefore, you should consider different hardware requirements depending on where you host the AWS service.

Hosting the services locally

Hidden in the AWS documentation is all sorts of useful information about various services. For example, AWS Storage Gateway will connect an on-premises software appliance (an application combined with just enough operating system capability to run on hardware or on a virtual machine) with cloud-based storage.

In other words, you use the gateway to connect your application to the data storage it requires. It might seem as if running the gateway in the cloud would be a good idea because you wouldn’t need to invest in additional hardware. However, when you look at the requirements, you see that the AWS Storage Gateway comes with specific hardware, instance, and storage requirements. The important thing to understand is that the cloud presents limits that you must consider during any planning stage.

After you make certain that you can run your intended configuration, you can begin to consider the advantages and disadvantages of working in the cloud. For example, when hosting the service in the cloud, you get automatic scaling as needed, and Amazon performs many of the administrative tasks for you. However, for a realistic perspective, you must offset these advantages with awareness of the disadvantages, such as:

• Potential for lower application speed
• Need to maintain a reliable Internet connection
• Loss of flexibility
• Vendors going out of business

Even though basic hardware needs become less expensive, you do need to consider additional expenses in the form of redundancies. Most organizations find that the hardware costs of moving to the cloud are substantially less than maintaining a full IT department, which is why they make the move. However, you must make the move with the understanding that you have other matters to consider when you do.

Hosting the services in the cloud

When hosting services locally, you need to provide all the required infrastructure, which can get expensive. AWS does provide guidance on the minimum requirements for hosting a service locally.

A good rule of thumb when hosting services locally is to view any vendor-supplied requirements as minimums. If you don’t plan to load the service heavily, these minimums usually work. However, when you click the Optimizing Gateway Performance link, the first suggestion you see is to add resources to your gateway. Planning for too much capacity is better than for not enough, but getting the configuration as close as possible to what you need will always help financially.

Not all the services will work locally, but you may be surprised to find that many do. The issue is one of defining precisely how you plan to use a given service and the trade-offs that you’re willing to make. For example, when hosting a service locally, you may find it hard to provide the same level of connectivity that you could provide to third parties when hosting the same service in the cloud.

Defining a good development environment

After you know about the resources required for AWS and have accounted for the basics of your setup, you need to consider your development environment. The first issue you must consider is one of language. AWS doesn’t care what IDE you use (although the choice of IDE determines which features you have available for remote access), but it does care about language. You must verify that AWS supports the language of your choice for the service you want to access. For example, here are the choices for Simple Queue Service (SQS).

You can create a deployment environment using EC2. This tutorial describes how to perform this task. The main advantage of this approach is that you can theoretically develop AWS applications from anywhere because development no longer requires a local system with specific resources.

However, this approach is most definitely not free, and it means that you must have a reliable Internet connection from wherever you want to perform development tasks — which is not a problem at work, but possibly an issue at home. The cloud-based development approach uses the AWS Command Line Interface (CLI).

The main reason to use a localized development environment is that you retain access to local resources and the code libraries that your organization currently relies on to perform development tasks.

This option also has an advantage in reliability because you don’t rely on a remote connection to use it. If your Internet connection goes down, you can continue developing code (but testing isn’t possible until the connection is restored). When using this option, you do need additional bandwidth — at least for testing purposes and permissions for the AWS access through the organization’s firewall.

You aren’t limited to just two options when working with AWS. For example, you could use a local development environment but place your code on S3. The use of cloud-based data storage means that you can have localized setups in several locations (so that you retain access to local resources) and still gain advantages of cloud-based development, such as having access to your code from any location where you have a development environment configured.

This tutorial is also interesting because it tells you how to configure your development environment to use Elastic Beanstalk for project, source control, and repository use. As with a localized development environment, you still need required permissions for Internet access and enough bandwidth to handle the increase in data requests to make this option work well. In fact, the bandwidth requirements are higher than a local configuration, and the development environment must work with remote resources.

Choosing the correct development environment isn’t easy. In many cases, the choice becomes one of personal preference and organizational requirements. For example, using a cloud-based development solution might not be an option when dealing with sensitive development tasks; security needs could trump other wants.