The original | translations in English

Once you find the right tools, the world of Serverless is really cool and even the middle tier is completely eliminated.

After the wonderful Amway of ServerlessConf in October, I decided to move the entire company structure to Serverless. It took me a couple of months to switch my mind and figure out how to turn a Python Flask-based application into a Lambda, and those attempts helped me find some good ways to do it.

Six months later, we deployed our fourth large project based on Serverless. Here are some lessons we learned along the way.

Lesson one – Give up Python

Flask is a good lightweight framework for traditional request-response architectures. Sessions are managed by the server. But in the era of responsive development, it’s pretty primitive, like building a house with rubber bands and scrapers.

Traditional: Python Flask programs run in EB and data is stored on RDS

As you start moving more work to the client side to support interaction, you will definitely use JavaScript. This work is previously embedded in Python templates, leading to the accumulation of more technical baggage.

Flask-based solutions tend to end up mixing languages. I quickly came to the conclusion that this was a bad way to go. I began to wonder why I was still using Python.

After switching to Node, everything becomes more maintainable and logical, and you don’t need to use multiple languages at once. With the Node/Express configuration on Webpack, you can also use ES6 to avoid some JavaScript constructs that Python developers hate.

Doing the same thing on Zappa/Flask is more trouble than filing taxes. But in just five minutes, you can learn a full-fledged Lambda-based Node/Express application like filling out a 1040EZ form. It’s no big deal. So, we abandoned Python and joined the cool guy’s JavaScript camp.

Lambda functions are applied as singletons

So what are we giving up? Pythonists will talk about a bunch of cool language features, but they’re mere toys compared to the true asynchronous appeal of JavaScript. Now we don’t have to worry about Python 2/3. . At least for our project, switching was easy.

Of course, Ben Kehoe provides a compelling alternative trap with his views and insights into serverless use of Python and Node.

Lesson two – Abandon the middle tier

Maybe it’s because we’ve been developing Web applications, or maybe I’m too old, but it took us a long time to realize one obvious benefit of being serverless.

Our first Web applications also included a Node Express layer for recording session state. (1) Expect users to hit the same Lambda container repeatedly. (2) Because of a design error, we used DynamoDB to store session ids. This practice is very bad.

In the first phase of the “transition,” our middle tier is like a Web server running on a Lambda, and it’s way off base. After that, we end up with an HTML page filled with JavaScript calling the REST API. This approach is crude and makes projects difficult to maintain very quickly. In Serverless, the middle tier must be eliminated.

The state moves to the client and the logic moves to the Lambda

Lesson three – Hug Vue

It’s really nice to have everything on the front end, but it can get messy very quickly. In the end, you’re too embarrassed to have your code reviewed, because you’re writing a bunch of code that doesn’t really work. It is not a good practice for programmers not to let others check your code.

I learned about React when I was introduced to single-page applications (SPA). It is currently the most popular front-end framework. React was great, but the learning curve was steep, required a lot of setup on Webpack/Babel, and introduced JSX. Although it might eventually be used, it was too complex for our current needs, so we looked for alternatives.

Fortunately, I quickly discovered vue.js, and my Serverless development immediately became very easy. In short: You can learn Vue in a day.

Vue’s design approach is very much in line with our design model, where everything is a component that manages its own content, design, and code. This made it very easy to manage multiple client projects and decentralized teams, and we performed very well in Serverless.

The open source JavaScript framework gives you powerful debugging tools, great organization capabilities, and Webpack builds out of the box, which can save you a lot of time. Just install routing and Store management plugins, and you’ll be as good as the engineers at Facebook. Who knew single-page applications could be so simple?

From a Serverless perspective, Vue compiles all of your code into index.html and bundle.js files that can easily be uploaded to S3. NPM run is the new build command.

If you think about it, we used to have to deploy applications through Elastic Beanstalk, monitor utilization, automate scaling when necessary, and manage the infrastructure.

The real beauty of SPA is that when you deploy your application, you simply copy index.html, budle.js, and a few file dependencies to S3 and speed them up via CloudFront. This gives you stable distribution and load speeds, and allows for multiple versioning and any deployment you like, since it only needs to manage text files.

In this way, we have virtually unlimited capacity to scale and pay for it on demand. There is no charge for application infrastructure administration.

Vue actually allows you to build desktop applications in the browser, which means you can greatly improve the user experience. All user states can be managed on the client side without the need to repeatedly send requests. You can hide the demo using a series of standard UI tricks like transitions, and the whole thing works pretty well.

