You may also find yourself drowning in a sea of new abbreviations and acronyms. Of course, you can act like you know what all these terms mean, but they’re actually important terms, and knowing what they mean gives you an edge over everyone else. This chapter also helps you understand terms like Infrastructure as a Service (IaaS) and discover just what this new term means to you as a developer. If you already work on the Internet, you could possibly skip this part of the chapter, but if you’ve spent your career working with desktop applications or a local intranet, you definitely want to find out more.
Developers often find that the most frustrating part of creating an application is having the right tool. Development is more than knowing the right procedures and the right function calls – it’s a matter of knowing the most efficient manner in which to use them and determining when the tools already in use won’t do the job. This chapter closes with some essential information about the platforms that AWS supports. Reading this material will help you avoid some serious trouble later because you can avoid the most serious platform issues at the outset.
Defining the AWS Cloud
As a developer, you need to meet end-user demands with the least amount of effort and in the quickest time. Amazon Web Services (AWS) is a huge array of services that affects consumers, small to medium-sized businesses (SMB), and enterprises. Using AWS, you can do everything from creating applications for remote access to organization data to creating a full-fledged IT department in the cloud. The installed base is immense. You can find case studies of companies like Adobe and Netflix that use AWS at https://aws.amazon.com/solutions/case-studies/. (The page also includes a link to create an account, a topic discussed in Chapter 2.) AWS use isn’t just for private companies, either – even the government makes use of its services.
The technologies that make all these services possible are simple in conception. Think of a pair of tin cans attached to each other by a string. Amazon holds one tin can and you hold the other. By talking into one tin can, you can hear what is said at the other end. The implementation, however, relies on details that make communication harder than you might initially think. The following sections give you an overview on how the AWS cloud works.
Service-driven application architectures, sometimes known as Service-Oriented Architectures (SOA), come in many forms. No matter how you view them, service-driven application architectures are extensions of the client-server technologies that you may still use when creating localized applications, in that a client makes a request that a server fulfills by performing an action or sending a response.
The request/response implementation details have changed significantly over the years, however, making modern applications far more reliable, flexible, and less reliant on a specific network configuration. The request and response process can involve multiple levels of granularity, with the term microservice applied to the smallest request and response pairs. Developers often refer to an application that relies on a service-driven application architecture as a composite application because it exists as multiple pieces glued together to form a whole. Service-driven application architectures follow many specific patterns, but in general, they use the following sequence to perform communication tasks:
1. Create a request on the client using whatever message technology the server requires.
2. Package the request, adding security or other information as needed.
3. Send the request using a protocol, such as Simple Object Access Protocol (SOAP), or an architecture, such as REpresentational State Transfer (REST).
4. Process the request on the server.
5. Perform an action or return data as required by the request.
6. When working with data, process the response on the client and present the results to the user (or other recipient).
Even though many of the processes you perform with AWS require using an app (so that you have a user interface rather than code to work with), the underlying process is the same. The code provided in the app makes requests and then waits for a response. In some cases, the app must determine the success or failure of an action on the server. Rather than reinvent the wheel, a smart developer will use as many of these apps as possible to perform general configuration tasks. Using the AWS apps places the burden of updating the code on Amazon so that you can focus on custom tasks related to your organization.
INTERACTIVITY IN THE DEVELOPMENT ENVIRONMENT
Local applications require a certain level of interactivity between groups. A database administrator (DBA) may perform database setups before you can write code to interact with the data in that database. However, after the required individuals perform basic local setups, you may not interact with them as much as you do while creating your application code. Usually there is a flurry of activity during testing and again during deployment, but developers are often left alone to do their work otherwise because administrators in other areas give them the control needed to perform tasks.
Things work differently in the cloud. For example, you might find yourself performing some tasks normally associated with other disciplines, such as service configuration. This book helps you through the configuration tasks that developers normally do as part of working with AWS. In addition, you find tips about when you need to work with others to finish tasks. The level of interactivity between disciplines is much higher in the cloud because you have less control over the environment (you’re using someone else’s hardware and underlying software, after all). In addition, the cloud environment can become more complex than the test server setup that you may normally rely on for localized development.
In creating apps to help manage underlying services, AWS also defines workflows. A workflow is an organized method of accomplishing tasks. For example, when you want to save a file to AWS using S3, you must first create a bucket to hold the file. Only after you create a bucket can you save a file to AWS. In addition, you can’t retrieve a file from the bucket until you first save a file there, which makes sense because you can’t grab a file out of thin air. In short, a workflow defines a procedure for working with software, and the concept has been around for a long time. (The first workflows appeared in the mid-1970s with simple office