Portez un site IIS / ASP.NET sur LAMP?

Je dirige la technologie pour une entreprise de taille moyenne qui s’apprête à acquérir une autre entreprise de taille moyenne. Notre technologie est tout LAMP (Linux / Apache / MySQL / PHP), la société que nous achetons est toute la stack Microsoft (IIS / MSSQL / ASP.NET). Aucun des développeurs de l’équipe ne travaille actuellement sur .NET et n’a jamais pris en charge l’infrastructure de serveur Microsoft. J’ai du mal à décider quoi faire avec la situation …

Est-ce que nous portons tous les éléments de MS à LAMP (pas intéressé à aller dans l’autre sens pour diverses raisons, y compris l’inexpérience personnelle de mon équipe, le coût des licences lorsque nous essayons de réduire les frais généraux, etc.)?

Est-ce que nous exécutons les deux technologies en parallèle avec des équipes distinctes pour prendre en charge chacune et écrire un ensemble de middleware afin qu’ils puissent se parler?

Aucun de ces choix n’est optimal. Quelqu’un a-t-il déjà été confronté à une telle situation et comment avez-vous procédé? Gardez à l’esprit que nous parlons d’une grande infrastructure dans les deux cas avec des volumes de trafic élevés et des systèmes backend assez étendus. Toutes les idées seront les bienvenues.

Je n’ai jamais fait cela auparavant, alors prenez mon avis avec un grain de sel. Mais je suggère de ne PAS réécrire une application existante. Je veux dire, si c’est une application de 1 page qui vous dit simplement “Bonjour” quand vous cliquez sur un bouton, alors oui, réécrivez-le en PHP. Mais les applications métier qui rapportent de l’argent ne sont pas aussi simples que cela, et vous allez recommencer à zéro pour développer quelque chose qui a pris l’autre année x pour se développer. Sans compter que vous devrez supporter et maintenir l’application que vous prenez en charge, même si vous la réécrivez en PHP.

Si vous avez des développeurs intelligents dans votre équipe et qu’ils ont la capacité, ils pourront apprendre ASP .NET. Mais il serait peut-être préférable d’engager des ressources ASP .NET pour aider votre équipe à l’apprendre et à supporter le poids (maintenance et support) de l’application que vous prenez en charge. Vos équipes peuvent travailler ensemble pour trouver des points d’intégration entre les deux applications.

Face au choix de l’écriture de points d’intégration ou de l’écriture d’une application métier à partir de zéro, je me risquais à écrire des points d’intégration.

Dans le cadre de cette acquisition, votre entreprise s’engage-t-elle dans l’équipe d’assistance informatique de l’acquisition?

Bien qu’il y ait probablement des «économies d’efficacité» à réaliser en consolidant le personnel de back-office, il existe un argument de poids pour que les deux équipes soutiennent leurs «propres» systèmes afin de garder les lumières allumées.

Ensuite, vous devez parsingr le chevauchement – vous vous retrouvez avec des systèmes sur chaque stack qui font des choses similaires. Si c’est le cas, cherchez à consolider sur la plate-forme préférée et à supprimer l’autre. Examinez également (sans tenir compte des compétences actuelles), quelle stack correspond le mieux aux besoins de l’entreprise dans les années à venir. LAMP pourrait être parfait en ce moment, mais il pourrait y avoir des arguments pour passer à .net pour répondre aux besoins futurs. Encore une fois peut-être pas, mais doit être évalué.

Existe-t-il un besoin commercial pour les 2 ensembles de systèmes pour partager des données? Si oui, à quel niveau? La création de services (Web) pour encapsuler les fonctionnalités partagées et les rendre disponibles pour l’autre système peut constituer un moyen (SOA efficace). Alternativement, vous devrez peut-être partager un backend initialement et faire en sorte que .NET parle à une firebase database MySQL ou à un site Web.

C’est une question très compliquée.

Si les deux applications offrent des fonctionnalités similaires, je les exécuterais côte à côte jusqu’à ce que celle que vous souhaitez conserver ait toutes les fonctionnalités de l’autre. Ensuite, je changerai les clients et finalement je les jetterai. Si les clients sont réceptifs, changez-les maintenant.

Si ce sont des applications radicalement différentes, je ne ferais probablement que maintenir les deux. Étant donné qu’il s’agit d’applications volumineuses, toute réécriture sera douloureuse et risque fort d’échouer. Il est préférable de s’habituer à l’idée d’avoir différentes stacks technologiques en interne.

Une chose, en maintenant les deux applications, vous serez mieux placé pour garder l’acquisition aussi silencieuse que possible en ce qui concerne la clientèle. Les clients qui utilisent déjà une application ne modifient généralement les chevaux que s’ils estiment que l’application qu’ils utilisent ne sera plus prise en charge. À ce stade, vous pouvez garantir que certains partiront quelle que soit la qualité de l’autre système.

Si l’acquisition devait entraîner un changement dans le marketing (par exemple, le changement de logo de l’autre société, etc.), je suggérerais à nouveau de ne conserver que les deux. Les clients vont être assez nerveux.

Ce qui précède est qu’il s’agit davantage d’un problème d’entreprise qu’un problème technique et que cela se résume aux raisons pour lesquelles vous avez acquis l’autre société et comment vous la présenterez aux clients existants. Si l’entreprise a été acquise pour la technologie ou sa clientèle, la laisser seule est une bonne idée.

BTW, je l’ai fait quelques fois. La seule différence était d’aller de PHP à .Net.

Dans un cas, l’application était relativement petite, mais avait une base énorme d’utilisateurs. Nous avons fini par utiliser des règles de réécriture d’URL pour que la base d’utilisateurs ne sache même pas que l’application a changé sous eux. C’était une collection de services Web.

Dans un autre cas, l’application était grande, avait une base d’utilisateurs importante et avait un aspect très public. Encore une fois, nous avons tiré parti de la réécriture d’URL pour préserver l’emplacement de Google et les signets. Le plus gros problème que nous avons rencontré était que le développement sur le site d’origine ne pouvait pas s’arrêter pendant que nous construisions le remplacement. Cela présentait beaucoup de défis dans la mesure où chaque fonctionnalité devait passer par les deux équipes. Au bout du compte, le projet a pris environ 3 fois plus de temps que prévu, mais grâce à des personnes hautement qualifiées, le projet a finalement abouti.