Whoa, what a long post. First, you should be aware that the 99.9% and better kool-aid is a bit dangerous to drink while blind. Yes, you can get some astounding stability figures, but you need to write your program in a way facilitating this. It does not come for free. It does not happen by magic either. Your application must be designed in a way such that other subsystems recover. OTP will help you a lot - but it still takes time to learn.
Continuous integration: Easily done. If you can call rebar or make through your build-bot you are probably set here already. Look into eunit, cover and Erlang QuickCheck (the mini variant is free for starters) - all can be run from rebar.
QA Cycle: I have not had any problems here. Again, if using rebar you can build embedded releases that are minimized erlang vm's you can copy anywhere and run (they are self-contained). You can even hot deploy fixes to such a system pretty easily by altering the code path a bit so you have an overlay of newer fixes. Your options are numerous. Git already help you here a lot.
Environmentalization: Easily done.
Logging centralization: Look into SASL and the error_logger. You can do anything you want here.
Alerting: The system can be probed for all you need (introspection is strong in Erlang). But you might have to code a bit to hook it up to the system of your choice.
Misconfiguration: Configuration files are Erlang terms. If it can be computed, it can be done.
Security: Limit who has access. It is a people problem, not a technical one in my opinion.
Profiling: cprof, cover, eprof, fprof, instrument + a couple of distributed systems for doing the same. Random sampling is also easy (introspection is strong in Erlang).
Windows interaction: Dunno. (Bias: last time I used windows professionally was in 1998 or so).
Some personal observations:
Your largest problem might end up being that you try to cram Erlang into your existing process and it might resist. It is a new environment, so new approaches will be needed in places and you should expect to adapt and workaround limitations you find along the way. The general consensus is that it can work (it is working for several big sites).
It looks like you have a well-established and strict process. How much is that process allowed to be sacrificed to give way to a new kind of thinking?
Are your programmers willing to throw out almost all of their OO knowledge? If not, you will end with a social problem rather than a technical one. If they are like me however, they will cheer, clap in their hands and get a constant high by working with an interesting language solving an interesting problem in a new way.
How many Erlang-experienced programmers do you have? If you have rather few, then better cut your teeth on some smaller subsystems first and then work towards the larger goal. Getting the full benefit of the system takes months if not years. Getting partial benefit can be had in weeks though.
发布评论
评论（1）
哇，好长的帖子啊。首先，您应该意识到，盲人饮用 99.9% 或更好的 kool-aid 饮料有点危险。是的，您可以获得一些令人震惊的稳定性数据，但您需要以有利于实现这一点的方式编写程序。它不是免费的。它也不是靠魔法发生的。您的应用程序的设计方式必须使其他子系统能够恢复。 OTP 会对您有很大帮助 - 但仍然需要时间学习。
持续集成：轻松完成。如果您可以通过构建机器人调用
rebar或make，那么您可能已经在此处进行了设置。研究一下 eunit、cover 和 Erlang QuickCheck（迷你变体对于初学者来说是免费的）——所有这些都可以从 rebar 运行。QA 周期：我在这里没有遇到任何问题。同样，如果使用 rebar，您可以构建最小化的 erlang 虚拟机的嵌入式版本，您可以在任何地方复制并运行（它们是独立的）。您甚至可以通过稍微更改代码路径来轻松地将修复程序热部署到此类系统，以便覆盖较新的修复程序。您的选择有很多。 Git 已经在这里为你提供了很多帮助。
环保：很容易做到。
日志集中化：研究 SASL 和 error_logger。你可以在这里做任何你想做的事。
警报：可以探测系统以获取您需要的一切（Erlang 中的自省功能很强）。但您可能需要编写一些代码才能将其连接到您选择的系统。
配置错误：配置文件是 Erlang 术语。如果可以计算，就可以完成。
安全性：限制谁有权访问。在我看来，这是一个人的问题，而不是技术问题。
分析：cprof、cover、eprof、fprof、instrument + 几个用于执行相同操作的分布式系统。随机采样也很容易（Erlang 中的自省能力很强）。
Windows 交互：不知道。 （偏见：我上次专业使用 Windows 是在 1998 年左右）。
一些个人观察：
你最大的问题可能最终是你试图将 Erlang 塞进你现有的流程中，但它可能会抵制。这是一个新的环境，因此某些地方需要新的方法，您应该期望能够适应并解决您在此过程中发现的限制。普遍的共识是它可以工作（它正在为几个大型网站工作）。
看起来你们有一个完善且严格的流程。为了让位于一种新的思维方式，这个过程可以被牺牲多少？
您的程序员是否愿意抛弃几乎所有的面向对象知识？如果没有，你最终会遇到社会问题而不是技术问题。然而，如果他们像我一样，他们会欢呼、鼓掌，并通过使用有趣的语言以新的方式解决有趣的问题而获得持续的兴奋。
你们有多少有 Erlang 经验的程序员？如果你的子系统相当少，那么最好先在一些较小的子系统上进行尝试，然后再朝着更大的目标努力。充分利用该系统需要数月甚至数年的时间。不过，几周内就能获得部分福利。
Whoa, what a long post. First, you should be aware that the 99.9% and better kool-aid is a bit dangerous to drink while blind. Yes, you can get some astounding stability figures, but you need to write your program in a way facilitating this. It does not come for free. It does not happen by magic either. Your application must be designed in a way such that other subsystems recover. OTP will help you a lot - but it still takes time to learn.
Continuous integration: Easily done. If you can call
rebarormakethrough your build-bot you are probably set here already. Look into eunit, cover and Erlang QuickCheck (the mini variant is free for starters) - all can be run from rebar.QA Cycle: I have not had any problems here. Again, if using
rebaryou can build embedded releases that are minimized erlang vm's you can copy anywhere and run (they are self-contained). You can even hot deploy fixes to such a system pretty easily by altering the code path a bit so you have an overlay of newer fixes. Your options are numerous. Git already help you here a lot.Environmentalization: Easily done.
Logging centralization: Look into SASL and the error_logger. You can do anything you want here.
Alerting: The system can be probed for all you need (introspection is strong in Erlang). But you might have to code a bit to hook it up to the system of your choice.
Misconfiguration: Configuration files are Erlang terms. If it can be computed, it can be done.
Security: Limit who has access. It is a people problem, not a technical one in my opinion.
Profiling: cprof, cover, eprof, fprof, instrument + a couple of distributed systems for doing the same. Random sampling is also easy (introspection is strong in Erlang).
Windows interaction: Dunno. (Bias: last time I used windows professionally was in 1998 or so).
Some personal observations:
Your largest problem might end up being that you try to cram Erlang into your existing process and it might resist. It is a new environment, so new approaches will be needed in places and you should expect to adapt and workaround limitations you find along the way. The general consensus is that it can work (it is working for several big sites).
It looks like you have a well-established and strict process. How much is that process allowed to be sacrificed to give way to a new kind of thinking?
Are your programmers willing to throw out almost all of their OO knowledge? If not, you will end with a social problem rather than a technical one. If they are like me however, they will cheer, clap in their hands and get a constant high by working with an interesting language solving an interesting problem in a new way.
How many Erlang-experienced programmers do you have? If you have rather few, then better cut your teeth on some smaller subsystems first and then work towards the larger goal. Getting the full benefit of the system takes months if not years. Getting partial benefit can be had in weeks though.