Port un site IIS/ASP.NET à LAMP?

Question

Je dirige la technologie pour une entreprise de taille moyenne qui est sur le point d'acquérir une autre entreprise de taille moyenne. Notre technologie est tout LAMP (Linux/Apache/MySQL/PHP), la société que nous acquérons est toute la pile Microsoft (IIS/MSSQL/ASP.NET). Aucun des développeurs actuellement sur le site ne fait .NET et n'a jamais pris en charge l'infrastructure de serveur Microsoft. Je vais avoir du mal à décider quoi faire de la situation ...

Portons-nous tous les trucs 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 de la licence lorsque nous essayons de réduire les frais généraux, etc)? Est-ce que nous courons les deux technologies en parallèle avec des équipes séparées pour soutenir chacune et écrire un tas de middleware afin qu'ils puissent parler les uns aux autres?

Aucun de ces choix n'est optimal. Est-ce que quelqu'un a déjà été confronté à une telle situation et comment avez-vous procédé? Gardez à l'esprit que nous parlons de grandes infrastructures 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.

Answer 1

Dans le cadre de l'acquisition, votre entreprise prend-elle en charge l'équipe de support informatique de l'acquisition? Bien qu'il y ait des chances de réaliser des économies d'efficacité grâce à la consolidation du 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 analyser le chevauchement - vous vous retrouvez avec des systèmes sur chaque pile faisant des choses similaires. Si c'est le cas, cherchez à consolider sur la plate-forme préférée et à supprimer l'autre. Regardez également (indépendamment des compétences actuelles), quelle pile a le mieux besoin des besoins de l'entreprise dans les années à venir. LAMP peut être parfait en ce moment, mais il peut y avoir des arguments pour passer à .net pour répondre aux besoins futurs. Puis peut-être pas encore, mais doit être évalué.

Existe-t-il un besoin commercial pour les 2 systèmes de partager des données? Si oui, à quel niveau? La création de services (Web) pour encapsuler des fonctionnalités partagées et les rendre disponibles pour l'autre système peut être une solution (SOA). Alternativement, vous devrez peut-être partager un backend initialement et avoir .NET parler à une base de données MySQL ou quelque chose comme ça.

Answer 2

Ceci est une question très compliquée. Si les deux applications offrent des fonctionnalités similaires, je les exécuterai côte à côte jusqu'à ce que celle que vous souhaitez conserver possède toutes les fonctionnalités de l'autre. Ensuite, je passerais les clients et finalement le jeter. Si les clients sont réceptifs, changez-les maintenant.

S'il s'agit d'applications radicalement différentes, il est fort probable que je maintiendrai les deux à l'avenir. Étant donné que ce sont de grandes applications, toute réécriture va être douloureuse et avoir une forte probabilité d'échec. Il est préférable de s'habituer à l'idée d'avoir différentes piles de technologie à l'interne. Une chose, en maintenant les deux applications, vous serez dans une meilleure position pour garder l'acquisition la plus silencieuse possible en ce qui concerne la clientèle. Les clients qui utilisent déjà une application ne changent généralement de chevaux que s'ils pensent que l'application qu'ils utilisent ne sera plus prise en charge. À ce moment-là, vous pouvez garantir que certains partiront, peu importe la qualité de l'autre système.

Si l'acquisition va entraîner un changement dans le marketing (par exemple, le logo de l'autre société change, etc.) alors je suggère à nouveau de maintenir les deux. Les clients vont être assez nerveux comme ça.Le but de tout ce qui précède est qu'il s'agit plus d'un problème commercial que d'un problème technique et se résume aux raisons pour lesquelles vous avez acquis l'autre entreprise en premier lieu et comment vous le présenterez aux clients existants. Si l'entreprise a été acquise pour la technologie ou pour sa clientèle, alors il est préférable de le laisser seul.

BTW, j'ai fait cela quelques fois. La seule différence était d'aller de l'autre côté de PHP vers .Net.

Dans un cas, l'application était relativement petite, mais avait une base énorme d'utilisateurs. Nous avons fini par utiliser certaines règles de réécriture d'URL, de sorte que la base d'utilisateurs n'a même jamais su que l'application était modifiée en dessous d'eux. C'était une collection de services Web.

Dans un autre cas, l'application était grande, avait une grande base d'utilisateurs, et avait une peau très publique. Encore une fois, nous avons fortement utilisé la réécriture d'url pour préserver le placement google ainsi que les signets. Le plus gros problème que nous avons eu était le développement sur le site d'origine ne pouvait pas s'arrêter pendant que nous construisons le remplacement. Cela présentait beaucoup de défis dans la mesure où chaque caractéristique devait passer par les deux équipes. En fin de compte, le projet a pris environ 3 fois plus de temps que prévu, mais parce que nous avions des gens hautement qualifiés, il a finalement réussi.

Answer 3

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 d'une page qui vous dit "Hello" quand vous cliquez sur un bouton, alors oui, réécrivez-la en PHP. Mais les applications métier rentables ne sont pas aussi simples, et vous commencerez à partir de zéro pour réécrire quelque chose qui a pris l'autre entreprise x ans pour se développer. Sans compter que vous devrez soutenir et maintenir l'application que vous prenez, même pendant que vous le réécrivez en PHP.

Si vous avez des développeurs intelligents dans votre équipe maintenant, et qu'ils ont la capacité, ils seront en mesure d'apprendre ASP .NET. Mais il peut être préférable d'embaucher 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 des points d'intégration, ou de l'écriture d'une application d'entreprise entière à partir de zéro, je prendrais mes chances d'écrire des points d'intégration.