Shulou(Shulou.com)05/31 Report--

This article introduces the relevant knowledge of "how to go to Serverless through AWS's Lambda and API Gateway". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

A brief memory of the development in the field of computing

In the early days, there was. Okay, it's a little complicated. In the early days, mechanical computers appeared, and then there was Eniac ENIAC (Electronic Numerical Integrator And Computer), but there was no large-scale production. It was not until the emergence of the mainframe that the field of computing developed rapidly.

1950s-mainframe

In the 1960s-microcomputers

1994-Rack Server

2001-Blade Server

Early in this century-virtual server

2006-Server clouding

2013-containerization

2014-serverless (Service of Computing Resources)

These dates are approximate release or fashion dates, so there is no need to argue with me about the accuracy of the time. The evolution trend in the field of computing is that the functional units executed are getting smaller and smaller. Each evolution usually means the reduction of the burden of operation and maintenance and the increase of flexibility of operation and maintenance.

Prospect of development

Oh, Serverless! But what benefits can serverless bring to us? What challenges will we face?

There is no charge when the code is not executed. I think this is a huge selling point. You don't have to pay when no one visits your site or uses your API. There is no ongoing infrastructure cost, just pay for what you need. In other words, this fulfills the promise of cloud computing: "only pay for the resources you actually use."

There is no need to maintain the server, nor do you need to think about server security. Server maintenance and security will be handled by your service provider (of course, you can also set up your own serverless host, but this seems to be moving in the wrong direction). Since your execution time is also limited, the security patch is also simplified because there is no need to restart at all. All of this should be handled seamlessly by your service provider.

Scalability of *. This is another big benefit. Suppose you have developed another Pokemon Go, and instead of frequently upgrading the offline maintenance of the site, use serverless to continue to expand. Of course, this is also a double-edged sword, and a lot of bills will follow. If the profit of your business depends heavily on site availability, serverless can really help.

Mandatory micro-service architecture. There are two sides to this. On the one hand, microservices seem to be a good way to build a flexible, scalable, fault-tolerant architecture. On the other hand, if your business is not designed in this way, it will be difficult for you to introduce serverless into your existing architecture.

But now you're limited to their platform.

A restricted environment. You can only use the environment provided by your service provider. Do you want to use serverless in Rust? You may not be too lucky.

Restricted pre-packaged packages. You only have a pre-loaded bag from the provider. But you may be able to provide your own bag.

Limited execution time. Your Function can only run for so long. If you have to deal with 1TB files, you may need to have a solution or use another solution.

Mandatory micro-service architecture. Refer to the description above.

Limited monitoring and diagnostic capabilities. For example, what is your code doing? In serverless, it is almost impossible to set breakpoints and trace processes in the debugger. You can still log and send out statistical metrics as usual, but this is of limited help to locate the difficult problems that occur in the serverless environment.

Competitive field

Since the advent of AWS Lambda in 2014, the number of serverless providers has increased a bit. Here are some of the mainstream service providers:

AWS Lambda-the first to start

OpenWhisk-available on IBM's Bluemix cloud

Google Cloud Functions

Azure Functions

These platforms all have their comparative advantages and disadvantages (for example, Azure supports centering, or is tightly integrated on the platforms of other providers). The player in this game is AWS.

Build your * * API through AWS's Lambda and API Gateway

Let's try serverless. We will use AWS Lambda and API Gateway to build an API that returns what Jimmy calls "Guru Meditations."

All the code can be found on GitHub.

API documentation:

POST / {"status": "success", "meditation": "did u mention banana cognac shower"}

How to organize engineering documents

File structure tree:

. ├── LICENSE ├── README.md ├── server │ ├── _ _ init__.py │ ├── meditate.py │ └── swagger.json ├── setup.py ├── tests │ └── test_server │ └── test_meditate.py └── tools ├── deploy.py ├── serve.py ├── serve.sh setup.sh zip.sh

Information in AWS

API . The object actually built. It is represented as a separate object in AWS.

Perform the role. In AWS, each Function executes as a separate role. This is meditations.

Role strategy. Each Function is executed as a role, and each role requires permissions to work. Our Lambda Function doesn't do much work, so we only add some logging permissions.

Lambda Function . Where our code runs.

Swagger . Swagger is the specification of API. API Gateway supports parsing the definition of swagger to configure most of the resources for API.

Deploy. API Gateway provides the concept of deployment. We only need to use one for our API (for example, all use production or yolo, etc.), but know that they exist, and for real production-level services, you may want to use a development and staging environment.

Surveillance. In the event of a collapse of our business (or when a large number of bills are generated because of usage), we want to add some monitoring for these errors and expenses in the form of cloud alarm view. Note that you should modify tools/deploy.py to set your email correctly.

Code

Lambda Function will randomly select one from a hard-coded list and return guru meditations, which is very simple:

Import logging import random logger = logging.getLogger () logger.setLevel (logging.INFO) def handler (event, context): logger.info (u "received request with id'{}'" .format (context.aws_request_id)) meditations = ["off to a regex/", "the count of machines abides", "you wouldn't fax a bat", "HAZARDOUS CHEMICALS + RKELLY", "your solution requires a blood eagle" "testing is broken because I'm lazy", "did u mention banana cognac shower"] meditation = random.choice (meditations) return {"status": "success", "meditation": meditation,}

Deploy.py script

The script is so long that I can't post it here. It basically just traverses the items under "Information in AWS" above to make sure that each item exists.

Let's deploy this script.

Just run. / tools/deploy.py.

It's almost done. However, there seems to be some problems in the permission application, because API Gateway does not have the authority to execute your Function, so your Lambda Function will not be executed, the error should be "Execution failed due to configuration error: Invalid permissions on Lambda function". I don't know how to use botocore to add permissions. You can solve this problem through AWS console, find your API, go to the / POST endpoint, go to "integration request", click the edit icon next to "Lambda Function", modify it, and save it. A pop-up window will prompt "You are about to give API Gateway permission to invoke your Lambda function" and click "OK".

When you are finished, record the URL printed out by. / tools/deploy.py, call it like this, and then check the behavior of your new API:

$curl-X POST https://a1b2c3d4.execute-api.us-east-1.amazonaws.com/prod/ {"status": "success", "meditation": "the count of machines abides"}

Local operation

Unfortunately, AWS Lambda doesn't have a good way to run your code locally. In this example, we will use a simple flask server to host the appropriate endpoint locally and call the handler function.

From _ _ future__ import absolute_import from flask import Flask, jsonify from server.meditate import handler app = Flask (_ _ name__) @ app.route ("/", methods= ["POST"]) def index (): class FakeContext (object): aws_request_id = "XXX" return jsonify (* * handler (None, FakeContext ()) app.run (host= "0.0.0.0")

You can run it with. / tools/serve.sh in the warehouse and call it like this:

$curl-X POST http://localhost:5000/ {"meditation": "your solution requires a blood eagle", "status": "success"}

test

You should always test your code. Our test method is to import and run our handler function. This is the most basic python testing method:

From _ future__ import absolute_import import unittest from server.meditate import handler class SubmitTestCase (unittest.TestCase): def test_submit (self): class FakeContext (object): aws_request_id = "XXX" response = handler (None, FakeContext ()) self.assertEquals (response ["status"], "success") self.assertTrue ("meditation" in response)

You can run this test code through nose2 in the warehouse.

This is the end of the introduction of "how to get to Serverless through AWS's Lambda and API Gateway". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.