Lesson 4 – Learn to love DynamoDB

In some ways, the hardest part of moving to Serverless is DynamoDB. In the first few iterations, you’re bound to make some mistakes, and you’ll be tempted to drop them and go back to the familiar and comfortable RDS.

SQL was my crutch for a long time, and I have to admit that I put a lot of business logic in the database. But RDMS systems are just another monolithic application that does not scale well, and they do not support the agile system idea of dynamic scaling.

DynamoDB is an entirely different creature. When done correctly, NoSQL can provide excellent performance, scale on a large scale, and have almost no administrative overhead. But you have to take the time to figure out how it works, and there are a lot of pitfalls in the initial stages.

Dynamo table fields cannot contain blank strings. The timing of the backup is not automatic. If you get the partitioning and sorting wrong, you have to create the table from scratch. If you try too hard to simulate SQL queries, you will experience an explosion of forms. These are far from what RDS wants to do.

After watching a lot of tutorials, trying, failing, and ultimately succeeding, I know…

  • You need to understand how DynamoDB works and spend some time understanding the indexing strategy and how to query data. It’s very easy to jump into these pits without knowing it, and many people have been screwed, and then go back to the RDMS at the wrong time. When you make mistakes, you should overcome them.
  • It’s easy to overlook the fact that DynamoDB allows you to stream code to table events, just like SQL triggers can do anything. These capabilities are so powerful that we use a very simple pattern of pushing table changes to the SNS topic queue. This way changes can be absorbed by other Serverless code, even if you haven’t written it yet.
  • Don’t forget that DynamoDB can stream to other storage systems (RDMS, Readshift, or plain text files) and can be a great way to mitigate traffic spikes or protect other databases from massive data. DynamoDB has a TTL feature, which is useful for temporarily storing data to be pushed to another location.

Lesson 5 – Serverless Frame Awesome!

My early experience with Lambda was tedious, and the amount of work and error messages that came with writing code directly in the AWS console were frustrating. Missing a bridge between the IDE and the production environment.

Fortunately, I eventually found the Serverless framework. This is the most exciting thing I’ve found in years.

A simple SLS deploy command has tremendous power, packaging your code together and sending it to Amazon. Also, if you need to check logs caused by code errors, just type SLS logs -f functionname -t and you can check CloudWatch logs like Pro without even opening a browser.

This change, earth-shaking! People who use Serverless should praise each cloud service provider for what they should have provided from the beginning. Excellent as hell.

Lesson 6 – New ways of licensing

In traditional applications, you need to authenticate the user once, and then track the user by tracking the session ID. What makes you like it is that you only bother once, and then you can use the ID recklessly for the entire life cycle, no matter how long you want to log in.

In the past, session ids controlled access

The problem with this approach is that it only works if you have a server in the middle tier. And we just canceled the server. It also leaves you open to nasty attacks, such as cross-site request forgery (CSRF), and doesn’t allow you to easily pass authentication to other services. As a result, this approach basically only supports monomer applications (explosion!). .

We hate singleton applications and cross-site request forgery attacks. But we have a new method. -JWT. JWT is really exciting. When I learned how it worked, I felt a kind of Zen delight, but I needed a graph to represent it.

Step one, get a JWT; Step two, use it to communicate with any service you write.

The first step looks familiar: the authorization program obtains a JWT token

The second step is magic: any lambda function can accept and validate the token

Simply put, each request is authenticated, the client can communicate with multiple serverless, has anti-singleton functionality, and cross-site request forgery attacks don’t even exist under JWT. All your Serverless code needs is to use custom authorization to check that the JWT is valid (using template code) and you’re done.

JWT makes all other authentication methods seem too complicated. We switched all projects to Auth0 (Cognito in some places) and never moved back. Serverless authentication is crazy and simple. So, join us.

It’s a Brave New World

I’ve been working on AWS for a long time, but I’ve never felt my way through development like this. Even in EC2, there was a lot of help documentation because I joined so late. After leaving A Cloud Guru’s Serverless meeting, it felt like untapped territory, and there were more discoveries to be made in the dark.

In the first few experiments, we tried to use existing tools and techniques and failed a bit, with unsatisfactory results. After a few months of deployment, we have officially begun delivering the project 100% Serverless. Let’s see, our migration difficulties and early exploration were well worth it.

We are building sophisticated real-time SPA applications that use the Serverless architecture, can be easily scaled and cost 70% to 90% less. I was both delighted and shocked by the return. I have never been more convinced that Serverless technology will revolutionize cloud-based application delivery.

The results were transformative.