Isso soa como a hist\u00f3ria da computa\u00e7\u00e3o em nuvem e a ado\u00e7\u00e3o de software cloud native, mas na verdade \u00e9 de mais de um s\u00e9culo antes. <\/p>\n\n\n\n
Como Tim Hartford explicou em “50 coisas que fizeram a economia moderna”, levou mais de 50 anos para as empresas come\u00e7arem a construir seus neg\u00f3cios em torno da eletricidade fornecida por um fornecedor de energia central em vez de instalar seus pr\u00f3prios equipamentos \u00e0 base de vapor. <\/p>\n\n\n\n
Assim como ter seu pr\u00f3prio data center, administrar sua pr\u00f3pria usina de vapor era caro, mas parecia mais confi\u00e1vel quando a eletricidade era nova. No entanto, \u00e0 medida que a tecnologia de eletricidade melhorou, n\u00e3o era mais econ\u00f4mico contar com vapor e os trabalhadores necess\u00e1rios para manter essa infraestrutura eram mais dif\u00edceis de encontrar.<\/p>\n\n\n\n
Isso deve soar familiar para quem tenta contratar profissionais de TI qualificados.<\/p>\n\n\n\n
As dificuldades do mercado<\/h3>\n\n\n\n
Assim como \u00e9 dif\u00edcil justificar a constru\u00e7\u00e3o de sua pr\u00f3pria usina, \u00e9 dif\u00edcil competir com a escala dos principais provedores de nuvem. Confiar em seus servi\u00e7os significa que seu pessoal de opera\u00e7\u00f5es pode se concentrar <\/strong>nos problemas que s\u00e3o exclusivos de sua empresa. <\/strong><\/p>\n\n\n\n N\u00e3o h\u00e1 vantagem competitiva em armazenar servidores individuais em rack, trocar discos r\u00edgidos ou verificar se h\u00e1 cabos Ethernet quebrados.<\/p>\n\n\n\n Depois de 100 anos, ningu\u00e9m fala em ser “nativo el\u00e9trico”. Usar eletricidade \u00e9 simplesmente como o trabalho \u00e9 feito. <\/p>\n\n\n E 15 anos ap\u00f3s o lan\u00e7amento do primeiro servi\u00e7o da<\/mark> <\/strong>AWS<\/strong><\/a>, a maioria das empresas iniciou sua migra\u00e7\u00e3o para a nuvem ou est\u00e1 considerando seriamente como come\u00e7ar. E para muitas empresas, a migra\u00e7\u00e3o para a nuvem come\u00e7a com uma replica\u00e7\u00e3o <\/mark><\/strong>do ambiente hospedado. <\/strong><\/p>\n\n\n\n Isso costuma ser chamado de abordagem “lift and shift”, em que o software<\/strong><\/a> em alguns servidores \u00e9 copiado em imagens de m\u00e1quina e implantado como servidores virtuais em uma conta usando o EC2 da AWS, as m\u00e1quinas virtuais do Azure ou o Compute Engine<\/strong><\/a> do Google.\u00a0<\/p>\n\n\n\n Assim como os servidores de um data center s\u00e3o protegidos por firewall do mundo externo, as regras de rede s\u00e3o configuradas para garantir que apenas os servidores virtuais voltados para o cliente sejam acess\u00edveis externamente. <\/p>\n\n\n\n Quando chegar a hora de atualizar seu software, voc\u00ea ter\u00e1 algum tempo de inatividade, pois o software em seu servidor virtual \u00e9 desligado, atualizado e reiniciado.<\/p>\n\n\n\n Se sua experi\u00eancia na nuvem parar por aqui, voc\u00ea se perguntar\u00e1 sobre o motivo de tanta confus\u00e3o. Pode haver alguma economia de custos, e certamente \u00e9 mais r\u00e1pido ativar uma inst\u00e2ncia do EC2 do que solicitar e instalar um novo servidor f\u00edsico, mas o trabalho real do dia a dia de seus desenvolvedores e equipes de opera\u00e7\u00f5es n\u00e3o muda muito. <\/p>\n\n\n\n Isso ocorre porque voc\u00ea n\u00e3o adaptou suas ferramentas e processos para aproveitar o que a nuvem oferece. Resumindo, seu software ainda n\u00e3o \u00e9 cloud native<\/mark>.<\/strong><\/p>\n\n\n Mas, o que \u00e9 realmente “cloud native”? O que isso significa? A Cloud Native Computing Foundation, ou CNCF, foi criada como um desdobramento da Linux Foundation para “tornar a computa\u00e7\u00e3o nativa em nuvem onipresente”<\/mark><\/strong>. <\/p>\n\n\n\n Eles pastoreiam muitos dos projetos que permitem software nativo de nuvem multiplataforma e elaboraram uma defini\u00e7\u00e3o<\/mark> <\/strong>do que significa:<\/strong> <\/p>\n\n\n\n As tecnologias nativas da nuvem capacitam as organiza\u00e7\u00f5es a criar e executar aplicativos escal\u00e1veis \u200b\u200bem ambientes modernos e din\u00e2micos, como nuvens p\u00fablicas, privadas e h\u00edbridas. Cont\u00eaineres, malhas de servi\u00e7o, microsservi\u00e7os, infraestrutura imut\u00e1vel e APIs declarativas exemplificam essa abordagem.<\/em><\/p>\n\n\n\n Essas t\u00e9cnicas permitem sistemas fracamente acoplados que s\u00e3o resilientes, gerenci\u00e1veis \u200b\u200be observ\u00e1veis. Combinados com automa\u00e7\u00e3o robusta, eles permitem que os engenheiros fa\u00e7am altera\u00e7\u00f5es de alto impacto com frequ\u00eancia e previsibilidade com o m\u00ednimo de trabalho.<\/p>\n\n\n\n Vamos passar pelas palavras mais importantes, dar uma olhada no que elas significam e, em seguida, percorrer as ferramentas das plataformas nativas da nuvem que nos permitem construir sistemas nativos da nuvem.<\/p>\n\n\n\n Vamos come\u00e7ar com escal\u00e1vel. A escalabilidade \u00e9 um dos principais motivadores para migrar para a nuvem. Mas a maior desvantagem de executar seu pr\u00f3prio data center \u00e9 que leva muito tempo para adquirir e configurar um novo hardware.<\/p>\n\n\n\n Isso significa que voc\u00ea precisa reservar servidores com base em uma estimativa de quanta capacidade ser\u00e1 necess\u00e1ria no dia mais movimentado. Se a sua empresa tem uma temporada movimentada<\/mark><\/strong>, voc\u00ea tem excesso de capacidade<\/mark> <\/strong>na maior parte do ano. Pior ainda, se voc\u00ea subestimar a demanda, seu sistema n\u00e3o funcionar\u00e1 quando voc\u00ea mais precisar.<\/p>\n\n\n\n Tornar seus servi\u00e7os escal\u00e1veis \u200b\u200bprovavelmente exigir\u00e1 que seus desenvolvedores fa\u00e7am altera\u00e7\u00f5es em seus softwares<\/mark>.<\/strong> Isso pode ser complicado, porque geralmente significa repensar como seus aplicativos s\u00e3o arquitetados. No entanto, a recompensa vale a pena.<\/p>\n\n\n\n A primeira etapa \u00e9 dividir um aplicativo monol\u00edtico em microsservi\u00e7os. Embora voc\u00ea possa executar um mon\u00f3lito na nuvem, n\u00e3o pode aumentar os recursos para uma \u00fanica parte de um mon\u00f3lito; \u00e9 tudo ou nada. <\/p>\n\n\n\n Al\u00e9m disso, com os microsservi\u00e7os<\/a><\/strong>, voc\u00ea pode dimensionar diferentes \u00e1reas funcionais do seu aplicativo em taxas diferentes, dependendo do que elas precisam.<\/p>\n\n\n\n Depois de pensar em termos de microsservi\u00e7os, o pr\u00f3ximo passo \u00e9 pensar em colocar esses microsservi\u00e7os<\/mark> <\/strong>em cont\u00eaineres. O Docker popularizou a ideia de empacotar software em pacotes imut\u00e1veis \u200b\u200be execut\u00e1-los isoladamente, sem exigir um sistema operacional completo por servi\u00e7o. <\/p>\n\n\n\n Essa diferen\u00e7a entre cont\u00eaineres e m\u00e1quinas virtuais permite que voc\u00ea execute muito mais cont\u00eaineres no mesmo hardware subjacente do que com VMs.<\/p>\n\n\n\n N\u00e3o h\u00e1 nada sobre microsservi\u00e7os ou cont\u00eaineres que impe\u00e7a voc\u00ea de implant\u00e1-los em um data center. Portanto, o problema \u00e9 que voc\u00ea ainda precisa alocar e gerenciar os servidores subjacentes que os hospedam. <\/p>\n\n\n\n Um Microsservi\u00e7o Cloud Native aproveita os servi\u00e7os de um provedor de nuvem. Assim como a execu\u00e7\u00e3o na nuvem significa que <\/strong>voc\u00ea n\u00e3o precisa mais se preocupar com o estado das placas de rede<\/mark> <\/strong>e dos ventiladores <\/mark><\/strong>do seu servidor, uma arquitetura nativa da nuvem<\/strong><\/a> significa que voc\u00ea pode evitar se preocupar com a aloca\u00e7\u00e3o de servidores virtuais.<\/p>\n\n\n\n Os Microsservi\u00e7os Cloud Native seguem determinados princ\u00edpios de design. O mais importante \u00e9 que eles s\u00e3o projetados como uma infraestrutura imut\u00e1vel.<\/p>\n\n\n\n <\/p>\n\n\n\n Isso leva \u00e0 pergunta: como voc\u00ea faz atualiza\u00e7\u00f5es? A resposta \u00e9 que em uma Arquitetura Cloud Native, sempre que voc\u00ea quiser alterar um microsservi\u00e7o nativo da nuvem, voc\u00ea inicia uma nova inst\u00e2ncia com as atualiza\u00e7\u00f5es e desativa a inst\u00e2ncia antiga.<\/p>\n\n\n\n Isso contrasta com a abordagem mais antiga de fazer atualiza\u00e7\u00f5es em um \u00fanico servidor.<\/p>\n\n\n\n Depois de criar essas inst\u00e2ncias imut\u00e1veis, voc\u00ea estar\u00e1 no caminho certo para criar uma Arquitetura Cloud Native. <\/p>\n\n\n\n Suas equipes agora podem aproveitar os servi\u00e7os de provedores de nuvem para aumentar a escalabilidade de seus sistemas. Ou seja, quando nenhuma inst\u00e2ncia de servidor \u00e9 especial, voc\u00ea pode usar servi\u00e7os do provedor de nuvem para dimensionar automaticamente ou configurar seu ambiente para adicionar e remover automaticamente inst\u00e2ncias de servidor virtual \u00e0 medida que a carga em seu sistema muda.<\/p>\n\n\n\n Dividir seus servi\u00e7os em componentes menores pode levar a mais benef\u00edcios de escalabilidade. Em alguns casos, voc\u00ea pode reduzir ainda mais um microsservi\u00e7o nativo da nuvem, para apenas uma \u00fanica fun\u00e7\u00e3o.<\/p>\n\n\n\n A AWS os chama de Lambdas<\/strong><\/a>, o Google de Cloud Functions e o Azure simplesmente de Functions. Eles s\u00e3o ainda mais simples de empacotar do que um cont\u00eainer, geralmente apenas um arquivo zip contendo algum c\u00f3digo. Sua equipe de opera\u00e7\u00f5es precisa apenas configurar o n\u00famero m\u00e1ximo de fun\u00e7\u00f5es a serem executadas simultaneamente e quanta mem\u00f3ria fornecer a cada uma. <\/p>\n\n\n\n O provedor de nuvem se encarrega de alocar as m\u00e1quinas subjacentes, dimensionando-as para cima e para baixo (e at\u00e9 mesmo desativando-as) automaticamente. Para processos ou servi\u00e7os infrequentes que t\u00eam rajadas de solicita\u00e7\u00f5es, por exemplo, essas fun\u00e7\u00f5es geralmente s\u00e3o muito mais econ\u00f4micas do que um cont\u00eainer que \u00e9 executado o tempo todo.<\/p>\n\n\n\n As vantagens das Arquiteturas Nativas da nuvem v\u00e3o muito al\u00e9m da capacidade de dimensionar a l\u00f3gica de neg\u00f3cios do seu aplicativo. <\/p>\n\n\n\n E quando voc\u00ea tem uma infraestrutura imut\u00e1vel e sem estado, seus dados ainda precisam estar em algum lugar. Embora voc\u00ea possa executar bancos de dados de terceiros em servidores virtuais, uma arquitetura nativa de nuvem usa bancos de dados hospedados pelos pr\u00f3prios provedores de nuvem. <\/p>\n\n\n\n MySQL, Postgres e Oracle est\u00e3o dispon\u00edveis em todos os tr\u00eas maiores provedores de nuvem, mas apenas o Azure possui uma vers\u00e3o hospedada do Microsoft SQL Server. Como os bancos de dados hospedados s\u00e3o gerenciados pelo seu provedor de nuvem, \u00e9 f\u00e1cil alocar recursos adicionais conforme necess\u00e1rio, como disco, mem\u00f3ria e CPU, dimensionando ao longo do tempo conforme suas necessidades mudam.<\/p>\n\n\n\n Voc\u00ea tamb\u00e9m pode come\u00e7ar a procurar outras maneiras n\u00e3o relacionais de armazenar seus dados. Um dos <\/strong>primeiros servi\u00e7os da AWS <\/strong>foi o S3<\/strong><\/a>. <\/p>\n\n\n\n Ele <\/strong>permite que voc\u00ea coloque <\/strong>arquivos em “buckets”<\/strong> <\/mark>(Azure chama sua vers\u00e3o desse servi\u00e7o de Blob Storage e o Google o chama de Cloud Storage). Existem bancos de dados de documentos, noSQL, bancos de dados de gr\u00e1ficos, data warehouses e at\u00e9 blockchains privados. Em outras palavras, ter esses armazenamentos de dados alternativos dispon\u00edveis apenas com uma API \u00e9 poderoso. <\/p>\n\n\n\n Suas equipes s\u00e3o capazes de descobrir se existem solu\u00e7\u00f5es melhores de maneira muito mais r\u00e1pida e barata do que em um ambiente auto gerenciado.<\/p>\n\n\n\n \u00c0 medida que suas equipes se sentirem mais \u00e0 vontade, elas explorar\u00e3o mais maneiras de se concentrar nas principais compet\u00eancias da sua empresa. Por exemplo, considere a identidade do cliente. Em vez de gerenciar essas informa\u00e7\u00f5es por conta pr\u00f3pria,<\/mark> <\/strong>os provedores de nuvem (assim como empresas terceirizadas) t\u00eam solu\u00e7\u00f5es<\/mark> <\/strong>de gerenciamento de identidade usando padr\u00f5es como OAuth2 <\/mark><\/strong>e OIDC<\/mark>. <\/strong><\/p>\n\n\n\n Existem solu\u00e7\u00f5es semelhantes, como aprendizado de m\u00e1quina ou processamento em lote. As arquiteturas nativas da nuvem n\u00e3o apenas dimensionam seu software,<\/mark> <\/strong>mas tamb\u00e9m dimensionam os recursos<\/mark> <\/strong>de sua equipe, permitindo que voc\u00ea se concentre no que faz de melhor.<\/p>\n\n\n Outra parte importante de uma arquitetura nativa da nuvem \u00e9 que ela \u00e9 resiliente<\/mark><\/strong>. O que isto significa? Como<\/em><\/strong> <\/mark>Matthew Titmus explica em “Cloud Native Go”:<\/p>\n\n\n\n \u201cResili\u00eancia (aproximadamente sin\u00f4nimo de toler\u00e2ncia a falhas) \u00e9 uma medida de qu\u00e3o bem um sistema resiste e se recupera de erros e falhas. Um sistema pode ser considerado resiliente se puder continuar operando corretamente\u2014possivelmente em um n\u00edvel reduzido\u2014em vez de falhar completamente quando alguma parte do sistema falhar.\u201d<\/em><\/p>\n<\/blockquote>\n\n\n\n Assim como voc\u00ea precisa modificar seu software para torn\u00e1-lo mais escal\u00e1vel, voc\u00ea precisar\u00e1 fazer altera\u00e7\u00f5es para torn\u00e1-lo mais resiliente. Assim como a escalabilidade<\/a><\/strong>, h\u00e1 recompensas tremendas<\/mark> <\/strong>quando voc\u00ea torna seus sistemas mais resilientes, porque eles continuam funcionando e as equipes n\u00e3o est\u00e3o se esfor\u00e7ando para corrigir problemas.<\/p>\n\n\n\n Existem muitos recursos que discutem t\u00e9cnicas que tornam os servi\u00e7os mais resilientes. (Se est\u00e3o escrevendo software nativo da nuvem em Go, sem surpresa, uma leitura obrigat\u00f3ria.) <\/p>\n\n\n\n Esses padr\u00f5es se concentram em como os dados fluem pelos seus servi\u00e7os. Para dados que chegam a um servi\u00e7o, voc\u00ea precisa limitar a quantidade de dados ao que pode ser processado em um tempo razo\u00e1vel. <\/p>\n\n\n\n Se entrar muito, a carga precisa ser descartada para responder \u00e0s solicita\u00e7\u00f5es restantes em um per\u00edodo de tempo razo\u00e1vel. Quando seu servi\u00e7o est\u00e1 solicitando dados de outro servi\u00e7o, ele deve ser escrito para lidar com erros inevit\u00e1veis \u200b\u200be os tempos limite que ocorrer\u00e3o.<\/p>\n\n\n\n Os provedores de nuvem tamb\u00e9m fornecem algumas ferramentas para ajudar na resili\u00eancia. H\u00e1 sobreposi\u00e7\u00e3o com escalabilidade. Ou seja, se um microsservi\u00e7o falhar devido a um erro raro, um autoescalador poder\u00e1 iniciar uma nova c\u00f3pia. <\/p>\n\n\n\n O escalonamento autom\u00e1tico tamb\u00e9m permite que seus sistemas absorvam a carga em vez de elimin\u00e1-la.<\/strong><\/em> Ao usar bancos de dados ou plataformas de processamento de dados gerenciados, pode aumentar rapidamente seus recursos se precisarem de mais CPU ou armazenamento.<\/p>\n\n\n\n Os provedores de nuvem tamb\u00e9m permitem aumentar a resili\u00eancia espalhando seus servi\u00e7os entre regi\u00f5es. Uma regi\u00e3o \u00e9 uma \u00e1rea geogr\u00e1fica com um ou mais data centers, como a Costa Leste dos Estados Unidos ou S\u00e3o Paulo, Brasil. Dentro de uma regi\u00e3o, cada data center \u00e9 atribu\u00eddo a uma das v\u00e1rias zonas de disponibilidade.<\/p>\n\n\n\n Para garantir que uma falha <\/em><\/strong>n\u00e3o cause uma interrup\u00e7\u00e3o, \u00e9 recomend\u00e1vel iniciar servi\u00e7os em v\u00e1rias zonas de disponibilidade. Seguir os princ\u00edpios de apatridia e tratar seus servidores como gado significa que seu sistema continuar\u00e1 funcionando mesmo que uma \u00fanica zona ou regi\u00e3o de disponibilidade fique inativa. <\/p>\n\n\n\n Se usar um armazenamento de dados de um provedor de nuvem, ele poder\u00e1 replicar dados automaticamente em zonas de disponibilidade e at\u00e9 mesmo regi\u00f5es.<\/p>\n\n\n Outro aspecto importante da computa\u00e7\u00e3o nativa em nuvem \u00e9 que ela \u00e9 gerenci\u00e1vel<\/mark><\/strong>.<\/p>\n\n\n\n Todos esses componentes podem ser visualizados a partir de uma interface do usu\u00e1rio ou ter seu status consultado por meio de uma API. Ter uma API para descobrir e modificar o estado do seu ambiente significa que voc\u00ea pode escrever ferramentas para esse trabalho de maneira repet\u00edvel. Isso tamb\u00e9m significa que voc\u00ea pode descrever o ambiente em um script e executar esse script para implantar, atualizar ou excluir seus componentes. A AWS <\/strong>fornece uma ferramenta chamada CloudFormation<\/mark> <\/strong>para fazer isso. <\/strong><\/p>\n\n\n Intimamente relacionado \u00e0 capacidade de gerenciamento est\u00e1 a observabilidade<\/a><\/strong>. Depois de ter v\u00e1rios componentes em execu\u00e7\u00e3o juntos, voc\u00ea deseja entender o que eles est\u00e3o fazendo. <\/p>\n\n\n\n Voc\u00ea tamb\u00e9m quer saber quando algo d\u00e1 errado. Mesmo que seus desenvolvedores projetem para resili\u00eancia, seu pessoal de opera\u00e7\u00f5es ainda precisa saber sobre os problemas assim que eles acontecem para evitar que a situa\u00e7\u00e3o piore. A Amazon fornece um servi\u00e7o chamado <\/strong>CloudWatch<\/strong><\/a> <\/strong>para fornecer<\/mark> <\/strong>essa funcionalidade. <\/p>\n\n\n\n O CloudWatch coleta dados da AWS sobre como seu aplicativo est\u00e1 sendo executado e m\u00e9tricas sobre o desempenho de seus aplicativos. Al\u00e9m disso, os logs do seu aplicativo tamb\u00e9m podem ser enviados para o Cloudwatch, para que voc\u00ea veja as informa\u00e7\u00f5es do seu c\u00f3digo junto com as informa\u00e7\u00f5es capturadas pela AWS.<\/p>\n\n\n\n (O Azure tem um servi\u00e7o semelhante chamado Monitor, que possui um componente chamado Application Insights para capturar a telemetria do aplicativo, enquanto o Google fornece o Cloud Monitoring.)<\/p>\n\n\n\n Al\u00e9m de observar seus sistemas enquanto eles est\u00e3o em execu\u00e7\u00e3o, tamb\u00e9m \u00e9 \u00fatil observar as chamadas de API para seu provedor de nuvem que configuram seu sistema. Essas chamadas podem informar se os sistemas est\u00e3o configurados corretamente e podem detectar atividades maliciosas.<\/p>\n\n\n\n A AWS usa o CloudTrail<\/mark> <\/strong>para relatar chamadas de API,<\/mark><\/strong> o Google possui logs de auditoria de nuvem, enquanto o servi\u00e7o Monitor do Azure rastreia chamadas de API, bem como o desempenho do aplicativo.<\/p>\n\n\n Por fim, voc\u00ea precisa confiar na automa\u00e7\u00e3o para garantir a consist\u00eancia em seu ambiente de nuvem. <\/p>\n\n\n\n A automa\u00e7\u00e3o une todos os nossos princ\u00edpios nativos da nuvem. A escalabilidade \u00e9 poss\u00edvel<\/mark> <\/strong>porque automatizamos a implanta\u00e7\u00e3o <\/mark><\/strong>de infraestrutura imut\u00e1vel. Os sistemas s\u00e3o mais resilientes quando podemos reinici\u00e1-los automaticamente em caso de falha ou quando eles fazem failover <\/em>automaticamente para um sistema de backup quando detectam um problema em uma depend\u00eancia. <\/p>\n\n\n\n As ferramentas de gerenciamento automatizadas permitem que voc\u00ea acompanhe o que est\u00e1 sendo executado, e a automa\u00e7\u00e3o permite que voc\u00ea descubra quando seus sistemas observ\u00e1veis \u200b\u200best\u00e3o se comportando mal.<\/p>\n\n\n\n H\u00e1 mais maneiras de a automa\u00e7\u00e3o habilitar o software nativo da nuvem. Ao lan\u00e7ar novas vers\u00f5es, voc\u00ea n\u00e3o quer que um administrador do sistema instale o software manualmente. Em vez disso, voc\u00ea deve aproveitar os pipelines de implanta\u00e7\u00e3o que automatizam o processo de compila\u00e7\u00e3o, teste e implanta\u00e7\u00e3o, como o CodePipeline da AWS, o Cloud Build do Google ou os Pipelines do Azure. <\/p>\n\n\n\n A automa\u00e7\u00e3o garante consist\u00eancia e permite que voc\u00ea fa\u00e7a coisas como lan\u00e7ar uma nova vers\u00e3o<\/mark> <\/strong>do seu software para um subconjunto limitado<\/mark> <\/strong>de seus servidores para ver se funciona corretamente.<\/p>\n\n\n\n Al\u00e9m de melhorar a experi\u00eancia <\/mark><\/strong>de implanta\u00e7\u00e3o de software nativo da nuvem<\/mark><\/strong>, a automa\u00e7\u00e3o tamb\u00e9m ajuda no gerenciamento do seu ambiente. Voc\u00ea precisa ter certeza de que todos os componentes do seu software est\u00e3o configurados corretamente.<\/p>\n\n\n\n Isso inclui coisas como validar permiss\u00f5es de acesso, garantir que apenas aplicativos voltados para o cliente sejam expostos \u00e0 Internet p\u00fablica ou garantir que todos os seus recursos de nuvem estejam devidamente marcados com informa\u00e7\u00f5es para identificar qual equipe \u00e9 a propriet\u00e1ria. <\/p>\n\n\n\n Voc\u00ea tamb\u00e9m pode implementar medidas de otimiza\u00e7\u00e3o de custos na nuvem, como desligar componentes em um ambiente de controle de qualidade quando os engenheiros estiverem dormindo e lig\u00e1-los novamente quando voltarem ao trabalho.<\/p>\n\n\n Como voc\u00ea viu, o objetivo de criar aplicativos nativos da nuvem n\u00e3o \u00e9 estar atualizado com as \u00faltimas palavras da moda. Depois de seguir esses princ\u00edpios e reprojetar seus aplicativos com uma arquitetura nativa da nuvem, sua empresa pode produzir um software mais confi\u00e1vel que atenda melhor \u00e0s necessidades de suas equipes internas e de seus clientes.<\/p>\n\n\n\n Certamente, para empresas que investem em um data center e tecnologias mais antigas, isso n\u00e3o ser\u00e1 f\u00e1cil. Como Tim Hartford disse em seu artigo sobre a transi\u00e7\u00e3o do vapor para a eletricidade e a ado\u00e7\u00e3o da tecnologia computacional:<\/p>\n\n\n\n \u201cA coisa sobre uma tecnologia revolucion\u00e1ria \u00e9 que ela muda tudo – \u00e9 por isso que a chamamos de revolucion\u00e1ria. E mudar tudo leva tempo, imagina\u00e7\u00e3o e coragem – e \u00e0s vezes muito trabalho duro.\u201d<\/em><\/p>\n<\/blockquote>\n\n\n\n Assim como as empresas h\u00e1 100 anos tiveram que fazer altera\u00e7\u00f5es em sua infraestrutura ao passar do vapor para a eletricidade, tornar-se cloud native significa que seus desenvolvedores e equipes de opera\u00e7\u00f5es precisar\u00e3o fazer altera\u00e7\u00f5es \u00e0 medida que melhoram a escalabilidade, resili\u00eancia, capacidade de manuten\u00e7\u00e3o, observabilidade e automa\u00e7\u00e3o de seu software e seu ambiente. <\/p>\n\n\n\n Requer a altera\u00e7\u00e3o de alguns padr\u00f5es de desenvolvimento e a ado\u00e7\u00e3o de uma arquitetura nativa da nuvem usando as ferramentas dos provedores de nuvem. No entanto, as recompensas s\u00e3o not\u00e1veis. Bem-vindo ao futuro.<\/p>\n\n\n\n Quer continuar se aprofundando no assunto? Inscreva-se na nossa newsletter<\/strong><\/a> para receber em primeira m\u00e3o conte\u00fados de tecnologia. <\/p>\n\n\n\n![\"O](\"https:\/\/uds.com.br\/blog\/wp-content\/uploads\/2022\/07\/traco-ok.png\")
<\/figure><\/div>\n\n\nAWS Cloud Native<\/strong><\/h2>\n\n\n\n
<\/figure><\/div>\n\n\nO que \u00e9 Cloud Native?<\/strong><\/h2>\n\n\n\n
Cloud Native: 5 princ\u00edpios<\/strong><\/h3>\n\n\n\n
\n
<\/figure><\/div>\n\n\n1. Escal\u00e1vel<\/strong><\/h2>\n\n\n\n
O que torna um Microsservi\u00e7o Cloud Native?<\/strong><\/h3>\n\n\n\n
Isso significa duas coisas:<\/h4>\n\n\n\n
\n
Construindo Arquitetura Cloud Native<\/strong><\/h3>\n\n\n\n
Funcionalidade de Dimensionamento com Arquitetura Cloud Native<\/strong><\/h3>\n\n\n\n
Outras maneiras…<\/h4>\n\n\n\n
<\/figure><\/div>\n\n\n2. Resiliente<\/strong><\/h2>\n\n\n\n
\n
Recursos dispon\u00edveis<\/strong><\/h3>\n\n\n\n
<\/figure><\/div>\n\n\n3. Gerenci\u00e1vel<\/strong><\/h2>\n\n\n\n
<\/figure><\/div>\n\n\n4. Observ\u00e1vel<\/strong><\/h2>\n\n\n\n
<\/figure><\/div>\n\n\n5. Automatiz\u00e1vel<\/strong><\/h2>\n\n\n\n
<\/figure><\/div>\n\n\nCloud Native vale a pena? <\/strong><\/h2>\n\n\n\n
\n