Adopting a serverless architecture approach to creating applications provides us with many benefits, but there are also some pitfalls that we should address. Let's start by reviewing the benefits:

• Developers using a serverless architecture can focus primarily on the code, and can forget everything related to provisioning servers, which is a task handled by the cloud provider itself.
• The scaling of the code is ephemeral, meaning that it can be scaled and can spin up or down, based on the number of requests retrieved.
• By definition, all of the functions used to code the business logic must be stateless, and therefore, loosely coupled. In this way, the tasks are focused on well-defined responsibilities.
• Functions can be asynchronously triggered by events.
• We only have to pay for the compute time consumed.  
• The functions base their functionality on an event-driven model.
• Infinite scaling can be achieved for developers in a transparent way. 

On the other hand, there are also some pitfalls:

• A lack of documentation and showcases that can be used as references
• Latency issues that are introduced when many services have to be consumed at the same time
• Some features are only available from certain cloud providers. 
• Vendor lock-in

In order to tackle the pitfall of vendor lock-in, it is highly recommended to use a polycloud approach as a part of a serverless architecture. A polycloud strategy involves using more than one cloud provider. This is important because, with it, we can take advantage of the strengths of different vendors and different products. For example, Google offers awesome services for machine learning, AWS provides a wide variety of standard services, and Microsoft Azure has awesome features for functions such as remote debugging. On the other hand, cloud-agnostic strategies recommend that we avoid sticking to a determined cloud provider as much as possible, in order to have the freedom to deploy systems whenever we want to. However, this would be difficult to achieve, because it would mean designing systems in a more generic way, ignoring specific vendor features that offer additional advantages.