Scegliere i servizi di Azure corretti per le applicazioni Java
Questo articolo illustra come usare i servizi di Azure per la distribuzione di applicazioni Java, evidenziando il supporto di Azure per diverse tecnologie e architetture Java. Descrive i metodi di distribuzione, ad esempio "Lift and Shift", la containerizzazione e la funzionalità PaaS (Platform-as-a-Service), su misura per vari livelli di controllo e semplicità.
L'articolo sostiene una mentalità A+B, che consiglia di scegliere i servizi in base alle esigenze dell'applicazione rispetto a una scelta A o B fissa. Suggerisce di prendere in considerazione casi d'uso, obiettivi aziendali, sicurezza e budget per un approccio flessibile. L'articolo evidenzia la partnership di Microsoft con i leader dell'ecosistema Java per migliorare le esperienze degli sviluppatori e consiglia i servizi di Azure per la distribuzione di applicazioni Java, sia come origine, file binari o contenitori. Questo approccio sfumato consente di concentrarsi sull'innovazione, supportata dall'impegno di Microsoft a fornire applicazioni Java con i servizi di Azure più appropriati per la strategia di distribuzione, ottimizzando l'efficienza, la scalabilità e l'efficacia dei costi.
Distribuire qualsiasi applicazione Java con sicurezza e facilità
L'ecosistema Java include tecnologie diverse, ad esempio Java edizione Standard, Jakarta edizione Enterprise (successore di Java edizione Enterprise e J2 edizione Enterprise), Spring, numerosi server applicazioni e altri framework. Qualsiasi operazione eseguita con Java, ad esempio la creazione di un'app, l'uso di un framework e l'esecuzione di un server applicazioni, supporto tecnico di Azure il carico di lavoro con un'ampia gamma di opzioni. Analogamente, supporto tecnico di Azure qualsiasi architettura dell'applicazione, dalle applicazioni monolitiche in esecuzione nelle macchine virtuali o nei contenitori alle applicazioni basate su microservizi native del cloud in esecuzione su servizi completamente gestiti.
Azure offre i tre metodi principali seguenti per l'esecuzione di applicazioni Java nel cloud, personalizzate in base a diversi livelli di controllo e semplicità:
L'approccio "Lift and Shift" consente la migrazione minima delle applicazioni esistenti direttamente ad Azure Macchine virtuali.
La containerizzazione offre flessibilità, con servizio Azure Kubernetes (AKS) e Azure Red Hat OpenShift sono le piattaforme principali per orchestrare le app in contenitori.
Platform-as-a-Service (PaaS) rappresenta l'apice della facilità e dell'efficienza, offrendo produttività ottimale per gli sviluppatori e gestibilità operativa, spesso abbinato al costo totale più economico della proprietà.
Indipendentemente dalla fase dello sviluppo di applicazioni Java, Azure offre una soluzione cloud compatibile per soddisfare i requisiti. Per altre informazioni su queste offerte, vedere Distribuire applicazioni Java con sicurezza e facilità.
Portabilità completa per le applicazioni Java: distribuire facilmente ovunque
Indipendentemente dal servizio di Azure scelto per l'applicazione Java, la flessibilità dell'applicazione è garantita. Poiché si dispone del codice Java e dei relativi output compilati, è possibile distribuire l'applicazione ovunque si voglia, ad esempio nel computer di sviluppo locale, compilare server, ambienti locali o qualsiasi piattaforma cloud scelta. La portabilità dell'applicazione è nelle mani.
Naturalmente, quando ci sono così tante scelte, si affronta un dilemma.
Dilemma: usare il servizio A o B per le applicazioni Java
Se si esplorano le offerte di Azure, è possibile che si verifichi il dilemma di selezionare il servizio di Azure più adatto per l'esecuzione delle applicazioni Java. Questa scelta è fondamentale, in quanto influenza la pianificazione delle risorse, il budget, le sequenze temporali del progetto e infine il time-to-market dell'applicazione. La decisione influisce non solo sui costi di distribuzione iniziali, ma anche sulle spese di manutenzione in corso.
In passato, le organizzazioni spesso si sentivano costrette a scegliere tra due piattaforme, tecnologie o soluzioni concorrenti per le applicazioni software. Ad esempio, le organizzazioni devono decidere tra applicazioni WebLogic o WebSphere per Java Enterprise, Docker Swarm o Kubernetes per la gestione dei contenitori o contenitori rispetto alle macchine virtuali (VM) per la distribuzione. Questo processo decisionale è denominato "mentalità A o B" e differisce in modo significativo rispetto ai test A/B, che è un metodo per confrontare due versioni di una pagina Web o di un'app tra loro per determinare quali prestazioni migliori. In questo contesto, invece, la mentalità A o B consiste nel scegliere una piattaforma o una tecnologia rispetto a un'altra per la distribuzione di applicazioni. Si tratta di procedure locali tradizionali, in cui le decisioni sono spesso vincolate da fattori come modelli di distribuzione software in pacchetto, notevoli investimenti iniziali nelle licenze dell'infrastruttura e del software e i tempi di lead lunghi necessari per creare e distribuire qualsiasi piattaforma applicativa.
L'adozione di questa mentalità in Azure può comportare tempi eccessivi per la creazione di una singola piattaforma che tenta di soddisfare tutte le applicazioni, introducendo potenzialmente ritardi ed inefficienze. Tuttavia, Azure offre un approccio più vantaggioso, incoraggiando un passaggio da questa mentalità restrittiva a quella che abbraccia il meglio di entrambi i mondi, in ultima analisi producendo un migliore ritorno sugli investimenti (ROI).
Durante la transizione ad Azure, l'ambiente cloud offre un paradigma flessibile in cui è possibile effettuare il provisioning e il deprovisioning delle risorse in base alle proprie esigenze, eliminando la necessità di scegliere tra un servizio rispetto all'altro. Questa flessibilità favorisce l'approccio A+B, una strategia che diverge dalla mentalità tradizionale A o B promuovendo un modo più ampio e inclusivo di pensare. Azure facilita questo passaggio semplificando la combinazione dei vantaggi di più servizi e adottando una mentalità A+B sia semplice che conveniente. Questo approccio sottolinea il principio di selezione dei servizi che meglio si allineano alle esigenze specifiche dell'applicazione, essenzialmente richiamando la scelta dello strumento appropriato per il processo.
La transizione a una mentalità A+B consente alle organizzazioni di ampliare i processi decisionali e le strategie tecniche, adottando nuove possibilità e opportunità offerte da questa mentalità. Questo articolo delinea i principi della mentalità A+B, consentendo di selezionare in modo selettivo i servizi di Azure che hanno un aspetto più efficace con i requisiti dell'applicazione. Sia che si tratti di App Spring di Azure, app Azure Servizio, App Azure Container (ACA), servizio Azure Kubernetes o Macchine virtuali, la mentalità A+B consente di valutare e scegliere tra una serie di servizi di Azure per l'hosting delle applicazioni. Questa filosofia è applicabile universalmente, trascendendo i confini del linguaggio e del framework. Anche se le applicazioni Java sono incentrate qui, la mentalità A+B è ugualmente rilevante e vantaggiosa per le applicazioni sviluppate in qualsiasi linguaggio di programmazione.
Adottando la mentalità A+B, non ci si limita a un singolo servizio predeterminato. È invece possibile combinare i servizi in modo da soddisfare al meglio le esigenze specifiche dell'applicazione. Questo approccio non solo migliora la flessibilità e la scalabilità, ma ottimizza anche i costi e l'efficienza operativa. Questo approccio garantisce che la strategia tecnica sia dinamica e adattabile come l'ambiente cloud in cui si sta operando.
Perché non è necessario pensare al servizio A o B
La scelta del servizio cloud appropriato per le applicazioni non deve essere una decisione binaria tra il servizio A o il servizio B, grazie alla flessibilità e all'ampiezza delle opzioni offerte dal cloud, in particolare con Azure. Le sezioni seguenti descrivono il motivo per cui non è necessario attenersi alla tradizionale scelta "uno o l'altro" e come l'adozione di un approccio più fluido può trarre vantaggio dalle operazioni.
Dalle vecchie abitudini alla nuova flessibilità
Tradizionalmente, la distribuzione di sistemi IT ha comportato investimenti iniziali significativi nell'hardware e nel software, oltre a tempi di configurazione lunghi. Questo ambiente ha reso logico selezionare attentamente una piattaforma e ottimizzare tutto ciò che lo circonda per risparmiare sui costi e sulle risorse. Tuttavia, l'ambiente cloud, incluso Azure, introduce un cambiamento di paradigma con la sua natura su richiesta e elastica. Si paga solo per ciò che si usa e si modificano le risorse per soddisfare le proprie esigenze diventa semplice, senza il carico di spesa iniziale in conto capitale.
Il passaggio al cloud
Il passaggio al cloud e ad Azure, in particolare, apporta un cambiamento significativo nel modo in cui vengono gestite le responsabilità dell'infrastruttura e della piattaforma. Gran parte del sollevamento pesante, precedentemente eseguito dall'organizzazione, ora passa a Microsoft, come illustrato nel diagramma seguente. Questa modifica semplifica le operazioni e riduce il lavoro necessario per gestire le applicazioni. Non sei vincolato dai vincoli di gestione di più piattaforme, liberandoti di scegliere lo strumento migliore per ogni processo senza doverti preoccupare dei costi e delle complessità aggiuntivi.
Il diagramma seguente illustra il modello di responsabilità condivisa tra il cliente e il provider di servizi cloud:
Scegliere la scelta migliore per ogni esigenza
In questo nuovo mondo incentrato sul cloud, il processo decisionale diventa più appropriato per selezionare lo strumento giusto per il lavoro giusto, invece di cercare di adattarsi a tutte le esigenze in un unico servizio predeterminato. Sia che si scelga tra servizio Azure Kubernetes e le applicazioni Azure Spring Apps per Spring Boot o qualsiasi altro set di servizi, lo stato attivo passa a ciò che meglio soddisfa i requisiti di ogni applicazione specifica.
L'aumento dei microservizi
L'adozione di microservizi supporta ulteriormente questo approccio flessibile. Per impostazione predefinita, i microservizi incoraggiano l'uso della tecnologia più adatta per ogni servizio, promuovendo una diversità tecnologica che naturalmente si allinea alla mentalità A+B. Questo approccio consiste nell'usare i punti di forza dei diversi servizi per creare un'architettura applicativa più affidabile, efficiente e scalabile.
Vantaggi dell'adozione di A+B
L'adozione di una mentalità A+B offre diversi vantaggi chiave. Consente una maggiore flessibilità e flessibilità, consentendo di scegliere gli strumenti e i servizi più appropriati per ogni aspetto delle operazioni. Questo approccio non solo porta a una migliore efficienza delle risorse e dei costi, ma riduce anche il time-to-market per i prodotti. In definitiva, questo approccio promuove l'eccellenza operativa allineando le scelte tecnologiche più strettamente alle esigenze e agli obiettivi aziendali.
In sintesi, il cloud e Azure in particolare offrono un nuovo modo di pensare alla distribuzione e alla gestione delle applicazioni. Allontanandosi dalla scelta restrittiva A o B e adottando la mentalità A+B, è possibile prendere decisioni più allineate alle esigenze specifiche delle applicazioni, con conseguente miglioramento dell'efficienza, agilità e risparmio sui costi.
Linee guida pratiche per la transizione alla mentalità A+B
L'elenco seguente enumera alcuni principi chiave che è possibile usare come linea guida per la transizione alla mentalità A+B e continuare con esso:
Passare dal caso d'uso alla soluzione, non dall'altra parte. Spesso, molti team software decidono prima di tutto la tecnologia e quindi cercano di forzare i casi d'uso e la progettazione. In molti casi, questo approccio comporta un sovraccarico significativo in termini di costi, tempo di sviluppo, risorse e spese operative. Ottenere chiarezza sui casi d'uso e sui requisiti, sia funzionali che non funzionali, prima di passare alla soluzione.
Comprendere gli obiettivi aziendali, la natura dell'azienda e la concorrenza e la frequenza con cui è necessario implementare nuove funzionalità nell'ambiente di produzione. È consigliabile progettare sempre la soluzione per soddisfare gli obiettivi e gli obiettivi aziendali.
Informazioni sui requisiti di sicurezza e conformità. Nell'era del cloud, dove tutto è accessibile tramite Internet, la sicurezza è fondamentale e non negoziabile. Inoltre, a seconda del settore usato, l'applicazione potrebbe dover soddisfare determinati requisiti di conformità. È necessario progettare la soluzione per gli attacchi di sicurezza avanzata meteo e soddisfare i requisiti di conformità.
Comprendere il budget e le sequenze temporali. Avere una chiara comprensione del budget per lo sviluppo iniziale, le operazioni in corso e le versioni future. Comprendere anche le sequenze temporali. Il costo dei progetti ritardati, sia in termini di spese aggiuntive che di impatto negativo sul business, è spesso sottovalutato. Progettare la soluzione per soddisfare sia il budget che la sequenza temporale.
Si pensi al cloud nativo, se applicabile. L'architettura e le tecnologie native del cloud sono un approccio alla progettazione, alla costruzione e ai carichi di lavoro operativi compilati nel cloud che sfruttano appieno il modello di cloud computing. Con il cloud nativo, è possibile creare e distribuire applicazioni nell'ambiente di produzione a una velocità più rapida. Il cloud offre anche funzionalità che potrebbero non essere possibili in locale, ad esempio elasticità, scalabilità globale, analisi avanzata, intelligenza artificiale e funzionalità di Machine Learning (ML). Progettare la soluzione in base alle tecnologie native del cloud il più possibile.
Pensare alle impostazioni cultura di DevOps. DevOps non è solo strumenti o processi, è una pratica di sviluppo software che promuove la collaborazione tra sviluppo e operazioni, con conseguente distribuzione di software più veloce e affidabile. Comunemente chiamato cultura, DevOps connette persone, processi e tecnologie per offrire valore continuo.
Scegliere la soluzione che soddisfi i requisiti aziendali e non funzionali, ovvero:
- Più veloce da implementare.
- Conveniente in termini di costi necessari per la creazione, la compilazione, la distribuzione e le operazioni.
- Facile da usare.
- Completamente compatibile con l'automazione.
- Supporto di DevOps in base alla progettazione.
Questi principi consentono di mantenere l'attenzione sul punto in cui deve essere: creare una soluzione che soddisfi gli obiettivi aziendali anziché forzare la soluzione a una piattaforma predeterminata.
Eccezioni
Come qualsiasi altra cosa, esistono eccezioni a A+B. L'elenco seguente non è esaustivo, ma fornisce indicazioni direzionali su alcune eccezioni che potrebbero verificarsi:
Strategia aziendale. Ad esempio, alcune aziende usano un'adozione a livello aziendale di contenitori per compilare e distribuire applicazioni perché potrebbero avere più linguaggi di programmazione in gioco e vogliono compilare e distribuire tutte le applicazioni in modo unificato.
Troppo lontano dalla linea con l'esecuzione. È possibile che sia stata scelta una soluzione prima di eseguire l'analisi A+B. Se si è già approfondita l'esecuzione della soluzione, continuare con essa, ma per l'applicazione successiva, usare i principi della mentalità A+B per scegliere la soluzione più adatta per il caso d'uso.
Migrazioni di data center su larga scala. Per accelerare il percorso verso il cloud, le aziende usano in genere una strategia denominata "lift and shift" che implica la migrazione in blocco dei server (che ospitano le applicazioni) in azure usando strumenti come Azure Migrate. Alcuni usano questo approccio per eseguire la migrazione dei data center ad Azure e arrestarli in modo efficiente e conveniente. In questo scenario è consigliabile usare la mentalità A+B per modernizzare le applicazioni dopo la migrazione ad Azure.
Considerazioni essenziali
È stato fornito il framework per pensare e i principi che è possibile usare per scegliere le destinazioni appropriate in Azure per le applicazioni. Non è una dimensione adatta a tutti. Non è A o B, ma A + B.
Il diagramma seguente riepiloga le considerazioni principali per la scelta di un servizio di Azure per qualsiasi applicazione:
Come scegliere i servizi di Azure giusti per le applicazioni Java
Per semplificare il processo di selezione tra le numerose opzioni tecnologiche per le applicazioni Java in Azure, è stato creato un semplice albero delle decisioni per aiutare sviluppatori, clienti e integratori di sistemi al servizio azure ottimale.
Oltre alle indicazioni pratiche per considerare i requisiti non funzionali, dal punto di vista tecnologico, la domanda iniziale da considerare è se è necessario controllare l'infrastruttura. In caso contrario, i servizi gestiti sono i migliori, più consigliabile. La natura delle applicazioni, che siano basate su Spring o App Server, guida ulteriormente la decisione: le applicazioni Spring sono allineate ad Azure Spring Apps, mentre app Azure Service si adatta alle applicazioni Tomcat o JBoss EAP.
Per coloro che richiedono il controllo dell'infrastruttura, la scelta dipende dalle preferenze tecnologiche multi-cloud: Azure Macchine virtuali offre una transizione semplice e per coloro che si integrano con Tanzu, le offerte tanzu nel marketplace IaaS sono ideali. I clienti investiti in Kubernetes hanno le opzioni di servizio Azure Kubernetes e Azure Red Hat OpenShift. Questo framework decisionale è progettato per semplificare le scelte associando i requisiti dei clienti alle soluzioni più adatte di Azure.
Microsoft collabora con numerosi partner, inclusi i partner nelle aree seguenti:
- Partner leader dell'ecosistema Java, ad esempio Oracle, Broadcom, Red Hat, IBM e OpenAI.
- Database chiave e organizzazioni di strumenti, ad esempio MySQL, PostgreSQL, MongoDB Labs, DataStax, Redis Labs, Confluent e Elastic.
- Esperti di osservabilità, ad esempio New Relic, Dynatrace, AppDynamics, Grafana Labs e Datadog.
- Strumenti di sviluppo, ad esempio IntelliJ, Maven e Gradle.
L'investimento combinato consente di creare esperienze di sviluppo più fluide, garantendo integrazioni senza problemi con servizi essenziali, ad esempio database, cache, messaggistica e directory, oltre a fornire strumenti completi per l'osservabilità. Grazie all'automazione, al bilanciamento del carico e alla scalabilità automatica, l'obiettivo è quello di far fronte alla gestione dell'infrastruttura. Questo supporto consente di concentrarsi sulla creazione di valore aziendale tramite il codice, con la certezza che i sistemi sottostanti sono affidabili e scalabili. Per questi motivi, è consigliabile usare servizi di Azure specifici per ospitare ed eseguire i tipi di applicazione Java.
Distribuire applicazioni Java come origine o file binari
Per le applicazioni Java in Azure, sia che vengano distribuite direttamente dal codice sorgente o come file binari compilati (file JAR, WAR o EAR), la distribuzione è semplificata grazie alle offerte di servizi complete di Azure progettate appositamente per questi scopi. La portabilità intrinseca delle applicazioni Java significa che Azure può fornire un'ampia gamma di servizi per soddisfare le specifiche strategie di distribuzione e le esigenze operative. Questa flessibilità garantisce che, indipendentemente dalle specifiche dell'applicazione Java, sia disponibile un servizio di Azure adatto alle proprie esigenze.
Si considerino i tre esempi seguenti, che illustrano il modo in cui Azure soddisfa diversi scenari di distribuzione di applicazioni Java:
Applicazioni Spring. Per gli sviluppatori che lavorano con le applicazioni Spring, Microsoft Azure ha collaborato con Tanzu di Broadcom, leader nei progetti open source Spring, per offrire un servizio cloud premier noto come Azure Spring Apps. Questa collaborazione migliora le esperienze di sviluppo grazie all'integrazione di strumenti di sviluppo diffusi come IntelliJ, VS Code, Maven e Gradle, insieme a strumenti di automazione come Azure DevOps, GitHub Actions e Jenkins. Sono supportati anche strumenti di osservabilità come Application Insights, New Relic, Dynatrace, App Dynamics, Grafana, Log Analytics, Elastic e Splunk. La sicurezza è una priorità assoluta, con integrazioni per Key Vault che gestisce i segreti e i certificati TLS/SSL, l'autenticazione "senza password" con servizi di backup tramite identità gestite e il controllo degli accessi in base al ruolo di Azure, garantendo un processo di distribuzione sicuro e semplificato per le app Spring nel cloud.
Applicazioni Java in JBoss EAP. Analogamente, per le applicazioni Java che usano JBoss EAP, è disponibile un'esperienza personalizzata grazie alla collaborazione tra il team di Microsoft Azure e i team di Red Hat JBoss EAP. Questa partnership ha portato a un supporto migliorato su app Azure Service, offrendo un set completo di funzionalità progettate per le applicazioni JBoss EAP. Questo supporto consente di usare l'esperienza combinata di Microsoft e Red Hat, assicurando che le applicazioni Java vengano eseguite senza problemi, in modo sicuro ed efficiente in Azure.
Applicazioni Java aziendali in WebLogic. Le applicazioni Java aziendali tradizionali eseguite in Oracle WebLogic hanno anche un percorso dedicato ad Azure. La collaborazione tra Microsoft Azure e i team di Oracle WebLogic ha aperto la strada alla distribuzione ottimizzata in Azure Macchine virtuali. Questa partnership si estende all'integrazione con funzionalità IaaS fondamentali, ad esempio macchine virtuali, archiviazione, rete e servizi di bilanciamento del carico, fornendo una solida base per le applicazioni Java aziendali in Azure. Questo impegno coordinato garantisce che le applicazioni possano trarre vantaggio sia dall'affidabilità di WebLogic che dalla scalabilità e dalla flessibilità dell'infrastruttura di Azure.
Questi scenari evidenziano la dedizione di Azure all'offerta di un ambiente di distribuzione flessibile, sicuro ed efficiente per le applicazioni Java, offrendo diversi framework e architetture. Azure offre anche servizi specializzati per altre applicazioni Java, ad esempio quelle in esecuzione in Tomcat o WebSphere, assicurando che sia disponibile un servizio di Azure adatto per ogni tipo di applicazione Java.
Gli sviluppatori e gli operatori ottengono un'esperienza di distribuzione cloud uniforme e produttiva usando questi servizi di Azure personalizzati, automatizzando e proteggendo le applicazioni Java con facilità. Tuttavia, la scelta di opzioni di distribuzione alternative potrebbe richiedere la gestione della compilazione e della manutenzione di queste esperienze essenziali per sviluppatori e operatori.
Il diagramma seguente mostra i servizi di Azure consigliati per ogni tipo di applicazione Java distribuito come origine o file binari:
Per altre informazioni sui servizi a cui si fa riferimento in questo diagramma, usare i collegamenti nella tabella seguente:
| Service | Guida introduttiva per le app Java: distribuita come origine o file binari |
|---|---|
| Azure Spring Apps | Distribuire un'app Spring |
| Servizio app | Distribuire un'app Java in Tomcat Distribuire un'app Java in JBoss EAP |
| Funzioni di Azure | Distribuire un'app per le funzioni Java |
| Macchine virtuali di Azure | Oracle WebLogic Server in Azure Macchine virtuali Famiglia IBM WebSphere in Azure Macchine virtuali |
Distribuire applicazioni Java come contenitori
Quando si tratta di distribuire applicazioni Java, la containerizzazione rappresenta un approccio all'avanguardia che migliora l'automazione nella creazione, nella gestione e nella governance dei contenitori in tutte le aziende. La sfida consiste nel creare contenitori in modo sicuro e affidabile, un passaggio fondamentale per offrire rapidamente applicazioni software di alta qualità e in contenitori. Questo processo può iniziare da zero o usare sistemi contenitore esistenti, integrando strumenti che compilano e archiviano codice e file binari per semplificare gli aggiornamenti e la gestione dei contenitori. Tale integrazione è fondamentale per adattarsi alle pipeline di integrazione continua/distribuzione continua (CI/CD), offrendo un metodo di distribuzione flessibile per le applicazioni Java in formato contenitore.
I servizi di Azure si distinguono non solo semplificando la distribuzione di applicazioni in contenitori, ma anche fornendo percorsi chiari per la distribuzione da origini o file binari. Questo duplice approccio riduce al minimo l'impatto sugli sviluppatori e riduce il carico per gli operatori dell'infrastruttura o della piattaforma. Data la portabilità intrinseca di Java, l'ampia gamma di servizi contenitore di Azure garantisce la corrispondenza perfetta per la strategia e le esigenze di distribuzione.
Si considerino i due esempi seguenti, che illustrano come Azure si rivolge agli scenari di distribuzione di applicazioni Java in contenitori:
Applicazioni Spring. Azure Spring Apps è un'ottima scelta per le applicazioni Spring in contenitori. Supporta più tipi di distribuzione, tra cui l'origine, i file binari o le immagini del contenitore. Questa flessibilità consente di spostarsi facilmente tra i metodi di distribuzione. È possibile iniziare con i contenitori, ma successivamente decidere di eseguire la distribuzione come origini o file binari. Questa opzione è vantaggiosa perché evita la necessità di costruire e gestire in modo continuativo i contenitori, che possono essere complessi, ripetitivi e a elevato utilizzo di tempo.
Applicazioni Java in Tomcat. app Azure Servizio è adatto per la creazione di contenitori di applicazioni Java progettate per l'esecuzione in Tomcat. Supporta vari tipi di distribuzione, ad esempio file binari o immagini del contenitore. Analogamente ad Azure Spring Apps, questo servizio offre flessibilità per alternare le strategie di distribuzione. È possibile iniziare con la distribuzione dei contenitori e mantenere l'opzione per passare in un secondo momento alla distribuzione di file binari (WAR e JAR). Questa versatilità garantisce che sia possibile scegliere il metodo di distribuzione più efficiente per lo scenario specifico, semplificando il processo di sviluppo e distribuzione.
Questi esempi sottolineano l'impegno di Azure a fornire ambienti versatili, efficienti e descrittivi per sviluppatori per la distribuzione di applicazioni Java, sia tramite metodi tradizionali che la modernizzazione dei contenitori.
Il diagramma seguente illustra i servizi di Azure consigliati per ogni tipo di applicazione Java distribuito come contenitori:
Per altre informazioni sui servizi a cui si fa riferimento in questo diagramma, usare i collegamenti nella tabella seguente:
Riepilogo
Nell'esplorazione della distribuzione di applicazioni Java, Azure sostiene un approccio A+B sfumato, offrendo una gamma di servizi personalizzati per soddisfare le esigenze di ogni applicazione. La collaborazione di Microsoft con i leader dell'ecosistema Java ha portato a una suite di servizi di Azure, ognuna consigliata per tipi di applicazioni Java specifici, distribuiti come origine, binari o contenitori, semplificando il processo di distribuzione e garantendo prestazioni ottimali. Questo aspetto è incentrato sulla corrispondenza delle strategie di distribuzione con i servizi di Azure più appropriati sottolinea l'impegno di Microsoft a offrire la flessibilità necessaria per scegliere gli strumenti giusti per il processo. La portabilità intrinseca delle applicazioni Java è un vantaggio fondamentale, consentendo una transizione trasparente tra sistemi locali e diversi provider di servizi cloud per migliorare l'efficienza operativa e l'agilità. Richiamando questo processo di selezione più ampio e inclusivo, Microsoft non solo semplifica il percorso cloud per le applicazioni Java, ma ottimizza anche la scalabilità, la sicurezza, l'osservabilità e l'efficacia dei costi. In definitiva, le linee guida di Microsoft consentono agli sviluppatori e alle aziende di usare l'ecosistema di Azure, assicurando che ogni applicazione Java si adatti meglio alle proprie esigenze.
Passaggio successivo
Commenti e suggerimenti
Presto disponibile: Nel corso del 2024 verranno gradualmente disattivati i problemi di GitHub come meccanismo di feedback per il contenuto e ciò verrà sostituito con un nuovo sistema di feedback. Per altre informazioni, vedere https://aka.ms/ContentUserFeedback.
Invia e visualizza il feedback per