How does the serverless architecture style work?

A server is a physical entity capable of running code/software, while serverless architecture involves writing software that leverages a cloud platform to completely provision and manage servers. This approach offers quicker deployment and pay-as-you-go flexibility, making it suitable for lightweight applications. However, it's crucial to evaluate serverless use cases and limitations before proceeding

Imagine a world where servers are ghosts: gone, but your app still runs! That's serverless. Your code dances on the cloud, using resources on-demand (storage, computing, security). You focus on building, not babysitting servers. It scales like magic, pays only for what it uses, and frees you to create awesome products. It's serverless bliss!

Serverless doesn't mean there are no servers involved. The word is from the point of view of developers or the person managing the application, as they don't have to worry about managing the infrastructure to run the application or functions (hence no server in view, serverless). They just create the applications/functions and put them on the cloud. The cloud manages the required computing resources on demand.

Serverless architecture is a cloud computing approach where developers write code for individual functions without managing servers, letting the cloud provider handle infrastructure, scaling, and resource allocation dynamically.

Serverless architecture involves building applications using functions hosted on cloud services, triggered by events like HTTP requests. It's characterized by automatic scaling, no server management, and pay-per-use billing. This approach allows developers to focus on writing code without worrying about server maintenance, offering scalability and cost-efficiency. However, it can have limitations such as startup delays for functions ("cold starts").

1_>Automatic: Code runs on-demand without manual server setups. 2_>Efficient: Only uses resources when code is active, reducing waste. 3_>Scalable: Adapts to user traffic, handling more or fewer requests smoothly.

Pay only for what you use, no upfront costs or idle server expenses. Easily handle changes in demand without manual adjustments. Handle traffic spikes seamlessly without manual intervention. Cloud providers manage underlying security, ensuring compliance with standards.

Para pequenas empresas e startups a arquitetura sem servidor pode ser vantajosa por não possuir custos fixos mensais: você paga somente pelo que utilizar. Além disso esse tipo de arquitetura pode dispensar a necessidade de manter uma equipe própria de infraestrutura e operações, que podem representar um custo proibitivo para pequenas empresas.

- Cost-Effective Scalability: Serverless functions scale automatically based on demand, eliminating the need for over-provisioned servers and reducing operational costs. - Faster Time-to-Market: With serverless, developers can focus solely on writing code without worrying about infrastructure management, enabling quicker deployment of applications and features. - Efficient Resource Utilization: Serverless architecture allocates resources dynamically, ensuring optimal utilization and eliminating idle server times, resulting in improved efficiency and reduced waste.

The SQS "Receive Message Wait" parameter allows the application to perform parameterized readings, in accordance with the business strategy and free processing, when there are no messages to be processed.

Sometimes, serverless functions take a bit longer to start if they haven't been used recently. Serverless functions have maximum time limits, so they might not be suitable for really long tasks.

AWS provides a set of components for several programming languages. This facilitates the work of the developer who can use the programming language of their choice in addition to helping companies in the process of migrating to an infrastructure-free environment in the AWS Cloud.

Arquiteturas sem servidor são geralmente distribuídas e baseadas em eventos assíncronos, por conta disso qualquer projeto pode crescer em complexidade de forma exponencial caso não haja uma preocupação com a arquitetura geral do sistema desde o início. Observabilidade deve ser uma preocupação desde o primeiro momento quando se trabalha com esse tipo de arquitetura.

- Cold Start Delays: Serverless functions may experience latency during initial invocation, known as "cold starts," which can impact user experience and performance. - Limited Runtime Environment: Serverless platforms impose constraints on runtime environments, restricting access to certain resources and libraries, which may hinder the development of complex applications. - Debugging Complexity: Debugging serverless functions can be challenging due to the distributed nature of serverless architectures and the lack of visibility into underlying infrastructure, making troubleshooting more time-consuming and intricate.

use ENDPOINT=URL SQS available after creating the SQS, through the AWS panel. We will use the URL programmatically in a system that will send messages in AWS SQS, allowing Reading and Writing in this environment.

Em uma arquitetura serverless uma requisição do usuário, ou uma gravação em banco de dados pode desencadear uma série de chamadas de funções, as quais são processadas de forma assíncrona e estão sujeitas a falhas. É essencial ter clareza sobre isso para que os aplicativos sejam projetados de forma resiliente e que sejam fáceis de depurar, para isso é preciso fazer bom uso dos registros de log e manter identificadores que permitam acompanhar todo o fluxo de execuções desencadeado por um evento.

1. Function Decomposition: Break down the application into small, independent functions that perform specific tasks, enabling efficient scaling and improved manageability. 2. Event-Driven Architecture: Design the application to respond to events from various sources, such as HTTP requests, database changes, or file uploads, allowing for asynchronous and scalable processing. 3. State Management: Implement stateless functions whenever possible to simplify deployment and enhance scalability. Utilize managed services like databases, queues, and object storage to manage application state and ensure seamless scaling and fault tolerance.

Existem diversas opções de provedores com serviços serverless. Escolher qual deles utilizar deve levar em consideração o lock-in do uso desse tipo de tecnologia com o provedor escolhido, já que muitas vezes os serviços oferecidos pelos provedores são proprietários e não podem ser migrados sem esforço para outros provedores. É importante ter isso em mente durante o desenvolvimento para que se crie camadas de responsabilidade que reduzam o acoplamento do sistema aos serviços do provedor, facilitando um pouco a migração futura caso necessário.

Apesar de oferecer escalabilidade técnica, as arquiteturas sem servidor nem sempre oferecem escalabilidade financeira. Assim, invariavelmente com o crescimento do produto e da empresa chegará um momento em que se deve considerar outros tipos de solução não serverless por conta do custo. É importante que a empresa tenha clareza desse limiar a partir do qual o custo do serverless se torna mais alto do que o custo para manter uma infraestrutura gerenciada.

Hay que tener en cuenta que al diseñar serverless posiblemente generemos dependencia del proveedor de cloud. Hay que tener buena nomenclatura para etiquetar los servicios creados para tener un inventario de lo servicios serverless usados. Diseñar arquitecturas serverless impacto en el costo cuando el rendimiento no es el adecuado

You could also consider a Microservice architecture. Think of it as building blocks for your app. Instead of one big chunk, it's like having smaller, independent parts that work together. Each part, or "microservice," does a specific job, making your app flexible, easy to update, and scalable. It's like having a team of specialists working in harmony to create a powerful and efficient system.