微服务和esb不是一样吗_不是微服务，而是你

微服务和esb不是一样吗

The hype creates a dynamic of inflated expectations and excitement with business representatives and software engineers alike. In companies and teams where decision pushing is commonplace this often leads to rushed decisions, which likely ends in frustration and disappointment.

炒作在业务代表和软件工程师之间产生了一种过高的期望和兴奋。 在决策推动司空见惯的公司和团队中，这通常会导致仓促决策，最终可能导致挫败感和失望感。

Business representatives, software engineers and other technical specialists should be freely exchanging ideas, discussing risks and doubts as well as challenging each other with strong mutual respect. Creating this culture takes effort, a sense of personal responsibility and proactiveness from all involved. And I can guarantee you, no architecture or new technology will create long term success if the culture within the company is dominated by a small group of individuals who don’t understand that being a leader is to listen.

业务代表，软件工程师和其他技术专家应自由交换意见，讨论风险和疑虑，并在相互尊重的情况下相互挑战。 创造这种文化需要付出努力，需要所有参与者的个人责任感和积极主动。 而且，我可以向您保证，如果公司内部的文化由一小撮人组成，而这些人不了解自己是领导者，那是没有任何架构或新技术可以取得长期成功的。

Teams that rush into microservices can get burned in many different ways. When re architecting an application into smaller, loosely-coupled pieces of software that communicate with each other over a network, teams suddenly have to deal with the fallacies of distributed computing and decentralized data management. There’s a multitude of articles that explore these complexities in greater detail, so I won’t replicate that effort. I can say that underestimating these complexities often results in fragile architectures, scaling issues and substantial rework. Mastering them takes preparation, planning and experience.

投入微服务的团队可能会以许多不同的方式被烧毁。 当将应用程序重新架构为可通过网络相互通信的较小的，松散耦合的软件时，团队突然不得不应对分布式计算和分散数据管理的弊端 。 有许多文章更详细地探讨了这些复杂性，因此我不会重复这些工作。 我可以说，低估了这些复杂性通常会导致体系结构脆弱，问题扩展和大量返工。 掌握它们需要准备，计划和经验。

We cannot overcome the fact there will be a learning curve, as there really is no substitute for experience. That being said, the chances of success can be greatly increased through the right preparation and planning. A key aspect in that regard is estimation.

我们无法克服这样一个事实，那就是学习曲线，因为确实没有什么可以替代经验。 话虽如此，通过正确的准备和计划，可以大大增加成功的机会。 在这方面的一个关键方面是估计。

In this blog I want to share an estimation technique that I’ve found to be helpful to channel the excitement around technology trends and break through unrealistic expectations by providing clarity on effort as well as associated complexity, risks and unknowns. This enables the right conversations between business representatives, software engineers and other technical specialists about trends like microservices before committing prematurely.

在此博客中，我想分享一种估计技术，该技术有助于通过围绕工作趋势以及相关的复杂性，风险和未知数来激发人们对技术趋势的兴趣并突破不切实际的期望。 这使得业务代表，软件工程师和其他技术专家之间就微服务等趋势进行了正确的对话，然后才提早作出承诺。

如何正确进行工作估算 (How to do work estimation right)

No matter how hard you try, estimation will never be perfect. We cannot predict the future and foresee what we don’t know. The fact that we cannot be perfect when estimating, does not mean it doesn’t have value.

无论您多么努力，估计都不会是完美的。 我们无法预测未来，也无法预测我们所不知道的事情。 我们在估算时不能完美的事实并不意味着它没有价值。

Complexity, uncertainty, and risk are all factors that influence confidence and therefore also influence the estimated effort. But most estimation techniques whether it’s hours, ideal days, story points or t-shirt sizing, only focus on the effort and don’t provide means to also express confidence.

复杂性，不确定性和风险都是影响置信度的因素，因此也会影响估计的工作量。 但是大多数估算技术，无论是小时数，理想日子，故事情节还是T恤尺码，都只关注工作量，而没有提供表达信心的手段。

Which is a shame since it’s a big part of the value that is achieved through estimation. Because work that the team doesn’t feel confident about is much more likely to cause problems. One way of making confidence transparent having the team that will be delivering the work perform range estimation. A range estimation technique I’ve had good results with is the 50/90 estimation technique. When using 50/90 estimation, every piece of work is estimated twice:

真可惜，因为它是通过估算获得的价值的很大一部分。 因为团队不信任的工作更有可能引起问题。 一种使信心透明的方法是让将要进行工作的团队执行范围估计。 我获得了很好的效果的范围估算技术是50/90估算技术。 使用50/90估算时，每个工作估算两次：

• The first estimate represents a “aggressive, but possible” (ABP) estimate where there’s 50% certainty of completing the work within that time.
  第一个估计值表示“积极但可能”(ABP)估计值，其中在该时间内完成工作有50％的确定性。
• The second estimate represents a “highly probable” (HP) estimate where there’s 90% certainty of completing the work within that time.
  第二个估计值表示“高度可能”(HP)估计值，其中在此时间内完成工作的确定性为90％。

A narrow range, with the ABP and HP estimates being fairly close together, means the team is confident in the work. A wide range, where the ABP and HP estimates are far apart, means the team is not confident in the work based on current information and knowledge.

ABP和HP估计范围很窄，这意味着该团队对这项工作充满信心。 ABP和HP估计值相差很大，这意味着团队根据当前的信息和知识对这项工作没有信心。

When dealing with a wide range, the team should discuss the complexities, risks or unknowns they foresee and if these can be reduced or mitigated. Some examples it’s lead-time, dependencies on other teams, known bottlenecks, development complexity of technologies that are not known. When these things are outside the span of control of the team, they’re still relevant. Doesn’t mean it becomes their responsibility to fix, it’s their responsibility to make it transparent so it can either be acted upon or explicitly accepted.

