Je prévois de migrer une application Java de WebSphere vers un autre serveur d'applications. La principale motivation pour cela est d'économiser les frais de licence.
Je sais que le code source utilise des EJB et qu'ils ne sont pas pris en charge directement par Tomcat. Il y a deux grandes questions que je voudrais poser (et elles sont interdépendantes, je les pose donc en une seule question):
A) Comment puis-je identifier les tâches de migration / reprogrammation que je dois planifier? De diverses sources, j'ai trouvé que je devrais probablement suivre les étapes suivantes. Ma question est la suivante: quoi d'autre devrait figurer sur cette liste:
B) Quelle est la meilleure approche pour obtenir une estimation raisonnable de l'effort total? Je suppose que je peux simplement commencer et essayer de faire la migration pour avoir une première idée. Mais quels seraient les principaux points à examiner pour avoir une idée de l'effort total?
J'ai trouvé ce guide: Comment migrer de Websphere vers Tomcat , qui fournit déjà quelques conseils. Cependant, il n'entre pas vraiment dans les détails, en particulier il ne mentionne pas comment savoir quelles fonctionnalités spécifiques de WebSphere sont utilisées.
J'ai également trouvé ce guide sur [Comment migrer vers JBoss] (Comment migrer vers JBoss: https://docs.jboss.org/author/display/AS72/How%20do%20I%20migrate%20my%20application%20from% 20WebSphere% 20à% 20EAP% 206.html ). C'est beaucoup plus détaillé, mais j'ai l'impression que je dois faire presque toute la migration pour obtenir une estimation.
3 Réponses :
Divulgation complète: je travaille pour IBM sur Liberty
Si vous souhaitez économiser des frais de licence, vous pouvez envisager de passer à Liberty (Open Liberty ou WebSphere Liberty ou Liberty Core). Outre le fait qu'ils offrent des options moins chères que WebSphere Application Server ND traditionnel, ils sont également beaucoup plus efficaces et vous auriez donc besoin de beaucoup moins d'instances, ce qui permet d'économiser sur les coûts de licence et d'infrastructure.
Si vous utilisez WebSphere ND, vous pouvez également envisager WebSphere Base pour réduire les coûts de licence.
Lors des tests que nous avons effectués (et je vous recommande de faire le vôtre), nous avons trouvé que Liberty (utilisant OpenJ9 JVM) était bien plus efficace que les autres environnements d'exécution que nous avons testés (en termes de mémoire et de débit), y compris ceux que vous avez énumérés. Voir https://openliberty.io/blog/2020/10/21/memory-footprint-throughput.html
Si vous utilisez WebSphere traditionnel aujourd'hui, vous êtes déjà autorisé à utiliser Liberty.
Pour comprendre ce que vos applications utilisent et ce que vous pourriez avoir besoin de changer pour déplacer, vous pouvez utiliser Transformation Advisor - http://ibm.biz/cloudta
J'ai fait quelque chose de similaire l'année dernière et mon "économiser de l'argent" "gagner du temps" était de passer du serveur d'applications websphere nd à websphere liberty ou open liberty car liberty et websphere liberty partagent la même base de code la plus grande différence est le runtime JVM en termes de la fonctionnalité et de la configuration (par exemple fournisseur SSL pour keystore).
Pour ce faire, je suggère d'utiliser cet outil
https://www.ibm.com/garage/method/practices/learn/ibm-transformation-advisor
J'ai essayé une autre manière mais elles ne fonctionnent que s'il y a une parfaite indépendance de l'oreille par rapport au serveur d'application.
Jetez un œil à Apache TomEE au lieu de Tomcat. Il utilise Tomcat sous le capot, mais ajoute de nombreuses spécifications Java EE que vous pourriez manquer d'un Tomcat vanille.
Migrez simplement vers Open Liberty. Il prend en charge Jakarta EE (pas comme Tomcat) et contient de nombreuses bibliothèques WebSphere (pas comme JBoss), ce qui rend la migration plus rapide, plus facile et moins chère, est open source et est gratuit si vous ne voulez pas de support payant.