Questi non sono i contenitori che stai cercando



<div _ngcontent-c14 = "" innerhtml = "

In un messaggio precedente, Ho sostenuto che nel caso di Kubernetes, l'hype potrebbe essere in anticipo rispetto all'effettiva adozione. Le risposte a questo articolo spaziano dalle domande di base sui contenitori, alle opinioni molto ferme che molte persone stanno già utilizzando un'infrastruttura containerizzata multi-cluster e multi-cloud. Per quanto riguarda quest'ultima visione, dall'esperienza so che le aziende più piccole e più agili tendono a sottovalutare la complessità dietro le reazioni più lente alle grandi trasformazioni delle grandi imprese (Ian Miell fa un ottimo lavoro di & nbsp; abbattere la lentezza dell'impresa in questo post del blog). Quindi, in questo articolo, proverò a fare tre cose:

  • Tentativo di restringere alcune definizioni di base per le persone non techie che potrebbero ancora chiedersi di cosa si tratta
  • Cita l'attributo comune numero uno che ho visto tra le aziende che hanno successo con i container
  • Spiega perché il passaggio ai contenitori è solo la punta dell'iceberg delle tue preoccupazioni IT

"Guardalo dalla finestra"Foto di Robert Alves de Jesus su Unsplash

La mia app monolitica è in esecuzione su un container

VMware
cloud-nativa?

Beh, mi dispiace dirlo, ma dipende. Ricordiamo che un container è solo un pacchetto software che può essere eseguito sull'infrastruttura e che ci sono (almeno) due tipi di contenitori.

I container di sistema sono stati più lunghi, dai tempi di LXC (2008) o, forse, ai tempi di Solaris Zones. Queste sono, in modo semplicistico, unità piccole ed efficienti che si comportano come macchine virtuali. Possono supportare più applicazioni eseguibili e offrire isolamento e altre funzionalità che gli amministratori di sistema si sentiranno al sicuro, come la facilità di gestione. Questo è l'ideale per le app tradizionali che si desidera containerizzare senza rivoluzionare completamente le pratiche IT e il vantaggio è semplice: aumentare la densità delle applicazioni per server di oltre 10 volte rispetto a una macchina virtuale.

I contenitori di applicazioni hanno un'unica applicazione da eseguire. Questo è il mondo del formato di immagine Docker (diverso da Docker Engine, Docker Swarm o Docker Inc.) e

OCI
e ciò a cui la maggior parte della gente si riferisce quando menzionano la parola "contenitore". I vantaggi qui da un punto di vista dell'IT sono i contenitori applicativi che eseguono un'app di microservizi che promettono la piena naturalità del cloud: velocità di consegna elevata, scalabilità quasi infinita e migliore resilienza. Questi esiti drammatici richiedono una cultura e un cambiamento tecnologico significativi, ne citerò in dettaglio più avanti.

I contenitori sono solo pacchetti e, in generale, fanno come gli viene detto; microservices è un approccio architettonico alla scrittura di applicazioni software; e cloud-native è un metodo & nbsp; di distribuzione di tali applicazioni. & nbsp; Per rispondere alla domanda precedente: buttare via le risorse esistenti e ignorare i risultati aziendali alla ricerca di un ideale è probabilmente una cattiva pratica, quindi se si dispone di un ambiente VMware che è lì per rimanere, allora questo è probabilmente abbastanza cloud-nativo per ora (l'acquisizione di Heptio da parte di VMware è interessante in tal senso per il futuro caso d'uso). La linea di fondo è che rimanere agganciati sull'elemento più semplice (contenitori) da afferrare su quella lista è un errore comune.

Il martello di Thor non esiste nell'IT

Recentemente ho incontrato il responsabile di Cloud per una grande società di servizi finanziari del Regno Unito, che mi ha detto che il precedente CIO ha dovuto lasciare la sua posizione dopo aver fallito nel consegnare una strategia 'straight to serverless', cioè, saltare il cloud e il container rivoluzioni & nbsp; per gestire i carichi di lavoro sul datacenter privato ben utilizzato dell'azienda, con tecnologia serverless. Il fatto che il CIO abbia dovuto andarsene non è una grande sorpresa: in ogni linea di lavoro, abbiamo bisogno di usare gli strumenti giusti per i lavori giusti, specialmente quando questi lavori sono complessi. Nel cloud, ciò significa che nella maggior parte dei casi utilizzeremo probabilmente una combinazione di bare metal, macchine virtuali, contenitori e serverless, su qualsiasi combinazione di server farm privato, cloud privato o cloud pubblico.

