[música tocando] Olá a todos. Obrigada por assistir essa sessão. Eu sou Amanda Quinto
e eu sou Arquiteta de Soluções na AWS para o setor público. Hoje eu vou conversar
um pouco com vocês sobre como
o sistema cooperativo Unicred implementou operações de cartões
utilizando serverless na AWS e para me ajudar a contar
essa história, o Alessandro Guzzo
está aqui comigo também. Guzzo, você pode
se apresentar por favor? Olá, Amanda. Olá, pessoal. Meu nome é Alessandro Guzzo
e eu vou falar um pouquinho com vocês desse projeto,
dessa conquista da Unicred. A Unicred é um sistema cooperativo
formado por 34 cooperativas. É um sistema de crédito financeiro. Está presente em mais de 60%
do território nacional brasileiro. Ela é composta por uma confederação,
quatro centrais. Central Rio Grande do Sul,
Central Santa Catarina, Central Minas Gerais
e Central Rio de Janeiro. Hoje a gente tem
mais de 240 pontos de atendimento, então, 240 pontos
de atendimento ao cooperado. Então, a gente está presente
em 60% do território nacional. A gente é um sistema cooperativo
que nasceu da área da saúde. A gente começou prestando
esse serviço, fornecendo produtos e serviços
para médicos da área da saúde e agora a gente expandiu, então, a gente tem cooperativas
com livre admissão que passam a atender vários públicos, cooperativas nichadas
que atendem médicos. Mas é um sistema que está crescendo,
a gente está em expansão, bem grande. Dentro dessa expansão,
vem se tornando necessário algumas melhorias e alguns passos
tanto no fornecimento de produtos. Então, esse case é um dos pontos
que é bem estratégico para a Unicred. É importantíssimo na estratégia dela,
dentro da área de atuação. E a gente vai falar
um pouco desse case. Vou contar um pouco dessa história
para vocês com mais detalhes como ele aconteceu. Bom, falando um pouco do desafio. O desafio então era a gente constituir uma operação própria
de cartões de crédito e débito. O que é isso?
É a gente passar a emitir de maneira própria
os nossos cartões. Atualmente a gente utiliza
parceiros de negócios para fazer essas emissões. A gente, após um estudo
de mais de anos aí, a gente decidiu que a gente ia passar
a fazer essa emissão própria. Essa emissão própria passa a ter
uma bandeira que vai te apoiar nessa parte,
os arranjos de pagamentos mais processadora
e outros fornecedores que compõem essa cadeia
de cartões, de emissão de cartões. Então, não é só uma emissão,
é um projeto complexo. Ele é um projeto que envolve
muitos fornecedores e envolve também muita tecnologia. Algumas pontos, algumas premissas
foram estabelecidas no início deste desafio. Primeiro: a gente tinha como ponto
a segurança. Então, a gente precisava ter
um ambiente seguro, um ambiente que nos desse
toda a segurança tanto segurança cibernética quanto segurança
de prevenção de fraude quanto segurança de desenvolvimento
e de evolução, e que nos desse também
aquela escalabilidade de aplicação. Outro ponto é a rentabilidade. A gente precisava
que esse produto fosse rentável. Então, a gente precisava procurar
por uma solução que nos trouxesse tanto rentabilidade,
que nos desse a possibilidade também de fazer um gerenciamento
desses custos. Era importante para nós
gerenciar os custos, otimizar, ganhar escala. Então, eram pontos
que eram muito importantes e a gente não podia abrir mão. A ingestão de dados. Outro ponto: conhecer o comportamento
do nosso cooperado. Como é o comportamento
de compra dele, horário de compra, onde ele compra,
como é a utilização, fazer a gestão desses dados,
conseguir gerar métricas, conseguir gerar informações
para dar insumos para o quê? Para fazer o fomento do produto
para a parte comercial, para poder vender, colocar o produto. Se precisar nichar ele,
nichar esse produto. E também para dentro de casa. Melhorar a performance, disponibilizar cada vez mais
esse serviço com uma alta disponibilidade
para ele. Então, a ingestão de dados
era muito importante. E a inovação. A Unicred em si não tinha ainda
a experiência de trabalhar com nuvem. Então nuvem, por enquanto, era um projeto
que se conversava muito em ir para a nuvem e estar na nuvem. Então, a gente começou
com um grande ponto, um grande desafio, que era: como a gente começaria
essa jornada? E aí, a gente trouxe
alguns parceiros, um parceiro AWS para conversar um pouco de como a gente conseguiria
constituir esse produto. Primeiro, a gente teria
que lançar ele em no máximo um ano. Então, a gente tinha
um timing de lançamento bem agressivo para uma operação
completa de cartões. E a gente tinha um ponto
do lado de cá que a gente não tinha
a maturidade correta ou a maturidade
para levar esse projeto. Então, aí a AWS veio e a gente fez todo um trabalho
de treinamento, um trabalho de consultoria
com a AWS e começamos o desenvolvimento. Então, a gente inseriu
nesse processo, profissionais que nos dessem
sustentação dentro da nossa arquitetura
com o objetivo de quê? De lançar esse produto em um ano. Obrigada, Guzzo. Bom, agora que a gente já entendeu
como foi esse desafio na Unicred, vamos entender melhor
como a proposta de serverless pode ajudar tanto a Unicred quanto diversos
outros clientes na AWS. Então, o que os nossos clientes
precisam para ter sucesso? Quais são os benefícios de utilizar
arquiteturas e serviços serverless gerenciados na AWS. Em primeiro lugar,
a gente pode pensar na colocação no mercado. Então, o time to marketing
para lançar novos serviços e novas features e inovação
para os nossos clientes. Ao invés de ficar levando tempo para provisionar infraestrutura,
provisionar servidores, o cliente foca exatamente
no que ele precisa, criar a nova feature
que ele vai lançar, um novo produto que ele vai lançar e deixa toda
a parte de infraestrutura para a AWS. Se preocupa realmente ali
com o código e com o que ele está criando. Diminuição de custos também
é um valor agregado na utilização de serviços serverless
e gerenciados na AWS. Então, utilizando soluções serverless onde você não tem desperdício
de capacidade computacional, por exemplo,
dá para reduzir muito o TCO, então, o custo total ali
da propriedade deste projeto. E também contar com soluções de altíssimo desempenho
e escalabilidade com toda a capacidade computacional
e operacional da AWS. E por último,
mas não menos importante, segurança. Segurança é prioridade na AWS
utilizando serviços gerenciados e serviços serverless,
algumas camadas de segurança já estão agregadas a esse serviço. Então, a gente vai ver
um pouco melhor quando formos falar ali
da arquitetura realmente, da implementação da Unicred. Mas é importante
levar em consideração esses quatro itens aqui
para utilizar serverless em diversos projetos na AWS. Uma pesquisa feita pela Deloitte
em 2019 demonstra que os CIOs dizem que até 80%
do tempo dos desenvolvedores é gasto em operações e manutenção
das aplicações e apenas 20% do tempo é gasto
realmente com inovação e com criação
de novos produtos e serviços. A utilização de serviços
gerenciados pela AWS pode auxiliar os nossos clientes
a diminuir essa conta aqui, fazer com que mais tempo seja gasto em efetivamente implementar
novos serviços e novos projetos. E aí, embora muitos clientes
associem serverless na AWS ao AWS Lambda, que é um
dos nossos serviços de serverless, talvez o mais conhecido deles, existe toda uma gama
de outros serviços em diversos segmentos diferentes. Então, quando a gente fala
de computação, a primeira coisa que realmente
vem à cabeça é o AWS Lambda, mas também tem o AWS Fargate,
que a utilização de containers na estrutura da AWS
sem se preocupar com servidores. Então, quando a gente pensa
em containers, a gente pensa que os containers
estarão rodando em cima de alguma máquina virtual,
uma EC2. Mas, utilizando a tecnologia
do AWS Fargate, é possível rodar containers
sem se preocupar se o seu servidor
está com disco cheio, se o seu servidor está
com o sistema operacional atualizado e o cliente se preocupa realmente
só com o seu container ali, com a criação da sua imagem
e a implementação da sua aplicação utilizando esse tipo de tecnologia e não mais com nenhum tipo
de problemas de infraestrutura ali que a gente enfrenta no dia a dia. Então, pensando em computação,
além do conhecido AWS Lambda, que é a utilização de funções
como serviço na AWS, tem também o AWS Fargate. Quando a gente fala
de armazenamento de dados, também tem toda
uma camada de serviços que utiliza computação serverless
por trás dos panos. Então, o também conhecido Amazon S3
é um serviço da AWS de storage de objetos
onde você se preocupa apenas com o seu objeto
efetivamente, com o dado
que você quer armazenar ali. Você não precisa
nem provisionar computação, muito menos disco. Então, a capacidade computacional
dessa empresa é medida de acordo com a demanda
e o armazenamento também. Como a gente comentou sobre os benefícios
da utilização de serverless, é pago apenas pelo que é
efetivamente armazenado no S3 e não pelo provisionado. Uma vez que você não precisa
provisionar capacidade operacional para armazenar os seus dados no S3. Tem outras possibilidades também
de armazenamento serverless na AWS como por exemplo,
o Amazon Aurora Serverless. O Aurora é um desenvolvimento próprio
da AWS onde você consegue lançar
o seu banco de dados relacional baseado na engine de uma SQL
ou de Postgres ganhando aí até cinco vezes mais
em desempenho em MySQL e até três vezes mais desempenho
utilizando a engine Postgres em cima de Amazon Aurora. E o Amazon Aurora Serverless
por sua vez, você se preocupa efetivamente com a utilização
da capacidade computacional e não no provisionamento. Então, ele pode ser provisionado
de acordo com a necessidade do cliente
e não mais de acordo com o estimado, quando você estima
uma máquina virtual ali mesmo que seja
para um banco de dados relacional. E por fim, o Amazon DynamoDB, que inclusive é utilizado
pela Unicred. A gente vai falar um pouco mais
daqui a pouco também. É um banco de dados chave-valor
da AWS onde você efetivamente não vê nada
relacionado à computação também. Você se preocupa apenas
na criação ali da sua tabela e a implementação do seu código
para utilizar essa tabela, para armazenar dados, para consultar dados
das tabelas do DynamoDB e nada se preocupa
com relação à implementação, infraestrutura e gerenciamento
desse ambiente. A gente poderia ficar aqui
falando horas sobre as capacidades
de serverless na AWS. Eu quis trazer para vocês
apenas alguns dos exemplos de serviços serverless que foram inclusive utilizados
nesse projeto. Mas vamos adiante
para vocês entenderem um pouco melhor também
como os modelos de computação na AWS podem aumentar ou diminuir o quanto
que o cliente efetivamente precisa gerenciar de infraestrutura. Então aqui, quando a gente pensa
em AWS Lambda, como a gente já comentou ali
as funções como serviços na AWS, é onde você menos gerencia
a parte de infraestrutura. Você coloca o seu código
para funcionar no Lambda e não precisa se preocupar com absolutamente nada
relacionado a computação. Quando a gente pensa em Fargate, tem um pouco mais de gerenciamento
do que o Lambda porque você precisa efetivamente
se preocupar com a implementação dos seus containers,
boas práticas de containers, utilização de imagens
de containers seguras, etc. Mas também existem serviços
na AWS que podem te ajudar nesse gerenciamento. E aqui onde eu quero chegar,
é na utilização do Amazon EKS, que é o Amazon
Elastic Kubernetes Service da AWS que também é utilizado nesse projeto, onde o gerenciamento
da infraestrutura quando utilizando o Fargate, quando está sendo utilizado
o Fargate, ele fica também apenas
no gerenciamento da utilização do cluster de Kubernetes. Então, a criação ali dos serviços
relacionados ao Kubernetes, serviços de exposição, de APIs, serviços de balanceamento
dentro do cluster. Mas a infraestrutura
e a capacidade operacional de tudo isso é gerenciada pela AWS. Quando não está sendo utilizada
a computação através do Fargate, está utilizado ali o cluster também, gerenciado pela AWS,
mas com máquinas virtuais com EC2 por baixo desse cluster,
o gerenciamento também diminui. Porque você utilizar o cluster
de Kubernetes na AWS sem utilizar das capacidades
do Amazon EKS, por exemplo, você precisa se preocupar
com toda a questão da orquestração desse serviço. Então, efetivamente lançar
as suas EC2 na AWS, configurar todos os componentes
de infraestrutura do Kubernetes. Então, o gerenciamento
de um banco de dados, gerenciamento das APIs. Não vou entrar muito no detalhe,
mas é importante saber que tem mais uma camada
de gerenciamento requerida quando está utilizando EC2
com Kubernetes apenas. Então, a utilização
de máquinas virtuais de EC2, mas com EKS, facilita muito
o gerenciamento no dia a dia e, como eu venho falando aqui, é também dessa forma
que a Unicred utiliza. Mas, vamos ver agora realmente
como essa solução foi implementada baseado no desafio
que o Guzzo trouxe para a gente. Então, vamos entender melhor
essa arquitetura para que a gente consiga agora,
já que já temos um contexto das funções serverless na AWS de como funciona o gerenciamento
de containers na AWS de maneira gerenciada. Vamos agora ver então,
efetivamente essa solução da Unicred. Então, falando um pouco mais
sobre a solução. Essa daqui é a arquitetura geral
dessa solução da implementação da operação de cartão de crédito
e de débito da Unicred na AWS. Então, a gente descer um pouco mais
no detalhe no próximo slide, mas é importante entender
alguns pontos aqui. Então, logo de entrada,
a gente tem uma AWS WAF, que é um serviço de firewall
de aplicação da AWS onde o cliente se preocupa apenas
nas regras que ele vai aplicar e em quais serviços ele vai
efetivamente aplicar essas regras. Não precisa se preocupar
em provisionar servidor, em gerenciar servidor, nada disso. É um serviço totalmente gerenciado
pela AWS. Aqui, no caso da Unicred,
foi utilizado o Amazon API Gateway para expor as APIs da Unicred
e outros serviços serverless também que eu inclusive vou abster aqui
os benefícios. Já comentamos bastante sobre
os benefícios da utilização do serverless. E aí tem um ponto importante
aqui nessa arquitetura. O Amazon API Gateway, para que ele se comunique
com os serviços privados, então, mais uma camada
de segurança aqui, é a utilização de redes segmentadas e a Unicred utiliza todas
as suas APIs de maneira privada ali, então, para que o API Gateway se comunique com essa infraestrutura
dentro do Amazon VPC, é importante, é necessário
a utilização de um VPC Link. Então, um VPC Link é configurado
no API Gateway para que ele exponha os serviços
de maneira privada que estão rodando dentro da VPC. E aqui, quando a gente fala
de serviços neste contexto, estamos falando dos micro serviços
que estão rodando dentro do Amazon EKS, como a gente já comentou
alguns benefícios também da utilização de Amazon EKS,
eu vou abster. Mas é importante entender aqui
que todo o backend dessa operação está rodando majoritariamente
dentro do Amazon EKS. Esses containers, essas aplicações que estão rodando
dentro desse ambiente, por sua vez, se comunicam
com múltiplos outros serviços. Aqui nessa arquitetura geral
da solução, vamos falar apenas de dois. Então, para o banco de dados está sendo utilizado o Amazon RDS
com a engine Postgres. Então, a utilização
de um serviço gerenciado, dessa vez
não é um serviço serverless, mas é gerenciado pela AWS. Então, a Unicred precisa se preocupar
apenas com a engine que está sendo utilizada,
que no caso é o Postgres e se preocupar ali com o schema
do seu banco de dados e os seus dados efetivamente. Toda a parte de infraestrutura
e provisionamento do servidor, do sistema operacional,
de firmware, tudo isso é feito,
todo esse gerenciamento pela AWS. E do outro lado, nós temos
o Amazon Managed Streaming for Kafka que é o MSK, Amazon MSK, que é a utilização
do Kafka efetivamente aqui na AWS como um serviço gerenciado também. Então, gerenciar um cluster de Kafka
pode ser um serviço, uma função bem desafiadora também
e a utilização do MSK facilita bastante esse gerenciamento. Aqui nessa arquitetura,
eu não vou entrar no detalhe do que cada um dos serviços faz,
quais são os fluxos das transações. A gente vai falar um pouco
mais disso daqui a pouco, mas é importante saber
que o Amazon MSK, o Managed Stream for Kafka, ele é utilizado, por exemplo,
para a emissão de cartões de crédito e para alguns fluxo
de faturamento também. E aqui do lado,
temos alguns outros serviços que eu vou detalhar melhor
na próxima arquitetura, como eles são utilizados. Então, essa daqui é uma arquitetura das transações
de débito efetivamente, então agora, a gente vai entender
como um dos diversos fluxos que foram implementados
pela Unicred na AWS, como que um desses fluxos
funciona na prática, na vida real. Então, se a gente seguir aqui
a arquitetura, a gente começa a transação
quando um parceiro da Unicred se comunica com essa arquitetura
passando ali efetivamente um payload de agência e conta do cliente
para que se inicie um processo de liberação de transação de débito. Então, utilizando uma VPN aqui
e nesse caso, eu abstraí já
toda aquela questão do WAF, do VPC Link
e do Network Load Balancer que a gente viu
na arquitetura anterior, aquela parte da arquitetura,
ela é utilizada para todos os demais fluxos. Então, como a gente já viu,
eu deixei essa parte abstraída para facilitar o entendimento
aqui também. Então, esse parceiro da Unicred
se comunica através de uma VPN com o Amazon API Gateway,
que por sua vez, faz uma chamada de um serviço
de backend que está rodando
dentro do Amazon EKS. O que esse serviços faz? Para que essa resposta seja
o mais próximo do tempo real, do near real time para a transação não demorar
na maquininha efetivamente, a consulta é feita direto no DynamoDB para agregar esses dados
de agência e conta com mais algumas informações
para que seja então validado se esse cliente tem saldo disponível
para liberar essa transação. Então, não é efetivamente debitado
esse valor no primeiro momento da conta do cliente,
é só apenas uma validação de saldo. E essa validação de saldo é feita no ambiente
da Unicred também, então, dentro
do datacenter da Unicred, no core banking da Unicred
é feita essa validação. Então, é um cenário
de uma arquitetura híbrida que ainda utiliza
serviços on premises e isso é bem comum na realidade
para clientes do setor financeiro. Então, retomando aqui o raciocínio, a gente começa a transação
através de um parceiro pelo API Gateway que consome
um serviço ali do backend. Esse serviço recebe as informações
de agência e conta ali do cartão de crédito que está sendo
efetivamente processada a transação, agrega informações
que estão no DynamoDB e faz uma consulta de saldo
no datacenter da Unicred dentro dos serviços do core banking. Esse saldo sendo positivo,
o cliente tendo saldo para concretizar essa transação,
já é liberada a transação na maquininha que está operando,
ele já tem a transação aceita neste mesmo momento. Para que continue o processo de efetivamente debitar esse valor
da conta do cliente, uma outra thread é iniciada
dentro desse mesmo micro serviço, onde ele inicia o processo
de comunicação também com o datacenter com os serviços
do core banking da Unicred e vai efetivamente ali debitar
esse valor da conta. Ele tendo um sucesso, não tendo nenhum problema
de comunicação, a VPN não caiu nem nada disso,
ele tendo sucesso, ele finaliza essa transação,
faz a extração do valor da conta do cliente ali e armazena essa informação
também no DynamoDB. Então, o fluxo das transações,
o histórico das transações ele também fica armazenado
no DynamoDB. Uma vez essa transação armazenada, o Kinesis Firehose extrai
essa informação e inicia o processo da criação
do que vai ser, que é na verdade, um Data Lake sendo criado ali baseado nas transações
dos cartões de crédito. Então, ele extrai essa informação
do DynamoDB e ele armazenamento em um S3
em uma pasta role. O Amazon AWS Glue gera parquês, ele transforma esse dado em parquê,
faz agregações desse dado e armazena ele em uma pasta staging,
que por sua vez, tudo isso sempre dentro do S3, esse Data Lake está sendo construído
dentro do S3, que por sua vez, posteriormente
a criação de um Data Catalogue dentro do AWS Glue,
é consumido ali pelo Athena. Então, alguns parceiros
que precisam consumir informações de transição, de volumetria ali
da Unicred, eles podem apenas se conectar
ao Athena que eles já têm esse Data Lake
sendo alimentado pelo Kinesis Data Firehose. Então, esse é o fluxo de sucesso
de uma transação. Ele se inicia com o parceiro
passando essa transação para dentro da Unicred, a Unicred validando o saldo
dentro do seu datacenter, armazenando essa transação
no DynamoDB e efetivamente subtraindo o valor
da conta do cliente posteriormente e gerando um Data Lake em cima disso. Para um fluxo de falha
em casos de falha de comunicação, como eu comentei aqui. A VPN caiu por algum motivo,
teve um outage dentro do datacenter ou até mesmo em algum micro serviço
ou algo do tipo, essa falha de transação
é enviada como uma mensagem. É feita uma criação de uma mensagem
ali dentro do Amazon SQS, que é o serviço
de mensageria serverless da AWS onde um AWS Lambda que a gente
já comentou um pouco sobre ele vai consumir essas transações
que não foram efetivamente debitadas das contas dos clientes, ele vai consumir essa fila no SQS
e vai finalizar a transação dentro do datacenter da Unicred
consumindo as APIs do core banking. Então, esse fluxo aqui
na parte de baixo da arquitetura onde tem o Amazon SQS, o AWS Lambda
efetivamente para processamento em caso de falhas ou em caso
de erros nos micro serviços ou algo do tipo. Depois que o débito é feito
também ali na conta do cliente ou em casos de estorno também,
tudo isso é armazenado, todas essas transações
são armazenadas também no DynamoDB por este Lambda, que aí começa o fluxo da criação
do Data Lake, também é feito da mesma forma
pelo Kinesis em caso de falha também. Legal, então aqui temos
uma visão geral de uma arquitetura das transações de débito
dos cartões de crédito da Unicred sendo processadas na AWS. Existem diversas outras
arquiteturas similares a essa para múltiplos fluxos
dentro da Unicred, mas hoje a ideia
era explicar para vocês como as transações de débito ocorrem. Com um ambiente tão vasto como esse, com uma arquitetura cheia de serviços
operando ali no Amazon EKS, é importante que o monitoramento
também esteja em dia e para isso é utilizado
o Amazon CloudWatch com containers Insights habilitado e aqui a gente traz
para vocês uma visão do que é uma das dezenas
de dashboards que são utilizadas pela Unicred
também para monitorar esse ambiente. Então, dá pra vocês terem aqui
uma visão geral de como a Unicred
monitora os logs e o comportamento
do seu cluster de Kubernetes que está rodando ali no EKS. Bom, falei bastante. Falamos bastante
da parte técnica aqui. Agora, o Alessandro Guzzo
vai explicar um pouco para vocês quais foram os resultados obtidos
com essas implementações, com essa arquitetura e para entender o quanto é processado
dentro desse ambiente, quais foram os impactos efetivamente
para o negócio. Falando um pouco
de resultado, pessoal, após a gente lançar esse produto, esse processo durou
um ano de desenvolvimento. A Amanda já falou um pouco
da arquitetura que foi desenvolvido esse produto. É um arquitetura bem robusta,
auto escalável. É um arquitetura
que é o embrião da Unicred após a gente fazer a migração
de outros produtos para dentro da AWS,
crédito, investimento, cobrança, canais digitais, internet banking,
toda essa parte aí. Então, a gente teve resultados
muito positivos. Olhando um pouquinho
para os nossos resultados, a gente atualmente está
com mais de 100 mil cartões emitidos, mais de 100 mil cartões emitidos
aí na praça. Mais de 220 milhões de faturamento
por mês. E com mais de cinco milhões
de transações. Então esse aí,
no resultado do primeiro ano, a gente está fechando, fechou o primeiro ano
com 1 bi, 1,2 bi. Vai fechar o ano de 2021
com 1,8 bi de faturamento. E uma estrutura hoje
que é 100% gerenciada por nós tanto na questão de custo,
na questão de recursos, na questão de desenvolvimento. Em todo esse ponto o produto nos dá
alta gestão nesse ponto. Falando um pouco nos impactos
para o negócio, a gente tem o aumento da oferta
de cartões no mercado com alta disponibilidade,
com funcionalidades liberadas rapidamente
e sem falhas. Também temos a redução de custos
para administrar essa estrutura, então a gente só trabalha
em cima da otimização e não mais na gestão de máquina
ou de um datacenter. E a gente passa também agora
a estar trabalhando com tecnologia em nuvem. Então, a gente passa aí
a entrar também junto com os outros bancos
nessa competição, nesse mercado aí estando trabalhando
com essa tecnologia. Pessoal, era isso. Eu agradeço o convite, Amanda. Meu nome é Alessandro Guzzo
e está aí o meu contato para quem quiser entrar
em contato comigo aí. Eu ficarei bem feliz em compartilhar um pouco mais
dessa experiência. Muito obrigada, Guzzo.
Obrigada a todos. Eu sou Amanda
e esses são os meus contatos. [música tocando]