5 reptes per anar-hi natiu en núvol i com solucionar-los

Vivim en un món nadiu dels núvols. Amb prou feines podeu llegir un bloc tecnològic o anar a una conferència sense conèixer tots els avantatges de les tecnologies o arquitectures natives del núvol, com ara contenidors, microserveis i funcions sense servidor.

Tot i així, enmig de tota la il·lusió de sortir al núvol del núvol, pot ser fàcil passar els reptes que es plantegen quan migreu d’aplicacions monolítiques heretades cap a una estratègia autòctona del núvol. Aquests reptes es poden superar, però només si els abordeu com a part de la vostra estratègia de migració originària del núvol.

Amb aquesta finalitat, analitzem cinc dels reptes més habituals dels núvols i les estratègies per superar-los.

Què és natiu al núvol?

Tanmateix, primer, una paraula sobre el que significa en realitat el cloud native.

Amb la idea del "núvol" de totes les coses, de vegades la gent utilitza "native cloud" per significar qualsevol tipus de tecnologia o estratègia que consideren moderna. Des d'aquesta perspectiva, native-cloud acaba sent una altra paraula de paraules relativament sense sentit.

D’altra banda, quan s’inverteix amb un significat específic i limitat, el cloud native és un terme i concepte útils. Ens agrada la definició del CNCF, que destaca “sistemes acoblats de manera fluïda” i la resiliència com a característiques de la informàtica nativa en núvol. La definició de CNCF també apunta a una llista específica i limitada de tecnologies i arquitectures ("contenidors, malles de servei, microserveis, infraestructures immutables i API declaratives") com a exemples de tecnologies natives al núvol.

Als efectes d’aquest article, ens adherim a la definició de CNCF de cloud native. Ara, comentem els reptes específics que sorgeixen quan utilitzeu tecnologies i estratègies com les descrites anteriorment.

Reptes per a l'adopció de Native Cloud

1) Emmagatzematge de dades persistents

Un dels desafiaments més comuns amb moltes tecnologies natives del núvol és emmagatzemar dades de forma permanent. Els contenidors, les funcions sense servidor i les aplicacions desplegades amb un model d’infraestructura immutable no solen tenir una forma d’emmagatzemar dades de manera permanent dins d’elles mateixes perquè totes les dades internes es destrueixen quan l’aplicació s’apaga.

Per solucionar aquest repte cal repensar els enfocaments de l’emmagatzematge de dades desconnectant-lo d’aplicacions i entorns host. En lloc d’emmagatzemar dades dins de l’entorn de l’aplicació, els fluxos de treball originaris del núvol s’emmagatzemen externament i exposen les dades com a servei. A continuació, les càrregues de treball que necessiten accedir a les dades, es connecten a ella de la mateixa manera que es connectarien a qualsevol altre servei.

Aquest enfocament, que està habilitat per diverses eines, com els volums a Kubernetes, té dos avantatges. A més d’habilitar l’emmagatzematge de dades persistent per a aplicacions que no estan dissenyades per si mateixes de manera persistent, també facilita la compartició d’un conjunt d’emmagatzematge únic entre diverses aplicacions o serveis.

2) Integració del servei

Les aplicacions natives del núvol es componen generalment d'un conjunt de serveis diferents. Aquesta naturalesa distribuïda és el que ajuda a fer-los escalables i flexibles, en comparació amb els monòlits.

Però també significa que les càrregues de treball natives del núvol tenen moltes més peces mòbils que han de connectar-se perfectament per obtenir èxit.

En part, la integració del servei és un problema perquè els desenvolupadors s’aborden a mesura que creen aplicacions natives del núvol. Han d’assegurar-se que cada servei té una mida adequada; una millor pràctica és crear un servei diferent per a cada tipus de funcionalitat dins d’una càrrega de treball, en lloc d’intentar que un servei únic faci diverses coses. També és important evitar afegir serveis només perquè pugueu. Abans d’introduir més complexitat a l’aplicació en forma d’un altre servei, assegureu-vos que el servei avança un objectiu concret.

Més enllà de l'arquitectura de l'aplicació mateixa, una integració efectiva del servei també depèn de triar les tècniques de desplegament adequades. Els contenidors són probablement la forma més òbvia de desplegar diversos serveis i unificar-los en una sola càrrega de treball, però en alguns casos, les funcions sense servidor o aplicacions no contenedores connectades per API, poden ser mètodes millors de desplegament de serveis.

3) Gestió i seguiment

