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

Question

我为即将收购另一家中型公司的中型公司运营技术。我们的技术都是LAMP（Linux/Apache/MySQL/PHP），我们正在收购的公司都是微软的堆栈（IIS/MSSQL/ASP.NET）。目前，职员中的开发人员都没有从事.NET，也从未支持过Microsoft服务器基础架构。我有一个艰难的时间决定如何处理这种情况...

我们是否所有的MS东西都转移到LAMP（对于各种原因而不感兴趣，包括我的团队的个人缺乏经验，当我们试图削减开销时的授权费用等）？

我们是否将两种技术与单独的团队并行运行以支持每个技术并编写一堆中间件以便彼此交谈？

这些选择都不是最佳选择。有没有人遇到过这样的情况，你是如何进行的？请记住，我们在高流量和后端系统相当广泛的两种情况下讨论了大型基础架构。任何想法都会受到欢迎。

Answer 1

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

虽然最终可能会有“效率节约”，他们希望通过整合后台员工来实现这一目标，但有一个强有力的理由让两个团队都支持他们的“自己的”系统，以保持照明亮起。

然后你需要分析重叠 - 你最终会在每个堆栈上的系统做类似的事情。如果是这样，请将其整合到首选平台上，并移除其他平台。另外看（无论目前的技能），哪个堆栈在未来几年最需要业务需求。 LAMP现在可能是完美的，但可能会有转向.net以满足未来需求的争论。然后再次也许不是，但需要评估。

2套系统共享数据是否存在业务需求？如果是这样，在什么级别？创建（web）服务来封装共享功能并使其可用于其他系统可能是一种可行的方法（SOA有效）。或者，您可能最初需要共享后端，并让.NET与MySQL数据库或某些人聊天。

Answer 2

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

如果这两个应用程序提供了类似的功能，那么我会并排运行，直到您想保留的那个具有另一个的所有功能。然后，我会把顾客换掉，最后把它扔掉。如果客户愿意接受，现在就切换他们。

如果他们是完全不同的应用程序，那么我很可能只是保持前进。鉴于这些是大型应用程序，任何重写都将是痛苦的并且很有可能失败。最好只是习惯于在家中使用不同的技术堆栈。

有一件事，通过维护这两个应用程序，您将能够更好地保持收购尽可能安静，就客户群而言。已经使用应用程序的客户通常只会在马上感觉到他们正在使用的应用程序不再受支持时才改变马匹。此时，无论另一个系统有多好，你都可以保证有些人会离开。

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

以上所述的一点是，这不仅仅是一个技术问题，更多的是一个业务问题，并归结为您首先获得另一家公司的原因，以及如何将其呈现给现有客户。如果该公司是因技术或其客户群而被收购的，那么把它放在一边是个好主意。

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

在一个案例中，该应用相对较小，但拥有庞大的用户群。我们最终使用了一些URL重写规则，以便用户群甚至不知道在其下面更改了应用程序。它是一个Web服务的集合。

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

Answer 3

我从来没有做过这件事，所以拿我的意见一粒盐。但我会建议不要重写现有的应用程序。我的意思是，如果它是一个1页的应用程序，当你点击一个按钮时它会告诉你“你好”，那么是的，用PHP重写它。但是赚钱的商业应用程序并不那么简单，而且您将从头开始重写一些其他公司需要花费x年才能开发的东西。更不用说，即使在用PHP重写它时，您也必须支持和维护您接管的应用程序。

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

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