This article introduces the advantages of a serverless architecture over traditional architecture, but also points out that the serverless architecture is not suitable for all applications, but it is beneficial for developers and enterprises to understand the architecture pattern.

【 3 days to burn brain type based on the actual combat training camp | CI/CD Docker Beijing station 】 this training around CI/CD of actual combat, based on the Docker concrete content includes: continuous integration and the continuous delivery (CI/CD) overview; Continuous integration system introduction; CI/CD practices on client and server side; Introducing CI and CD into the development process; Gitlab and CI and CD tools; Gitlab CI, Drone use and practical experience sharing.

The serverless architecture won’t work for all apps, but this article will help you understand what to expect if you use it.

Most of the talk about a serverless architecture today focuses on its integration with function-as-Service, how to orchestrate access requests, and troubleshooting tools based on a serverless architecture. However, not much attention has been paid to the underlying reasons behind choosing a serverless architecture over a traditional one. Why?

Reduce development costs

The primary reason for using a Serverless architecture, as its name suggests, is to remove servers from our focus. We have to admit that there is no such thing as a serverless application (serverless is just another word for a server hosted in the cloud), opting for a serverless implementation with the benefit of not having to develop server-side code.

In traditional client-server applications, all of the data-based apis and endpoints need to be implemented by the developer. This can be done by writing your own code using a framework like Rails, or by leveraging third-party tools that turn the underlying calls into callable REST apis.

With a serverless architecture, you can hand over much of the back-end technical work to third parties without having to worry about the complexities of bringing your Web application to market. This significantly reduces development costs. Your developers can focus on the user interface and user experience, and your application’s most distinctive features will be more appealing.

Reduce DevOps and maintenance costs

There are many direct costs involved in developing and hosting Web applications. This includes developer salaries, hosting fees, domain name registration fees, data transfer fees and so on. In addition, with Web applications, you typically need to keep the server running continuously to handle access requests at any time of day. This means that for low-access applications that can only run one hour of computing time per day, you still have to pay for the other twenty-three hours that your application is available but not yet used.

With a function-as-a-service utility like AWS Lambda, you can further reduce costs by ensuring that payments are made only when the application is active. Function-as-a-service runs on a pay-per-execution basis, so you only need to pay for hosting and computing resources when the code is actually invoked. Many Web applications are typically idle and can result in significant cost savings.

While you can get similar benefits by hosting containers on Heroku with products like Docker, you won’t get the pure level allowed by a feature-as-a-service serverless provider that provides only one instance and actually calls a single function. This intermittent installation and unloading of containers reduces hosting and resource usage costs by ensuring that your code is only active when it is actually needed.

Reduce time to market

In addition to reducing code volume and operating costs, you can also reduce delivery times. By sacrificing flexibility on the hardware and server side, you can reduce the time it takes to develop your application by moving complexity to the client side, focusing your efforts on a single language in your code base.

In addition, you don’t need to find a provider to run the server, configure the Web server software, and get your application running on the machine, which ends up being a simpler problem. You also get more host options, because a serverless application only needs a CDN that can serve files to its end users, rather than a specific Web server running the runtime in a programming language that handles requests from network users.

Finally, by handing over the server side of your application to a serverless provider, you can improve security by allowing a third party to manage the security of your application. In this way, you can reduce the effort required to secure web servers, database servers, and any other back-end security issues that are critical in traditional client-server applications.

conclusion

While many applications cannot run in a serverless environment due to specific requirements or some other reason, applications that support a serverless architecture have many advantages over traditional client/server applications. By using a serverless provider, you can reduce the amount of code required and let third parties build apis based on your data sources.

You can also reduce operating costs by allowing your code to run in a more intermittent fashion, starting (and terminating) instances only when needed.

Based on these two benefits, as well as other untapped advantages, you can see product time-to-market shorten as you focus on the look and feel, and the basic interaction behavior of your application. While a serverless architecture may not be right for you, it is a viable and sensible choice for a growing number of companies.

Original link:Why Go Serverless?(Translated by Fu Hui)