Com més serveis tingueu executant com a part d'una aplicació, més serà més difícil controlar-los i gestionar-los. Això és cert, no només a causa del gran nombre de serveis que heu de rastrejar, sinó també perquè garantir la salut de l’aplicació requereix un control de relacions entre els serveis, no només dels serveis.

Supervisar i gestionar els serveis en un entorn natiu en núvol, doncs, requereix un enfocament que pugui predir com un fracàs en un servei afectarà a altres, així com comprendre quins errors són més crítics. També és fonamental la línia de base dinàmica, que significa substituir els llindars estàtics per uns que avaluen contínuament els entorns d'aplicacions per determinar què és normal i què és una anomalia.

4) Evitar el bloqueig en núvol

Els riscos de bloqueig no són exclusius del núvol; poden sorgir de gairebé qualsevol tipus de tecnologia i han estat una amenaça per a l’agilitat durant dècades. Tanmateix, en el cas d’aplicacions o arquitectures natives del núvol, l’amenaça de dependre massa d’un determinat proveïdor o servei en núvol en particular pot ser especialment gran, a causa de la facilitat amb la qual es poden desplegar les càrregues de treball de manera que requereixin una determinada servei des d’un núvol concret.

Afortunadament, mitigar aquest risc de bloqueig en el núvol és bastant fàcil sempre que planegeu. Seguir els estàndards basats en comunitats (com els promocionats per OCCI) farà molt per garantir que pugueu moure les vostres càrregues de treball fàcilment d’un núvol a un altre. De la mateixa manera, a mesura que planifiqueu quins serveis al núvol fareu servir per ser originaris del núvol, tingueu en compte si algun dels serveis que considereu té funcions realment úniques i no disponibles d'altres núvols. Si ho fan, eviteu aquestes funcions, perquè poden bloquejar-vos.

Per exemple, els llenguatges i els marcs específics suportats per les plataformes informàtiques sense servidor de diversos núvols públics varien una mica. AWS Lambda admet Go, per exemple, però Azure no. Per això, us convindria evitar escriure les funcions sense servidor a Go. Fins i tot si teniu previst utilitzar AWS per allotjar-los inicialment, aquesta dependència dificultaria la migració en un núvol diferent en el futur. S'adhereix amb un idioma com Java, que puguis apostar de forma segura.

5) Construint aplicacions de pipelines de lliurament natives al núvol

Per definició, les aplicacions natives del núvol s'executen al núvol. Si bé el núvol podria ser un núvol públic, o un núvol privat, on-prem o hibridat en un entorn híbrid als entorns de la vostra organització, això significa una infraestructura immutable i processos de gestió del núvol. Però molts canals d’entrega d’aplicacions encara funcionen en gran mesura en entorns locals tradicionals que potser no s’havien tingut ennuvolats o estan molestos quan s’integren amb les aplicacions i serveis que s’executen en núvols públics o en contenidors.

Això crea un repte en diversos aspectes. Una d’elles és que desplegar codi d’un entorn local a un local pot introduir retards. Un altre és que desenvolupar i provar localment fa més difícil emular condicions de producció, cosa que pot comportar un comportament inesperat de l'aplicació, després del desplegament.

La manera més eficaç de superar aquests obstacles és traslladar el vostre pipeline CI / CD a un entorn de núvols, no només per beneficiar-vos d’infraestructures immutables i d’escalabilitat i d’altres avantatges del núvol, sinó també per imitar les condicions de producció i apropar el pipeline - tant. com sigui possible - a les vostres aplicacions. D’aquesta manera, el codi s’escriu més a prop d’on es desplega, fent que el desplegament sigui més ràpid. També és més fàcil generar entorns de prova idèntics als de producció.

Tot i que el desenvolupament completament basat en núvols no és per a tothom i alguns desenvolupadors prefereixen la familiaritat i la capacitat de resposta dels IDE locals que els basats en núvols, procureu que les pipelines CI / CD funcionin en un entorn núvol, en la mesura del possible.

Conclusió

No importa la forma de girar-lo, és difícil anar amb núvols. En comparació amb les aplicacions antigues, les aplicacions natives del núvol són més complexes i tenen molts més llocs on les coses poden funcionar malament. Dit això, es poden superar els reptes de computació autòctona en núvol i implementar estratègies que puguin afrontar els reptes és clau per desbloquejar l’agilitat, la fiabilitat i l’escalabilitat que només poden oferir les arquitectures natives del núvol.