在进行广泛的处理时，团队应讨论他们所预见的复杂性，风险或未知数，以及是否可以减少或减轻这些未知数。 例如交货时间，对其他团队的依赖，已知的瓶颈，未知技术的开发复杂性。 当这些事情超出团队的控制范围时，它们仍然有意义。 但这并不意味着要修复它是他们的责任，而是要使它变得透明，以便可以对其采取行动或明确接受它是他们的责任。

There are three additional rules that ensure you get the most value out of the estimation process and the decision making process:

还有另外三个规则可确保您从估计过程和决策过程中获得最大价值：

• Make sure that the estimation is done by the engineers that are performing the work. Involving others with prior expertise is certainly valuable, but they should assume a role where they use their experiences in a coaching capacity with the goal to eliminate blind spots in the estimations.
  确保估算是由执行工作的工程师完成的。 让其他人拥有先验的专业知识固然很有价值，但是他们应该扮演一个角色，以他们的经验作为教练，以消除估计中的盲点。
• Prevent estimations performed by one person to reduce cognitive bias and in a group setting make sure everyone involved provides input. Which can be challenging in groups with very vocal or overpowering individuals if not addressed. A simple trick often applied in story point estimation is having everybody present their estimates at the exact same time to eliminate the possibility of people being influenced. This is crucial to reduce the cognitive bias of individuals and extract the best out of the team by sparking the right conversations.
  防止一个人进行估计以减少认知偏见，并在小组设置中确保每个参与者都提供输入。 如果没有解决的话，这在具有很高声音或压倒性个人的小组中可能是具有挑战性的。 通常在故事点估计中应用的一个简单技巧是让每个人都在同一时间展示他们的估计，以消除人们受到影响的可能性。 这对于减少个人的认知偏见以及通过激发正确的对话来从团队中汲取最好的知识至关重要。
• Communicate estimations in bandwidth form, with the identified risks and possible follow up actions to reduce or mediate risks. The 50/90 estimation technique offers a formula for compounding all the range estimates back into a single number.
  以带宽形式传达估计值，已识别的风险以及可能采取的后续行动以降低或调解风险。 50/90估算技术提供了一个公式，用于将所有范围估算值重新组合为一个数字。

With the estimation results available, it’s time to decide what to do with the identified risks. Often it is possible to reduce or mitigate them. A common example is building a proof of concept to better understand a particular problem or challenge. The improved understanding or reduced blind spot should improve estimate accuracy. Investing additional time and resources in reducing or mitigating risks might not always be possible or worth the effort. This is fine, as long as residual risks are explicitly accepted.

有了可用的估算结果，就该决定如何处理已识别的风险了。 通常可以减少或减轻它们。 一个常见的示例是构建概念证明，以更好地理解特定问题或挑战。 更好的理解或减少的盲点将提高估计的准确性。 在减少或减轻风险上投入额外的时间和资源可能并不总是可行的，也不值得付出努力。 只要可以明确接受残余风险，就可以了。

准备是成功的一半 (Preparation is half the victory)

Instead of telling you if microservices are the right choice I shared a technique that enables your team to come to their own conclusion. Which is how it should be as nobody understands your circumstances better.

我没有告诉您微服务是否是正确的选择，而是分享了一种使您的团队得出自己的结论的技术。 因为没人能更好地了解您的情况，所以应该这样。

A key takeaway is that estimation is just a tool. The real goal is using that valuable information to bring everyone together and have honest conversations about the value and the realistic cost of applying/using microservices. Doing so gives a much better starting point than someone who watched a few tech talks on how Netflix migrated to microservices and feels that success can be replicated overnight.

一个关键的结论是，估计只是一种工具。 真正的目标是利用这些有价值的信息将每个人聚集在一起，并就应用/使用微服务的价值和实际成本进行坦诚的交谈。 这样做比那些观看过有关Netflix如何迁移到微服务的技术讲座的人提供了更好的起点，并且认为成功可以在一夜之间复制。

It’s very possible that some teams come to the conclusion they don’t need microservices or that they don’t feel confident enough given the complexities and learning curve when viewed in context of time constraints. Companies and teams often have multiple improvements going one in parallel so priorities have to be set.

一些团队很可能得出这样的结论：他们不需要微服务，或者在时间限制的情况下，鉴于复杂性和学习曲线，他们没有足够的信心。 公司和团队通常会同时进行多项改进，因此必须确定优先级。

In that case, consider starting with a monolith that is designed to be modular. This enables that application to be broken up into microservices later if their situation changes and the additional complexity of microservices can be justified. This upholds the KISS and YAGNI principles and avoids over engineering while also being mindful that the situation might change in the future.

在这种情况下，请考虑从设计成模块化的整体开始。 如果微服务的情况发生变化并且可以证明微服务的额外复杂性是合理的，那么这可以在以后将应用分解为微服务。 这秉承了KISS和YAGNI的原则，避免了过度的工程设计，同时还牢记未来情况可能会发生变化。

Those who have completely disregarded monoliths would do well to remember that Netflix started as a monolith before transitioning to microservices at a later stage. And while we all have the belief that we are building the next unicorn with massive scale requirements just around the corner, it’s likely that some of us are wrong.

那些完全忽略了整体的人会很好地记住Netflix是从整体开始的，之后才过渡到微服务。 尽管我们所有人都相信我们即将建立具有大规模需求的下一个独角兽，但我们当中有些人可能是错的。

翻译自: https://medium.com/swlh/its-not-microservices-it-s-you-8f2431dc50ff

微服务和esb不是一样吗