- Para startups em estágio inicial, pode ser melhor gastar tempo construindo o produto e buscando product-market fit do que já começar com Kubernetes e auto scaling desde o primeiro dia
- 20 a 30 funções Lambda, junto com SQS e logs espalhados pelo CloudWatch, tornaram debugging, mudanças e deploy mais difíceis; havia espaço para simplificar com um único contêiner NodeJS ou um app Flask/FastAPI com Redis
- Em um caso com 7 microsserviços no EKS separando CRUD e lógica de negócio, mais tempo foi gasto operando a infraestrutura do que desenvolvendo funcionalidades
- Até uma única VM pode fornecer computação suficiente para serviços iniciais com opções como EC2, GCP VM, Hetzner e latitude.sh, usando servidores na faixa de 40GB de RAM e múltiplos cores
- Mesmo com uma arquitetura simples, é preciso ter HTTPS, SSH/SSM com acesso restrito, CI/CD, DNS, backup de banco de dados, VM de espera, recuperação de desastre, regras de segurança e políticas de retenção de backup para uso real em produção
Como startups iniciais acabam com infraestrutura excessiva
- Pieter Levels é citado como exemplo de alguém que opera vários micro-SaaS em um único servidor, evitando a complexidade da infraestrutura de cloud e focando em product-market fit
- Essa abordagem não é a resposta certa para todos os times, mas mostra bem situações em que deploy e gestão de infraestrutura ficam complexos apenas por serem complexos
- Pequenos times de desenvolvimento após o MVP podem ter dificuldades com deploy e administração de banco de dados, mas nem todo projeto precisa de Kubernetes, sistemas distribuídos complexos e auto scaling desde o primeiro dia
- Uma infraestrutura simples permite que o time passe mais tempo criando um bom produto e encontrando adequação ao mercado
- Empresas em escala enterprise têm problemas próprios, como compliance e grandes equipes, mas startups iniciais não precisam copiar essa complexidade
Casos reais: a carga operacional criada pela complexidade
-
Sobrecarga de Lambda
- Havia de 20 a 30 funções Lambda para diferentes serviços
- SQS e vários trabalhos em background também eram baseados em Lambda
- Os logs ficavam espalhados pelo CloudWatch, dificultando rastrear a causa dos problemas
- Fazer debugging era doloroso, alterar era complicado e até em um monorepo o deploy ficou complexo
- Dava para simplificar com um único contêiner NodeJS ou um app Python Flask/FastAPI, com jobs em background baseados em Redis
-
Excesso de microsserviços
- Havia 7 pequenos microsserviços rodando em Kubernetes EKS
- CRUD e lógica de negócio estavam separados em serviços distintos
- Kubernetes é poderoso, mas aquele time gastava mais tempo com infraestrutura do que com desenvolvimento de funcionalidades
- Fica a dúvida se aquele nível de separação de serviços era realmente necessário naquela escala
Por que a abordagem de servidor único é realista
- A configuração com servidor único aproveita de forma agressiva o desempenho das VMs modernas
- É possível conseguir VMs potentes e com bom custo-benefício na Hetzner e na latitude.sh
- Instâncias GCP VMs e EC2 também têm preços razoáveis
- Um servidor com 40GB de RAM e vários cores pode ser uma escolha melhor do que vários serviços distribuídos, várias Lambdas ou várias tasks no ECS
- Como tudo fica centralizado, operar e administrar se torna mais fácil
- Escalar para centenas de milhões de QPS pode ser tratado quando esse momento realmente chegar, e até lá é provável que já exista um time de infraestrutura
- Para operar uma VM única de forma estável, alguns fundamentos são necessários
- Uma máquina robusta como EC2, GCP VM ou Hetzner
- HTTPS para a web e acesso seguro como SSH com restrição de IP ou SSM para deploy
- CI/CD para deploy sem downtime
- Configuração de DNS
- Backups regulares do banco de dados
- Uma VM de espera para redundância
- Uma estratégia sólida de recuperação de desastre, com tempo médio de recuperação testado, algo que pode ser alcançado com uma VM de backup
Docker Compose e Docker Compose Anywhere
- O Docker Compose é ótimo no desenvolvimento local para gerenciar vários serviços com um único comando, mas é menos usado em produção
- É mencionado que o Docker Swarm foi deprecated
- O Docker Compose pode causar downtime durante atualizações
- Existe um guia de deploy em produção, e é preciso equilibrar simplicidade com prontidão para produção
- Docker Compose Anywhere é um projeto de fim de semana para simplificar ainda mais a configuração com VM única
- Faz setup de um servidor Linux com um clique via GitHub Actions
- Usa GitHub Container Registry e Docker Rollout para suportar deploy contínuo sem downtime
- Oferece gerenciamento de variáveis de ambiente e secrets, com age e sops sendo considerados para melhorar a segurança
- Fornece backup automático de Postgres com base em GitHub Actions
- Suporta vários apps em uma única VM
- Automatiza SSL com Traefik e Let’s Encrypt
- Permite fazer deploy de apps Next.js, Go, Python e Node.js, entre outros
Princípios de segurança e operação que não podem faltar, mesmo na simplicidade
- Segurança e proteção de dados não podem ser ignoradas nem em uma configuração simples
- São necessárias regras rígidas de firewall, abrindo apenas as portas necessárias
- As chaves SSH devem ser gerenciadas com segurança; na AWS, prefere-se SSM, e no GCP, CLI
- Um bastion host pode ser usado para reforçar a segurança
- É preciso proteger os secrets e considerar o uso de WAF ou Cloudflare
- Backups criptografados do banco de dados devem ser enviados para o S3 ou armazenamento em nuvem equivalente e seguro
- Snapshots de disco devem ser criados regularmente para redundância adicional
- É preciso implementar políticas de retenção para backups e snapshots
- A prioridade do engenheiro é manter a simplicidade da configuração e focar no produto principal
- É fácil se distrair com configurações complexas que imitam o Google Engineering ou práticas de grandes empresas, além de novas ferramentas
- Seja startup ou não, o mais importante é conversar com os usuários e encontrar product-market fit
1 comentários
Opiniões do Hacker News
Já sofri muito em vários projetos por causa de tecnologias da moda
Mesmo dizendo que a equipe era pequena, acabavam entregando resultados de qualidade incrivelmente baixa sob o argumento de que precisavam de “escalabilidade infinita”; também vi equipes imaturas, que nem entendiam direito o que era LTS, decidirem que precisavam de Kubernetes
Hoje tenho um código Puppet simples que cria uma VM reforçada do tamanho que eu quiser em qualquer provedor e, sobre ela, executa serviços Docker, back-ends Python ou serve arquivos estáticos
Seja uma VM da Hetzner com 2 núcleos ou 48 núcleos, consigo criar o serviço em menos de 5 minutos, controlar a configuração com manifests versionados e monitorar a conformidade da configuração com plugins Naemon customizados
É um processo totalmente reproduzível, mas equipes de startups criam configurações descartáveis, como flocos de neve, na nuvem, gastam milhares de euros por mês e ainda entregam resultados piores do que os pioneiros de DevOps faziam em 2017
Também escrevi um texto sobre esse tema chamado The Emperor's New clouds: https://logical.li/blog/emperors-new-clouds/
Nunca entendi a pergunta “como você reproduz uma configuração sem Docker ou outras tecnologias?”
Os scripts eram determinísticos, as versões das dependências eram fixas, a configuração, os argumentos de entrada e a ordem de execução eram os mesmos, e tudo rodava em uma máquina de computação determinística
Não havia motivo para não ser reproduzível
Em vez de dizer que há Docker em uma VM reforçada, basta dizer que há kubelet; e, em vez de vários “docker services” improvisados, é possível controlar todas essas VMs com um plano de controle k8s de custo muito baixo
Não sei por que essa abordagem seria melhor; na verdade, parece pior
Infraestrutura de nuvem ruim é quando se tenta usar tudo que a AWS vende e toda a infraestrutura acaba presa a camadas de abstração altas demais, impossibilitando a migração para outra plataforma
k8s não tem nada a ver com isso
Se a resposta para qualquer uma dessas perguntas for “algo que eu mesmo fiz” ou “é só usar um script”, isso é exatamente o motivo pelo qual k8s tem valor
Se for um back-end Python, basta reproduzir o script de build na VPS:
pip install requirements.txt>python main.py>nano /etc/systemd/system/myservice.service>systemd start myservice> prontoPara escalar instâncias, é só colocar esses comandos em um script bash
build_my_app.sh, que funciona como um novo Dockerfile e pode ser instalado em qualquer servidor em dezenas de segundosUsada como IaaS, ela permite criar protótipos muito mais rapidamente do que outras abordagens, incluindo VPSs de outros provedores
O Google Cloud, em particular, tem menos efeito de lock-in e se alinha melhor ao princípio da menor surpresa
Mas, depois de criar o protótipo, é preciso se perguntar se vale reconstruí-lo em um lugar mais barato
É bom poder expandir discos quase infinitamente e fazer snapshots, e a nuvem pode permitir escalar um protótipo até uma carga de produção para medir a escala realmente necessária
Mas, quando dependi de “mágica da nuvem” como Cloud Run e Lambda, o tempo gasto aprendendo e depurando acabou sendo tão grande quanto fazer do jeito antigo
Em uma startup pequena, fazemos praticamente assim
Existem partes complexas, como escalonamento automático de filas de trabalho com GPUs misturadas, mas o núcleo é uma única VM com nginx, web app, Postgres e Redis
Como é B2B, quase não há tráfego
Os desenvolvedores conseguem rodar exatamente a mesma configuração em notebooks Linux ou em VMs Linux em outras plataformas e, se quiserem, cada um também pode ter sua própria VM na nuvem para demos ou testes
Fazer o bootstrap de um novo sistema é basicamente registrar uma chave SSH e executar um script de shell
É fácil de depurar, não é complexo nem caro, e dá para fazer bastante escala vertical antes de precisar de escala horizontal
Não serve para todo mundo, mas considero totalmente adequado antes da fase seed
É um nível de indireção a mais em relação à abordagem de “registrar a chave pública”, e permite que o usuário troque a própria chave sem uma alteração no Git
Além disso, embora fuja bastante da descrição original, o aluguel de chaves SSH é excelente porque lida muito melhor com situações de offboarding: https://github.com/hashicorp/vault/blob/v1.12.11/website/con...
Procurando o link, também encontrei uma documentação em que o Vault afirma oferecer senhas de uso único <https://github.com/hashicorp/vault/blob/v1.12.11/website/con...>
Mas eu sou firmemente do time “PasswordLogin no”, então cada um deve ter cuidado com essa opção
O Postgres consegue fazer qualquer coisa
Numa configuração assim, como vocês acompanham a configuração e as atualizações da VM?
A resposta é “não, não precisa”
Meu SaaS rodou inicialmente em um único servidor e, depois de encontrar product-market fit, foi migrado para vários servidores
Eles são servidores bare-metal da Hetzner, não há microsserviços e eu não lido com Kubernetes, mas opero um banco de dados distribuído
Esses servidores bare-metal são incrivelmente poderosos em comparação com as máquinas virtuais de provedores de nuvem
Alguns anos atrás, eu mesmo fiz medições: https://jan.rychter.com/enblog/cloud-server-cpu-performance-...
No geral, essa abordagem é absurdamente eficaz
Você não precisa lidar com a complexidade do Kubernetes, evita as falhas em cascata inevitáveis em sistemas complexos e economiza tempo de desenvolvimento, manutenção e custos mensais de servidores
A objeção comum é “mas e a escalabilidade?”, só que você ainda nem sabe se vai precisar escalar e, com máquinas potentes assim e um projeto razoável, dá para ir muito longe com 3 a 5 servidores
Claro, não estou dizendo para tocar um negócio no armário de casa
Para gerenciar os servidores, automação ainda é necessária, e eu uso ansible e terraform
Ela alimenta o otimismo de que o software vai fazer um sucesso enorme em pouquíssimo tempo, e as pessoas querem acreditar nisso
Não sei se você leu o texto ou só viu o título
Se descer até a seção A few considerations mais abaixo, vai ficar difícil rir
Essas “algumas considerações” são, especialmente se você armazena ou transmite informações muito sensíveis, um volume considerável de trabalho de segurança
Como lidar com requisitos de conformidade como HIPAA nesse tipo de situação?
Existem dois tipos de programadores
Os que acham que já viram de tudo e os que sabem que quase não viram nada
Por isso, esse tipo de afirmação absoluta é cansativo
Os 20% essenciais do Kubernetes são deployments, pods, services, a forma de lidar com deploys blue-green, definições declarativas e separação por namespaces, e isso é realmente ótimo
Se você se ativer a esses fundamentos simples, usar um serviço Kubernetes gerenciado na nuvem e deixar bancos de dados com estado fora do cluster, a experiência é boa
Os problemas começam quando você é sugado para a toca do coelho “cloud native” e passa a usar todo tipo de sistema open source de nicho, operators, ambassador, padrões de sidecar etc.
Essas coisas são para ambientes com várias equipes técnicas independentes, mas interligadas, e diversas linguagens de programação coexistindo
Sinto que, nessas discussões, as pessoas muitas vezes estão falando de duas coisas diferentes
Para mim, é apenas uma forma uniforme de deploy, melhor que Docker Compose
Você paga muito pouco pelo plano de controle, e os workers são VMs comuns com kubelet
Mas, para muita gente, “Kubernetes” parece significar o segundo parágrafo acima
Não há absolutamente nenhuma necessidade de usá-lo assim
Você pode configurar um cluster k3s e aprender só workloads, services e ingress
É disso que você precisa para substituir VMs improvisadas e configurações com Docker
99% só precisam, ou querem, algo como docker-compose++
Se deploy sem downtime vier por padrão e houver um sistema simples de configuração para replica sets ou outros mecanismos de replicação/distribuição, praticamente acabou
Seria bom ter algo que fizesse exatamente isso
Kubernetes traz muita bagagem, e Docker Compose é um pouco básico demais para requisitos importantes de produção
O Kubernetes tem mais ou menos um milhão de botões e controles que você pode ajustar para qualquer uso, mas da mesma forma você pode ignorá-los e usar apenas os recursos centrais, mantendo tudo simples
Dá para montar rapidamente uma configuração com deploys decentes, logs e métricas muito fáceis e uma boa experiência para desenvolvedores
Como a reputação é péssima e eu nunca tinha usado antes, quando perguntei se poderia configurar um servidor para ferramentas internas, me preparei para o pior
Na prática, quem tinha configurado tudo me deu um tutorial de 30 minutos, explicou os conceitos gerais e me passou informação suficiente para fazer o deploy do servidor, e eu fiz sem nenhum problema
Fazer deploy automático com
git pushtambém foi muito rápidoPara mim, pareceu uma escolha óbvia
Se o serviço não for literalmente único, é muito mais fácil de usar
Só que eu não fiz a instalação por conta própria, então talvez a má reputação venha dessa parte
Sem k8s no currículo, quem consegue um emprego novo? :)
Falando sério, acho que muita gente escolhe deliberadamente o caminho difícil para aprender infraestrutura em grande escala
Outro motivo comum é “fica muito mais fácil se tivermos muitos clientes” ou “podemos escalar dinamicamente conforme a demanda”
Para quem constrói, tudo isso é válido, mas não é tão válido assim para um fundador ou um CTO profissional
Algumas pessoas queimam dinheiro criando firulas bonitas, sem se preocupar com as necessidades e os prazos dos potenciais clientes
É como ir à oficina para trocar pneus e o mecânico levar três semanas porque, por necessidade de crescimento pessoal, quer instalar suspensão hidráulica de lowrider e calotas giratórias
O pior é que isso fica inerentemente ambíguo para a próxima pessoa
Não dá para saber se algo está ali porque era realmente necessário ou se é só um enfeite brilhante
Não sei se as pessoas fazem por interesse, porque gostam de tecnologia, ou se, como você disse, estão aprimorando tecnocraticamente as habilidades para colocar k8s no currículo
Eu só penso: “isso parece doloroso de administrar”
Por isso, acho melhor que infraestrutura k8s seja projetada e trabalhada por um grupo mais restrito de pessoas realmente experientes, ou pelo menos por pessoas experientes que conduzam os mentorados
E, quando não for necessário — ou seja, na maioria das startups, pequenas empresas e empresas de porte comum — é melhor manter os paradigmas existentes mais fáceis de usar
Eles ficaram muito satisfeitos com a escolha e escreveram bastante sobre isso no blog
Foi um caso em que “fica muito mais fácil se tivermos muitos clientes” realmente se confirmou
É uma discussão velha e frequentemente cansativa, mas vou deixar meus dois centavos mesmo assim.
Se é preciso escolher um framework complexo desde o primeiro dia, provavelmente não, a menos que a equipe já tenha bastante experiência com ele.
Mas o que eu contesto é a ideia de que gerenciar infraestrutura com processos sob medida e ferramentas customizadas sempre vai exigir menos esforço de manutenção do que usar ferramentas comprovadas.
É a postura de rejeitar teimosamente o espantalho da “complexidade”, mesmo quando o processo feito em casa não é nem um pouco simples e rouba muito tempo do produto principal.
Todo mundo gosta da simplicidade de copiar um binário para um VPS e reiniciar o serviço.
Mas logo você passa a precisar de configuração e gerenciamento de segredos; quando há vários servidores por disponibilidade e redundância, precisa de deploy gradual, balanceamento de carga, rollback etc.
Você também vai querer um ambiente de staging, e precisa conseguir replicar esse workflow com facilidade.
Quando a equipe cresce, também fica claro que não dá para rodar localmente um ambiente parecido com produção.
E assim os requisitos continuam sendo adicionados.
No fim, para cada novo requisito, em vez de se apoiar em uma solução padrão que outros já resolveram, você precisa resolver do seu próprio jeito especial.
Mais tarde, isso vira um problema de custo afundado.
Você vai abandonar ferramentas customizadas que conhece e entende para migrar para uma “complexidade” desconhecida?
Quanto mais investe, mais difícil fica migrar depois.
Minha sugestão é seguir desde o começo práticas que facilitem a transição futura para ferramentas padrão.
Ou seja, fazer deploy com contêineres desde o dia 1 e adotar a metodologia dos 12 fatores.
E, quando você começar a sofrer por causa de recursos necessários, é melhor migrar para uma ferramenta comprovada mais cedo do que tarde.
É bem provável que você descubra que o medo do desconhecido era infundado, e, no longo prazo, vai gastar menos tempo com infraestrutura.
Uma abordagem que considerei é começar desde o primeiro dia com ferramentas padrão, isto é, k8s + gitops, mas ainda rodando em uma única VM.
O que você acha?
Por outro lado, dá para encontrar muitos “engenheiros de cloud” que entendem esses sistemas de nuvem “complexos” e conseguem fazer deploy e manutenção com terraform.
É um conjunto de habilidades que já entra produzindo.
VM, armazenamento de bloco/blob, DNS, IdP, registrador de domínio.
Isso é basicamente tudo que já usei confortavelmente na nuvem.
Quando entro em FaaS e seus amigos, fica realmente estranho para mim.
Tenho dificuldade em aceitar que não posso inspecionar a máquina onde o ambiente de produção está rodando.
A experiência de depurar pelo dashboard da nuvem é péssima.
Acho que a abordagem da Microsoft é a que mais se aproxima de algo que de fato “funciona”, mas ainda assim é horrível, e não quero mexer com isso nunca mais.
Mesmo 10 anos depois, minha arquitetura ideal ainda é uma única VM com uma base de código monolítica se comunicando com instâncias locais de SQLite.
O surgimento do armazenamento NVMe deu bastante força a essa abordagem.
Backups são feitos com snapshots de dispositivos de bloco, e a durabilidade transacional, quando necessária, é tratada com replicação de WAL.
É simples a ponto de ser idiota.
Permite focar no negócio e nos clientes.
Os clientes não se importam nem um pouco com isso e não vão pagar por isso.
Todo código e toda infraestrutura são fatores puramente negativos, então é preciso ter o mínimo possível.
Quando as pessoas dizem que cloud é mais cara que on-premises, muitas vezes é por causa disso.
Se você vai manter uma VM rodando 24 horas por dia, há opções melhores.
Até livros sobre microsserviços dizem para criar primeiro um monólito.
Antes de obter reação de usuários reais, você não sabe como dividir o sistema, e é mais fácil quebrar um monólito em partes do que reorganizar serviços.
Talvez você nunca precise dividir o monólito.
A Stripe acabou extraindo partes do monólito em Rails, mas o monólito foi surpreendentemente longe.
É difícil ficar mais fácil de depurar do que um monólito em Django/Rails.
Ainda assim, ajuda ter alguma visão de para onde a infraestrutura pode ir.
A versão inicial da nossa empresa foi feita como um contêiner Docker de Django em uma única VM, com deploy manual via
docker pull; docker stop; docker start.Essa configuração aguentou por mais tempo do que eu esperava.
Docker é uma boa forma de contornar problemas de empacotamento de dependências.
No começo, coisas como saber se o servidor tem os headers C necessários quando você instala um novo driver de DB, ou se a configuração difere do Mac, podem ser irritantes.
Depois da nossa rodada de extensão de seed, migramos para k8s por necessidades de negócio ligadas a confiabilidade e escalabilidade, e k8s aguentou bem até a Série B.
Ter tudo dockerizado facilitou a transição, mas, na fase inicial, reduzimos a complexidade de forma agressiva.
E é preciso usar o framework direito, em vez de recriar versões capengas dos recursos que ele já oferece.
Nesse aspecto, uma pessoa experiente entrega resultados melhores do que 10 inexperientes.
Com o tempo, a diferença se acumula.
Acho que metade do verdadeiro motivo de as pessoas se cansarem de monólitos é por causa de monólitos ruins e mal operados.
Dizem que os dados devem ficar em seu próprio serviço e que, se for necessária uma abordagem multiparadigma, como relacional e busca textual, isso pode virar vários serviços.
A experiência do usuário também deve usar seu próprio serviço.
No mínimo, deve haver outro serviço entre eles, e normalmente Django e Rails entram aí.
Opcionalmente, dizem que serviços adicionais, como autenticação e transações financeiras, também podem ser necessários.
Operei um projeto por cerca de 6 anos em um único VPS de 10 dólares por mês.
Na prática, pagava ainda menos por causa de um desconto permanente que consegui no lowendtalk, e era um provedor de VPS focado em servidores de jogos.
Exceto por uma vez em que ficou fora o dia inteiro porque eu estraguei a configuração e precisei reinstalar um SO limpo, e outra vez em que o provedor mudou o endereço IP com aviso prévio, a estabilidade foi quase de nível 99,999.
A tecnologia de VPS evoluiu muito e é extremamente estável.
Os discos dos nós são configurados em RAID 1, e, durante manutenção do nó, a própria VM também pode ser facilmente migrada ao vivo para outra máquina.
Também dá para tirar snapshots.
Para mim, eu escolheria infraestrutura de cloud não por maior estabilidade, mas por recursos de colaboração e gestão operacional como IAM, gerenciamento de segredos e infraestrutura como código, ou por motivos de conformidade de data center, como HIPAA.
Depende da situação
Pessoalmente, gosto de soluções baseadas em nuvem porque economizam muito tempo
Mas é preciso escolher com muito critério o que usar, e há soluções que são tão complexas que claramente acabam tendo o efeito contrário
Eu toco uma pequena startup bootstrap
Não temos dinheiro suficiente nem para nos pagar salários, e eu me sustento fazendo consultoria como trabalho paralelo
Com orçamento e tempo tão limitados, precisamos ser muito cuidadosos sobre o que usar
Por isso gosto de coisas como o Google Cloud
Nossa conta do GCP é bem baixa, algumas centenas de euros por mês
Poderíamos migrar para um provedor mais barato, mas é difícil justificar o investimento de tempo, e também gosto da UI e das ferramentas do Google em comparação com a AWS que usei no passado
Kubernetes não tem utilidade para nós
Só o custo de manter um cluster vazio provavelmente seria maior do que nossa conta mensal atual do GCP
Também não precisamos disso porque não caímos na armadilha dos microsserviços
Mas gosto de Docker
Ele torna a implantação de software ridiculamente fácil
Nosso site é um bucket do Google Storage servido por meio de um balanceador de carga e do Google CDN
O mesmo balanceador de carga roteia chamadas REST para duas VMs que executam nosso monólito
Essas VMs conversam com um DB gerenciado, um Elasticsearch gerenciado e um Redis gerenciado
O DB e o Elasticsearch são caros, mas usá-los como serviços gerenciados economiza muito tempo e esforço
Isso é praticamente tudo o que temos, e é simples e nem tão caro
Se migrássemos tudo para algum lugar como a Hetzner, provavelmente poderíamos reduzir os custos em uns 50%
Pode até valer a pena tentar, mas para mim não é algo superurgente
Perder esses serviços gerenciados tornaria minha vida mais difícil
Alguns clientes parecem preferir AWS, então talvez um dia tenhamos que voltar para a AWS, e esse ponto também pesa