将 IIS/ASP.NET 站点移植到 LAMP？

Question

我为一家中型公司负责技术，该公司即将收购另一家中型公司。我们的技术全是LAMP（Linux/Apache/MySQL/PHP），我们收购的公司全是微软栈（IIS/MSSQL/ASP.NET）。员工中的开发人员目前都没有使用 .NET，也没有支持过 Microsoft 服务器基础结构。我很难决定如何处理这种情况......

我们是否将所有 MS 的东西都移植到 LAMP（出于各种原因，包括我的团队对它的个人经验不足、我们试图削减开销时的许可成本等，对采用其他方式不感兴趣）？

我们是否与不同的团队并行运行这两种技术以支持每种技术并编写一堆中间件以便他们可以相互交流？

这些选择都不是最优的。有没有人遇到过这样的情况，你是如何处理的？请记住，在这两种情况下，我们都在谈论具有高流量和相当广泛的后端系统的大型基础设施。欢迎任何想法。

Answer 1

我以前从未这样做过，所以请持保留态度。但我建议不要重写现有的应用程序。我的意思是，如果它是一个单页应用程序，当你单击一个按钮时它只会告诉你“你好”，那么是的，用 PHP 重写它。但是赚钱的商业应用程序并不那么简单，你需要从头开始重写其他公司花了 x 年才开发出来的东西。更不用说你必须支持和维护你接管的应用程序，即使你用 PHP 重写它。

如果您的团队中现在有聪明的开发人员，并且他们有能力，他们将能够学习 ASP .NET。但是最好租用一些 ASP .NET 资源来帮助您的团队学习它并承担您正在接管的应用程序的重量（维护和支持）。您的团队可以一起寻找两个应用程序之间的集成点。

面对编写集成点或从头开始编写整个业务应用程序的选择，我会抓住机会编写集成点。

Answer 2

作为收购的一部分，贵公司是否在收购 IT 支持团队？

虽然最终他们可能希望通过整合后台员工来实现“效率节省”，但有一个强有力的论点是让两个团队都支持自己的“自己的”系统以保持正常运转。

然后你需要分析重叠 - 你最终是否让每个堆栈上的系统都在做类似的事情。如果是这样，请寻求整合到首选平台并删除另一个。还要看看（无论当前技能如何），哪个堆栈最需要未来几年的业务需求。 LAMP 现在可能是完美的，但可能存在迁移到 .net 以满足未来需求的争论。再说一次，也许不是，但需要评估。

这两组系统是否有共享数据的业务需求？如果有，在什么水平？创建（Web）服务以封装共享功能并使其可用于其他系统可能是一种方法（有效的 SOA）。或者，您最初可能需要共享一个后端，并让 .NET 与 MySQL 数据库或类似的数据库通信。

Answer 3

这是一个非常复杂的问题。

如果这两个应用程序提供类似的功能，那么我会同时运行这两个应用程序，直到您要保留的应用程序具有另一个应用程序的所有功能。然后我会切换客户并最终将其丢弃。如果客户愿意接受，请立即更换。

如果它们是完全不同的应用程序，那么我很可能只是保持两者向前发展。鉴于这些都是大型应用程序，任何重写都将是痛苦的，并且很有可能失败。最好习惯于在内部拥有不同的技术堆栈。

有一件事，通过维护这两个应用程序，您将处于更好的位置，就客户群而言，尽可能地保持收购安静。已经使用应用程序的客户通常只会在他们觉得他们正在使用的应用程序不再受支持时才换马。到那时，你可以保证不管其他系统有多好，都会有人离开。

如果收购将导致市场营销发生变化（例如，其他公司的徽标发生变化等），那么我再次建议只保留两者。客户会很紧张的。

以上所有内容的重点是，这更像是一个业务问题而不是技术问题，归结为您最初收购另一家公司的原因以及您将如何将其展示给现有客户。如果公司是因为技术或客户群而被收购的，那么不管它是个好主意。

顺便说一句，我已经做过几次了。唯一的区别是从 PHP 到 .Net 的另一条路线。

在一种情况下，该应用程序相对较小，但拥有庞大的用户群。我们最终使用了一些 URL 重写规则，这样用户群甚至都不知道应用程序在它们下面发生了变化。它是 Web 服务的集合。

在另一种情况下，该应用程序很大，拥有庞大的用户群，并且拥有非常公开的皮肤。同样，我们大量利用 url 重写来保留 google 位置和书签。我们遇到的最大问题是在构建替代站点时无法停止原始站点的开发。这带来了很多挑战，因为每个功能都必须经过两个团队。最终，该项目花费了大约 3 倍的时间，比预期的要长，但因为我们有一些高技能的人，所以它最终成功了。