Matching AWS Services to Your Application

By John Paul Mueller

AWS application development requires long-term planning. Even though you deliver a product in increasingly shorter intervals, the goal is to create an application that is flexible enough and reliable enough to deal with organizational needs long term. With this in mind, check out the criteria you need to consider when matching AWS services to your application.

Working with services during the free period

Now that you understand what the services do, you need to start making choices about which services to try. Remember that you have only 12 months in which to make decisions about which services to use in your business. Twelve months may seem like a lot of time, but you’ll find that it evaporates before your eyes as you try to juggle your day-to-day responsibilities, meetings, and other needs.

In short, making a good decision on what to try during the limited time you have is essential. You may ultimately decide that AWS won’t meet your needs at all (as unlikely as that might seem, given all that AWS has to offer).

Focusing on the important issues during the trial period is the key to making AWS work for you. When thinking about AWS, you must consider these issues:

  • Cost: Determine whether AWS will perform the task for less money.
  • Speed: Decide whether the speed penalty of using the cloud outweighs the benefits.
  • Reliability: Ascertain the risk of using the cloud versus keeping the task in house. (The cloud may actually prove more reliable.)
  • Security: Define the security requirements for your application and then decide whether the risk of using the cloud is acceptable.
  • Privacy: Specify the application’s privacy requirements (especially the legal ones). Enduring a privacy breach when the data is housed on someone else’s system can prove hard to manage and cause permanent damage to a company’s reputation.
  • Flexibility: Consider whether the use of a cloud service will reduce flexibility to the point at which the application becomes unmanageable. In most cases, relying on the cloud reduces flexibility because the host reserves some configuration opportunities for in-house use only.

After you determine that using AWS poses acceptable risks and provides benefits to offset any negatives, you need to determine precisely which services to use. You may find that you can’t support some services because of legal or speed requirements, even if you have a cost incentive for using those services. Work through the services one at a time before you begin experimenting; doing so will save time that you can use to better test the services that will meet your needs.

Interacting with services after the free period

The free period will end at some point. During the free period, you experiment with applications and could possibly deploy simple applications. However, after you’re past this point, you need to consider how to continue interacting with AWS (or whether to try something else). The following list explores interaction needs from a variety of perspectives:

  • Redundancy: A huge problem with the cloud is that no one seems to realize that the cloud can fail. A recent news story serves to illustrate the point. The S3 service was out for a number of hours in the US-EAST-1 region. The problem with this outage is that it didn’t affect just S3 — it affected many other services, such as Dockerhub. In fact, the outage affected a huge swath of the Internet. If an outage like this can happen once, it can happen multiple times, and you need to plan for it by providing multiple data sources, some of which may not rely on the cloud at all.
  • Compromises: Every move comes with compromises of some sort. You may not feel as though you make compromises at first, but as the application grows into the various services, compromises begin to appear. During the application development stage, you need to determine what levels of services you require to ensure that the application continues to work as expected. Otherwise, you may get past the free period, have a lot invested in AWS, and only then figure out that users won’t ever be happy with the compromises you need to make.
  • Multiple provider options: AWS and other online services often provide support for options that work across cloud providers. For example, you can support Docker apps across Amazon, Google, and Microsoft cloud services. Consequently, using Docker means that you could have a plan B in place that doesn’t require you to jump through hoops when one of your cloud services has a failure.