The original | www.pulumi.com/blog/is_ser… The author | Lee Briggs & Piers Karsenbarg translator | donghui
In our second article on serverless, we’ll discuss some broader issues. Again, we’re not trying to make a hard and fast rule. We would like to present some ideas to facilitate discussion among all stakeholders. Many people who say all applications will be serverless haven’t run their applications on a large scale and haven’t solved all the problems associated with latency, complexity, and vendor lock-in. That’s what we’re talking about here.
What about vendor lock-in?
How concerned are you about vendor lock-in? For example: You probably won’t be able to move a serverless architecture from AWS to another cloud provider. Some organizations don’t care about vendor locking, but many do. If you really care, decide how much you should care before you move on.
How big is your organization?
Serverless is a good option for younger or smaller organizations, and perhaps a novice team in a larger organization is directly focused on delivering value. Once the organization has grown large enough to support teams dedicated to managing the infrastructure, and usage has grown, it may be time to reevaluate the situation. Large organizations that successfully adopt serverless platforms often undergo a cultural shift to succeed. If you are not prepared to make significant investments at all levels of your organization to make serverless adoption a success, a more traditional approach, with dedicated teams controlling the provisioning infrastructure, may be more appropriate. Finally, as discussed in the previous article, large enterprises may want to consider building an infrastructure platform where technologies like Kubernetes can benefit.
What does architecture look like?
One thing to consider is the significant difference in thinking between serverless products and more “traditional” approaches, which means that applications may often need to be redesigned when switching platforms. You may want to consider what the ROI of these architectural changes are. Often, any application redesign is expensive from a time and financial perspective and can cause problems for even the most successful engineering teams.
Whether you are developing a newly developed application or evaluating an existing one, it is important to consider the architecture of a serverless application. Traditional N-tier style architectures or N-tier style Web applications require a significant investment to migrate to a serverless platform.
conclusion
All in all, serverless won’t solve everything, but a lot can be done in the right place. Keep the following questions in mind:
1. How much do you care about vendor lock-in?
A serverless architecture cannot simply be migrated from one cloud provider to another. How concerned is vendor lock-in in your organization?
2. What is the size of your organization?
Serverless is usually better for small organizations. Once you have an IT staff to back IT up, you might want to look at more traditional options. Large enterprises may want to study Kubernetes.
3. Do you care more about delivering value quickly than providing application transparency?
If you want to get your application to market as quickly as possible, serverless might be a good choice. However, you will sacrifice the metrics and insight of your application. This can cause real problems as it grows in size.
4. Do you understand the properties of the application?
It is often said that serverless saves money because you only pay for time. However, if your application has long response or startup times, take a closer look. Serverless can be an expensive option.
5. What is the architecture of your application?
Do not expect a traditional end-to-end style architecture to work well with serverless applications. Look for applications that can be broken down into smaller components that work together. On the other hand, migrating a serverless application to a server you control also requires rebuilding the application. Do you have time to do that with someone?
6. Is serverless a way to bypass IT?
Using serverless as a way to bypass the IT department may not be the best idea. It is too easy to write code that is not compliant and vulnerable to attack. Instead, use the DevOps approach and meet with all stakeholders to come up with solutions.
7. How safe is it?
None The security of the server architecture is compromised. Cloud providers offer some off-the-shelf options, such as Amazon GuardDuty, but they can have many limitations that limit the flexibility offered by no server. Implementing secure serverless applications requires a lot of thought.
This article is reprinted from Serverless Life public account, please contact the original author for reprinting.