Introduction to hope these blog posts can help you to discuss the best business plan among all relevant people. The course may or may not involve serverless. In this first article, we will consider some of the most common issues when discussing serverless. In the second article, we will examine some broader issues.
Original | https://www.pulumi.com/blog/is\_serverless\_the\_future\_part\_1/
Author | Lee Briggs & Piers Karsenbarg
Translator | donghui
Many developers say that serverless is the future of computing, while other developers say that it will never succeed. Our own views are not so polarized. We see serverless as an option, which is a possible stepping stone from start-ups to medium-sized enterprises to large enterprises. In these two blog posts, we will discuss how serverless adapts to this process, as well as its advantages and disadvantages.
Our goal is to help you realistically evaluate serverless computing. We want to stimulate discussion, not a subconscious reaction, whether for or against. Hope these blog posts can help you to discuss the best business plan among all relevant people. The course may or may not involve serverless. In this first article, we will consider some of the most common issues when discussing serverless. In the second article, we will examine some broader issues.
What is serverless?
The term "serverless" is a bit of a misnomer. More cynics might mutter, "No server is still running on the server!" This is true. No matter what cloud provider you use, you always use a server to run your application. These servers must be configured, managed, and maintained. Serverless services provided by cloud providers often abstract out the components of running applications that are difficult to manage: they run and manage the server for you. Developers can run their applications without worrying about the underlying, such as the operating system or even computing power.
Why use serverless?
When people promote serverless, they will give some ready-made answers. We will mention them here quickly, and then we will study these claims more closely. The following are three reasons people give.
1. This is a quick way to start
Handing over the management of the server to the provider means that you can provide the application to the user very quickly. There are many underlying infrastructures for which you don’t have to write or maintain code.
2. It's very cheap
Serverless can save you money in several ways. First, because the provider manages the server, management costs can be reduced. You also don't need to write so much code, because the server is not your concern. You can bring your application to market faster, which means you can start generating revenue faster. Finally, depending on your usage pattern, you only pay for the time it takes to execute the code. You don't have to pay for free time.
3. It is outside of IT control
In organizations that adopt cloud engineering, people often turn to serverless because they feel that IT is too slow or unresponsive. In a "traditional" organization, it may be difficult to purchase hardware, the purchase time may be too slow, or it may shrink due to operations or finances. This is usually a reason people turn to cloud providers, and as part of their migration, they might consider using serverless.
If you encounter obstacles such as strict permissions in the process of providing cloud resources, you will also see the adoption of serverless among companies that have already adopted cloud computing. Serverless is a simple way to get things done by bypassing what is considered a "blocking tiger". Sometimes the push for serverless may come from departments other than the development department. For example, the marketing department may want to publish some time-critical content because it is related to an event.
or?
Let's take a closer look at the reasons why people advocate serverless.
1. Is this really a quick way to start?
Using serverless may make your application easier to market, but this requires rethinking how to build and develop the application, which will lead to labor penalties in the future. When you start to take advantage of serverless products, the traditional practices your organization has adopted when building production applications may need to be reconsidered or even readjusted. A good example of this is when considering monitoring and observability: many monitoring platforms work on a layer that you cannot access, and you cannot gain insight into the performance of the application. Redesigning and rethinking how to use serverless technology to build production-ready applications may bring unexpected delays to the serverless journey.
2. Is it really cheap?
One of the reasons serverless is considered cost-effective is that you only pay for the computing time you use. However, it is not inevitable that using serverless can save money. It is very important to analyze whether your application is suitable. There are two considerations here.
What is the mode of the request?
If your application has many small fast requests, then serverless may be a good choice. On the other hand, if your application relies on long-running operations, you might be shocked when you look at your bill.
What about the startup time?
Remember, you still have to "pay" for the startup time of the application. Serverless services are usually penalized by a "cold start", so if you rarely use or don't use it at all, you may have to run other processes in the background to ensure that your application does not pay for it. This also means that your first request will take longer than subsequent requests. If serverless functions need to be responsive all the time, you can pay extra for implementations such as preset concurrency to improve cold start losses. However, compared to traditional software deployment methods, this can easily offset any costs you might save.
3. What about control?
Using a serverless platform as the deployment mechanism means that the responsibility for patching the infrastructure is transferred to the provider. You can no longer react quickly to security warnings at the operating system level; you trust your vendor to do this. In this case, you may not want to give up control.
You still need to manage security notifications in application dependencies, and you need a mechanism to react to these issues. Due to the lack of infrastructure to manage, serverless collectors often have the wrong impression that their applications are "secure", but this rarely happens. You may need to adjust any existing mechanisms used for penetration testing of your application and adapt it to any new serverless platform. Although your attack surface may be small, you still need to ensure that it is difficult for any potential attacker to attack horizontally through a serverless infrastructure.
If you choose serverless because you or other departments want to bypass standard IT processes, then this will point to problems within the organization rather than the need for serverless. Technology cannot solve cultural problems. What really solves these problems is that people communicate with each other and figure out how to make everyone involved live a better life.
You must understand that you are handing over control of the server to the provider, not your own control, and you need to study the trade-offs between compliance and serverless advantages in detail.
This article is reprinted from the Serverless Life official account, please contact the original author for reprinting.Copyright Notice: content of this article is contributed spontaneously by Alibaba Cloud real-name registered users. The copyright belongs to the original author. The Alibaba Cloud Developer Community does not own its copyright and does not assume corresponding legal responsibilities. For specific rules, please refer to the "Alibaba Cloud Developer Community User Service Agreement" and the "Alibaba Cloud Developer Community Intellectual Property Protection Guidelines". If you find suspected plagiarism in this community, fill in the infringement complaint form to report it. Once verified, the community will immediately delete the suspected infringing content.
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。