AWS For Admins For Dummies. Mueller John Paul
Читать онлайн книгу.organization of your dreams. This chapter gives you a basic overview of what certification can do for you and helps you determine whether you really need certification to meet your needs today. Of course, those needs will change over time, so knowing what certification has to offer is helpful, even if you don’t intend to get certified today.
Finally, you need to round out your AWS education to use AWS effectively. The last part of the chapter offers some ideas of the types of educational resources you might use. Of course, this book is your starting point, but to meet specific needs, you may need to do more.
Amazon Web Services (AWS) is actually a huge array of services that can affect consumers, Small to Medium-Sized Business (SMB), and enterprises. Using AWS, you can do everything from backing up your personal hard drive 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 actually simple in conception. Think of a pair of tin cans with a string attached between them. 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.
Understanding service-driven application architectures
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 used in the early days of computing, in that a client makes a request that a server fulfills by performing an action or sending a response. However, the implementation details have changed significantly over the years, 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). (You can discover how SOAP works at http://www.w3schools.com/xml/xml_soap.asp and how REST works at http://www.tutorialspoint.com/restful/ – a passing knowledge of both is helpful in working with AWS.)
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).
AWS provides a service-driven application architecture in which you choose a specific service, such as S3, to perform specific tasks, such as to back up files on a hard drive. In many cases, you must perform setup steps in addition to simply interacting with the service. For example, if you look at the ten-minute tutorial at http://aws.amazon.com/getting-started/tutorials/backup-files-to-amazon-s3/, you find that you must first create a bucket to store the files you want to upload to Amazon. This additional step makes sense because you have to establish a location from which to retrieve the files later, and you don’t want your files mixed in with files from other people.
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 for you and then waits for a response. In some cases, the app must determine the success or failure of an action on the server. You need to realize, however, that these actions take place in code and that the code uses a sequence of steps to accomplish the task you’ve asked it to perform.
Understanding process- and function-driven workflows
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 automation prototypes at Xerox Parc and the University of Pennsylvania’s Wharton School of Business.)
Workflows can consist of additional workflows. In addition, workflows manage the interaction between users and underlying services. A process is the aggregation of services managed by workflows into a cohesive whole. The workflows may perform generic tasks, but processes tend to be specific and help users accomplish particular goals. A process-driven workflow is proactive and attempts to circumvent potential problems by
❯❯ Spotting failure patterns and acting on them
❯❯ Looking for trends that tend to lead to failures
❯❯ Locating and extinguishing potential threats
In looking through the tutorials at http://aws.amazon.com/getting-started/tutorials/, you find that they all involve using some type of user interface. The user interface provides the workflow used to manage the underlying services. Each major tutorial step is a workflow that performs a specific task, such as creating a bucket. When you combine these individual workflows into an aggregate whole, the process can help a user perform tasks such as moving files between the cloud and the user’s system. Creating a cloud file system is an example of a process-driven workflow: The workflow exists to make the process viable. Workflows can become quite complex in large-scale operations, but viewing them helps you understand AWS better. You can find a more detailed discussion of workflows and processes at https://msdn.microsoft.com/library/bb833024.aspx.
A function is the reactive use of services managed by workflows to address specific problems in real time. Even though it would be nice if process-driven workflows worked all the time, the reality is that even with 99.999 percent reliability, the process will fail at some point, and a function-driven workflow must be in place to address that failure. Although process-driven workflows focus on flexible completion of tasks, function-driven workflows focus on procedurally attenuating the effect of a failure. In short, function-driven workflows address needs. The AWS services and workflows also deal with this issue through the user interface, such as by manually restoring a backup to mitigate a system failure.
Even though this book frequently refers to virtual environments and services that you can’t physically see, these elements all exist as part of a real computer environment that Amazon hosts on your behalf. You need to understand how these elements work to some extent because they have a physical presence and impact