Castro Jose Dieguez - Beginning Amazon Web Services with Node.js

NY, United States

First and foremost is scalability , or the ability to rapidly deploy additional resources to support your application. Prior to the proliferation of cloud-hosting providers such as AWS, if demand for your application outstripped your hardware resources, deploying additional servers was an expensive and laborious task and often out of the capabilities of startups and small or medium-sized businesses. With your application hosted on AWS, you can allocate resources on demand, launching new servers and keeping your application online. According to the AWS white paper Architecting for the Cloud: Best Practices,

The ability to respond to demand for your application is known as elasticity . Being able to replace one server with 100 is useless if its not a strategic action. When additional servers had to be manually booted and configured for deployment in response to demand, the cost of doing so led many businesses/institutions to instead over-allocate resources. Instead of spinning up additional servers for a spike in traffic, the extra servers would just be left running at all times and required concomitant maintenance. With the elasticity of AWS, spikes in traffic can be detected, and additional resources can be automatically deployed. When the demand returns to normal, the application can be scaled down automatically to a normal state. Use what you need, and pay for what you usea simple concept that revolutionizes web application development. This saves time, money, energy, and reduces the barrier to entry for enterprise-level software.

As you can see, scalability and elasticity are great attributes to have in your application. These benefits also mean thinking differently about your role as software developer and architect. Shifting from developing in a fixed-hardware environment to a cloud-computing environment means that we are now cloud architects, in addition to software developers. This constitutes a major change in the way developers must think about web applications. For many of us, there will no longer be a system administrator or database administrator maintaining the infrastructure. (They work at Amazon, IBM, Google, Rackspace, etc., now.) Instead, virtual hardware management/cloud architecture is now in our domain. Not only do we think about our application in terms of best coding practices and organization, we have to think about how to leverage the vast resources available to us as developers. This means we have to become familiar with the features of AWS and understand how to design, configure, and maintain a virtual-hosting environment.

As you learn how to be a cloud architect, you will learn about a lot of great features specific to AWS, as well as the general philosophies of elasticity and scalability. The many features of AWS are organized into a series of overlapping services. Many of them have redundant features, allowing for some creativity in the decisions we make as we architect our system. All of these services run in virtualized-hardware environments located in Amazons many data centers around the globe. We will explore some of these services in the chapters that follow.

You will be familiarizing yourself with the fundamentals of Amazon Web Services. I have discussed some of the general principles and advantages of using AWS. Later on, I will discuss some of the core services in greater detail and the different ways we can interact with them. Before we dive in, it is important to start on the same page.

This book assumes that you are already at least a beginner Node.js developer, looking to expand your skill set to include architecting and developing a Node.js application with scalability and elasticity in mind. You should have a basic understanding of the main concepts in web-application development. You should know what a RESTful web service is, know your way around Git or SVN, and have a code editor handy.

Designing and developing the application is a creative process. This means that a number of highly subjective decisions have to be made. First and foremost, we will be using Amazon RDS (Relational Database Service) to host a MySQL database on AWS. Many Node.js developers prefer MongoDB to MySQL. That is perfectly fine! However, the sample application and subsequent instructions focus on MySQL, which suits the needs of our application. If you want to use this book to deploy an app using MongoDB, you will have to be capable of rewriting the database connections and queries accordingly. In either case, you will need elementary knowledge of the database language in question. This is just one of many creative decisions to be made along the way. You may disagree with some or require a different approach in your next project, but you will end up being better equipped to make these decisions in your next project, and you will be prepared to work with AWS services as a developer and architect.

To gain the benefits of cloud computing in our application, you will be learning about a variety of AWS services that can be integrated into our application. This integration will be carried out through two means: via configuration and customization of multiple services in the AWS Console and programmatically in our application code base with the AWS SDK. In this case, we will be using the JavaScript AWS SDK, which is intended for use in Node.js applications. However, there are SDKs for a variety of server-side languages, and many of the lessons of the book could even be useful to developers using different languages. Integrating AWS services into a PHP application with similar functionality would not be that different.

Virtually every task you can carry out in the AWS Management Console (AWS Console) could also be carried out programmatically, and vice versa. The AWS Console adds a lot of clarity to the process by providing access to hints and documentation and by providing visual reference for the otherwise abstract concepts. It can help a lot to use the console while you wrap your head around everything AWS can do. You might ask, How do I know when to use the console and when to use the SDK? Learning curve aside, this is a highly subjective topic. You may, in time, decide what rules are best for your workflow, but we can follow a few ground rules.