Senza dubbio, l'unica cosa che ho visto come un primo passo in un percorso di transizione IT di successo è questa: non cercare di semplificare eccessivamente una drammatica evoluzione dell'IT (r). Invece, comprenderlo da un aspetto olistico e giudicarlo visibilmente – esiti e obiettivi di business. È bene impegnarsi, ma non tutte le aziende hanno la risorsa per essere puristi del cloud-nativo, e ci sono chiari vantaggi anche in fasi più piccole, come concedere più tempo per l'analisi dell'impatto della tecnologia o per consentire una migliore gestione del rischio. (Questo post dalla società di container Cloud 66 fa bene a descrivere & nbsp; l'efficienza a breve termine e l'intuizione a lungo termine, i guadagni di & nbsp; lo spostamento di un'app monolitica in un contenitore).

Conoscenze sconosciute e incognite sconosciute

Alla fine, però, non saremmo così entusiasti della rivoluzione dei contenitori se si trattasse solo di spremere più applicazioni monolitiche. Un'app di microservizi, in esecuzione in contenitori, orchestrata su più substrati e tutto ciò in base ai principi nativi del cloud, è qualcosa per cui vale la pena sudare. Un'applicazione che si adatta rapidamente e in modo affidabile con meno risorse operative, che si adatta rapidamente alle dinamiche dei clienti e della concorrenza e che si autoalimenta, è il punto su cui molti di noi puntano.

Ancora una volta, i contenitori sono solo una parte di questo. Considerare le sfide tecnologiche: per quanto riguarda l'orchestrazione? E la rete? E servizi di stato? E strumenti di pipeline pronti per il cloud?

Probabilmente ancora più importante, considera le sfide culturali: cosa deve cambiare con le nostre pratiche di sviluppo? Come possiamo trovare e mantenere il talento giusto? Come ri-abilitiamo il talento più vecchio e il ponte tra le generazioni? Come cambierà l'equilibrio del rischio?

Un esempio: l'open source fa già parte della tua strategia

È un fatto ben documentato che l'aumento del cloud e dell'open source è stato collegato, il che porta anche alcune interessanti tensioni, come ho esplorato nel mio articolo precedente. & nbsp; In container, questa & nbsp; sinergia sembra più forte che mai. Il juggernaut dietro Kubernetes e molti & nbsp; relativi progetti open source, il & nbsp; Cloud Native Computing Foundation (CNCF), fa parte della Linux Foundation. La carta CNCF è chiara sulle intenzioni della fondazione:& nbsp; cerca di promuovere e sostenere un ecosistema di progetti open source e neutrali al venditore. & nbsp; Conseguentemente, dal momento che & nbsp; la nascita di CNCF nel 2014, è diventato sempre più fattibile gestire un complesso stack cloud-nativo con un ampio mix di questi progetti open source (alcuni dati interessanti nel relazione annuale). Più ti avvicini alle metodologie native del contenitore, maggiore sarà l'open source che utilizzerai.

L'altro lato di questa immagine è che i pacchetti open source costituiscono blocchi significativi di & nbsp; applicazioni gratuite e proprietarie allo stesso modo – mentre l'intera app può essere proprietaria, il bit che il team ha effettivamente scritto potrebbe essere molto piccolo all'interno di esso. Come il Stato del rapporto di sicurezza open source mostra che l'uso open source è strettamente associato alla trasformazione digitale e, in quanto tale, sta diventando sempre più critico per l'azienda; tuttavia, solo il 17% dei manutentori classifica la propria competenza in materia di sicurezza al livello più alto, il che significa che molti di questi pacchetti rappresentano un rischio operativo.

Un altro aspetto è la comunità: l'uso di più open source rende l'organizzazione uno stakeholder, e come tale dovrebbe mettersi in contatto con la comunità interessata per vedere come può contribuire, e anche come ottenere l'esposizione alla roadmap e agli avvisi di sicurezza il più rapidamente possibile .

No contenente questo

Quindi, per riassumere & nbsp; l'esempio di cui sopra, una decisione 'semplice' sull'adesione all'onda del contenitore & nbsp; aumenterà in modo significativo e significativo il vantaggio dell'organizzazione e l'esposizione a software open source. Questo software può o non può essere supportato da grandi sponsor, probabilmente sarà gestito da volontari e probabilmente avrà una vibrante comunità dietro di esso, ognuno dei quali deve essere coinvolto da utenti che si affidano a questi progetti.

In altre parole, non è semplice. I contenitori sono una parte fondamentale di una trasformazione digitale, ma solo una parte. L'intera parte di & nbsp; questa trasformazione, le cui parti appariranno nei tuoi sistemi di distribuzione del software senza che te le aspetti, può abilitare grandi cose per le tue applicazioni, se affrontate con il giusto mix di apertura, maturità e responsabilità.

& Nbsp;

">

In un post precedente, ho sostenuto che nel caso di Kubernetes, l'hype potrebbe essere in anticipo rispetto all'effettiva adozione. Le risposte a questo articolo spaziano dalle domande di base sui contenitori, alle opinioni molto ferme che molte persone stanno già utilizzando un'infrastruttura containerizzata multi-cluster e multi-cloud. Per quanto riguarda quest'ultima visione, dall'esperienza so che le aziende più piccole e più agili tendono a sottovalutare la complessità dietro le reazioni più lente alle grandi imprese (Ian Miell fa un ottimo lavoro di abbattere la lentezza delle imprese in questo post del blog). Quindi, in questo articolo, proverò a fare tre cose:

  • Tentativo di restringere alcune definizioni di base per le persone non techie che potrebbero ancora chiedersi di cosa si tratta
  • Cita l'attributo comune numero uno che ho visto tra le aziende che hanno successo con i container
  • Spiega perché il passaggio ai contenitori è solo la punta dell'iceberg delle tue preoccupazioni IT

"Guardalo dalla finestra"Foto di Robert Alves de Jesus su Unsplash

La mia app monolitica è in esecuzione su un container

VMware
cloud-nativa?

Beh, mi dispiace dirlo, ma dipende. Ricordiamo che un container è solo un pacchetto software che può essere eseguito sull'infrastruttura e che ci sono (almeno) due tipi di contenitori.

I container di sistema sono stati più lunghi, dai tempi di LXC (2008) o, forse, ai tempi di Solaris Zones. Queste sono, in modo semplicistico, unità piccole ed efficienti che si comportano come macchine virtuali. Possono supportare più applicazioni eseguibili e offrire isolamento e altre funzionalità che gli amministratori di sistema si sentiranno al sicuro, come la facilità di gestione. Questo è l'ideale per le app tradizionali che si desidera containerizzare senza rivoluzionare completamente le pratiche IT e il vantaggio è semplice: aumentare la densità delle applicazioni per server di oltre 10 volte rispetto a una macchina virtuale.

I contenitori di applicazioni hanno un'unica applicazione da eseguire. Questo è il mondo del formato di immagine Docker (diverso da Docker Engine, Docker Swarm o Docker Inc.) e

OCI
e ciò a cui la maggior parte della gente si riferisce quando menzionano la parola "contenitore". I vantaggi qui da un punto di vista dell'IT sono i contenitori applicativi che eseguono un'app di microservizi che promettono la piena naturalità del cloud: velocità di consegna elevata, scalabilità quasi infinita e migliore resilienza. Questi esiti drammatici richiedono una cultura e un cambiamento tecnologico significativi, ne citerò in dettaglio più avanti.

I contenitori sono solo pacchetti e, in generale, fanno come gli viene detto; microservices è un approccio architettonico alla scrittura di applicazioni software; e cloud-native è un metodo per fornire tali applicazioni. Per rispondere alla domanda di cui sopra: buttare via le risorse esistenti e ignorare i risultati aziendali alla ricerca di un ideale è probabilmente una cattiva pratica, quindi se si dispone di un ambiente VMware che è lì per rimanere, allora è probabilmente cloud-nativo abbastanza per ora (acquisizione di VMware di Heptio è interessante in tal senso per il caso d'uso futuro). La linea di fondo è che rimanere agganciati sull'elemento più semplice (contenitori) da afferrare su quella lista è un errore comune.

Il martello di Thor non esiste nell'IT

Recentemente ho incontrato il responsabile di Cloud per una grande società di servizi finanziari del Regno Unito, che mi ha detto che il precedente CIO ha dovuto lasciare la sua posizione dopo aver fallito nel consegnare una strategia 'straight to serverless', cioè, saltare il cloud e il container rivoluzioni per gestire carichi di lavoro sul datacenter privato ben utilizzato dell'azienda, con tecnologia serverless. Il fatto che il CIO abbia dovuto andarsene non è una grande sorpresa: in ogni linea di lavoro, abbiamo bisogno di usare gli strumenti giusti per i lavori giusti, specialmente quando questi lavori sono complessi. Nel cloud, ciò significa che nella maggior parte dei casi utilizzeremo probabilmente una combinazione di bare metal, macchine virtuali, contenitori e serverless, su qualsiasi combinazione di server farm privato, cloud privato o cloud pubblico.

Senza dubbio, l'unica cosa che ho visto come primo passo in un percorso di transizione IT di successo è questa: non cercare di semplificare eccessivamente una drammatica evoluzione dell'IT (r). Invece, comprenderlo da un aspetto olistico e giudicarlo nei confronti dei risultati e degli obiettivi aziendali. È bene impegnarsi, ma non tutte le aziende hanno la risorsa per essere puristi del cloud-nativo, e ci sono chiari vantaggi anche in fasi più piccole, come concedere più tempo per l'analisi dell'impatto della tecnologia o per consentire una migliore gestione del rischio. (Questo post della società di container Cloud 66 fa bene a descrivere l'efficienza a breve termine e l'intuizione a lungo termine, i vantaggi di spostare un'app monolitica in un contenitore.)

Conoscenze sconosciute e incognite sconosciute

Alla fine, però, non saremmo così entusiasti della rivoluzione dei contenitori se si trattasse solo di spremere più applicazioni monolitiche. Un'app di microservizi, in esecuzione in contenitori, orchestrata su più substrati e tutto ciò in base ai principi nativi del cloud, è qualcosa per cui vale la pena sudare. Un'applicazione che si adatta rapidamente e in modo affidabile con meno risorse operative, che si adatta rapidamente alle dinamiche dei clienti e della concorrenza e che si autoalimenta, è il punto su cui molti di noi puntano.

Ancora una volta, i contenitori sono solo una parte di questo. Considerare le sfide tecnologiche: per quanto riguarda l'orchestrazione? E la rete? E servizi di stato? E strumenti di pipeline pronti per il cloud?

Probabilmente ancora più importante, considera le sfide culturali: cosa deve cambiare con le nostre pratiche di sviluppo? Come possiamo trovare e mantenere il talento giusto? Come ri-abilitiamo il talento più vecchio e il ponte tra le generazioni? Come cambierà l'equilibrio del rischio?

Un esempio: l'open source fa già parte della tua strategia

È un fatto ben documentato che l'aumento del cloud e dell'open source è stato collegato, il che porta anche alcune interessanti tensioni, come ho esplorato nel mio precedente articolo. Nei container, questa sinergia sembra più forte che mai. Il juggernaut di Kubernetes e molti altri progetti open source correlati, Cloud Native Computing Foundation (CNCF), fa parte della Linux Foundation. La carta CNCF è chiara sulle intenzioni della fondazione: cerca di promuovere e sostenere un ecosistema di progetti open source e neutrali al venditore. Di conseguenza, dal 2014, anno della nascita di CNCF, è diventato sempre più fattibile gestire un complesso stack cloud-nativo con un ampio mix di questi progetti open source (alcuni dati interessanti nella relazione annuale della fondazione). Più ti avvicini alle metodologie native del contenitore, maggiore sarà l'open source che utilizzerai.

L'altro lato di questa immagine è che i pacchetti open source costituiscono blocchi significativi di applicazioni libere e proprietarie allo stesso modo – mentre l'intera app può essere proprietaria, il bit che il team ha effettivamente scritto potrebbe essere molto piccolo all'interno di esso. Come mostra lo stato del rapporto sulla sicurezza dell'open source, l'utilizzo dell'open source è strettamente associato alla trasformazione digitale e, in quanto tale, sta diventando sempre più critico per l'azienda; tuttavia, solo il 17% dei manutentori classifica la propria competenza in materia di sicurezza al livello più alto, il che significa che molti di questi pacchetti rappresentano un rischio operativo.

Un altro aspetto è la comunità: l'uso di più open source rende l'organizzazione uno stakeholder, e come tale dovrebbe mettersi in contatto con la comunità interessata per vedere come può contribuire, e anche come ottenere l'esposizione alla roadmap e agli avvisi di sicurezza il più rapidamente possibile .

No contenente questo

Quindi, per riassumere l'esempio di cui sopra, una decisione "semplice" sull'adesione all'onda del contenitore aumenterà in modo significativo e significativo il beneficio dell'organizzazione e l'esposizione al software open source. Questo software può o non può essere supportato da grandi sponsor, sarà probabilmente gestito in maniera significativa dai volontari e probabilmente avrà una vivace comunità dietro di esso, tutti i quali devono essere coinvolti dagli utenti che si affidano a questi progetti.

In altre parole, non è semplice. I contenitori sono una parte fondamentale di una trasformazione digitale, ma solo una parte. Tutta questa trasformazione – le cui parti appariranno nei tuoi sistemi di distribuzione del software senza che te le aspetti – può abilitare grandi cose per le tue applicazioni, se affrontate con il giusto mix di apertura, maturità e responsabilità.