负速度：如何提升复杂性极限
工程组织最常见的目标之一：快速交付高质量的软件。
查看您的首席信息官或首席技术官的愿景陈述，聆听他们的意见。很有可能他们正在追求这个目标的某种排列方式。虽然这是一个共同的目标，但实现这一必杀技的团队与陷入软件交付困扰的团队之间存在着广泛的差异。一些团队不断将新代码投入生产，几乎没有发生任何事件或对客户产生负面影响，而另一些团队还在为季度发布苦苦挣扎。
是什么原因导致了这种性能差异？
软件交付的复杂性是交付高质量软件、快速交付和…不交付软件之间的区别。这就是在每周成功发布后敲响胜利的钟声，与一个无所事事的软件交付团队之间的区别，该团队在因数月辛勤工作后发布的最新版本中有六个新错误并导致一次回滚而感到沮丧。
将初创公司推出新产品和功能的速度和质量与成熟的大型组织进行比较。例如，在金融行业，金融科技初创公司在过去十年中削减了大型老牌银行的市场份额。大型银行通常列举金融科技初创公司的不公平优势，这些初创公司的监管监督较少，没有传统、单一的应用资产可供维护。较小的团队规模可以提高灵活性，并能够根据客户需求进行调整。从本质上讲，金融科技公司不像老牌银行那样复杂，这使他们能够以更低的风险更快地行动。虽然它会减慢软件团队的速度，但复杂性并不总是一件坏事。
The benefits of SOA
SOA's modularity and standardized protocols enable services to communicate effectively, promoting reusability, interoperability, and scalability. These key benefits translate into tangible advantages for companies:
- Reusability: Reusing existing services reduces development time and costs and promotes consistency and quality. Companies can accelerate development cycles and improve overall efficiency.
- Interoperability: Services can communicate and exchange data regardless of their underlying technology or programming language. This facilitates enterprise-wide data integration and collaboration. Interoperability streamlines business processes and helps companies adapt to evolving technologies.
-
Scalability: SOA's modular design enables independent scaling of services to meet fluctuating demands. It ensures applications can handle spikes in traffic or expanding user bases without compromising performance or stability. Companies can adapt their infrastructure to changing needs without costly rewrites or redesigns.
相关资料
防止软件杂乱无章
查看解决方案
使用 Compass 来管理组件
软件交付的复杂性
复杂性可能是一件好事：解决棘手的问题是非常有意义的。它激励团队迎接挑战，解决棘手的问题，并扭转行业的局面。相反，在某种程度上，复杂性不再是解决难题，而是会对软件团队产生负面影响。
组织复杂性在降低软件团队效率方面起着关键作用。柯林斯词典将复杂性定义为“许多不同部分以复杂的方式相互连接或关联的状态”。实际上，组织复杂性是指信息、依赖关系、变更、其他团队、工具和请求的汇总，软件团队在与组织其他部门互动时需要了解这些内容。
更高的组织复杂性自然会使快速交付高质量软件变得更具挑战性，因为团队在组织中导航花费的时间比解决棘手的问题要多。成长中的组织很快了解到软件团队已达到复杂性极限——团队在影响工作满意度以及软件制作的质量和速度之前能够应对的复杂性。因此，降低组织复杂性使团队能够专注于解决棘手的问题，更快地交付软件并提高质量，这似乎是合乎逻辑的。我们来探讨一下为什么情况不一定如此。
Benefits of microservices
鉴于这些优势，越来越多的组织成员开始采用微服务架构，这自然开始增加组织的复杂性。更多的自主团队需要更多的协作，而更多的微服务意味着更多的依赖关系。变革的步伐飞快——所有这些都是软件蔓延的迹象。复杂性的增加导致软件团队的效率趋于平缓，这表现为变更速度的下降，认知负荷成为软件团队的问题。
如何判断您是否接近复杂性极限
达到复杂性极限可能让人感到不可避免，但有一些迹象表明团队已接近极限。首先我要说的是，没有绝对的指标可以告诉您离复杂性极限有多近，但是这些指标可以帮助您确定自己有多接近极限。
团队已达到复杂性极限最明显的指标是，他们花在应对组织复杂性上的时间多于解决本应关注的棘手问题。DORA 变更准备提前期（速度）和变更失败率（质量）指标的趋势显示团队是随着时间的推移减慢还是加速。尽管还有其他因素会影响这些指标，但它们是衡量团队效率的好指标。
开发人员满意度是衡量软件团队组织复杂程度的另一个指标。开发人员比任何其他角色都更喜欢花时间解决棘手的问题，同时也讨厌那些妨碍工作的不必要任务。开发人员满意度低很好地表明组织复杂性是软件团队面临的问题。
| Feature | SOA | Microservices |
| Architectural style |
|
|
| Service granularity |
|
|
| Independence |
|
|
| Communication |
|
|
| Data storage |
|
|
| Scalability |
|
|
| Deployment |
|
|
| Coupling |
|
|
如何判断您是否接近复杂性极限
达到复杂性极限可能让人感到不可避免，但有一些迹象表明团队已接近极限。首先我要说的是，没有绝对的指标可以告诉您离复杂性极限有多近，但是这些指标可以帮助您确定自己有多接近极限。
团队已达到复杂性极限最明显的指标是，他们花在应对组织复杂性上的时间多于解决本应关注的棘手问题。DORA 变更准备提前期（速度）和变更失败率（质量）指标的趋势显示团队是随着时间的推移减慢还是加速。尽管还有其他因素会影响这些指标，但它们是衡量团队效率的好指标。
开发人员满意度是衡量软件团队组织复杂程度的另一个指标。开发人员比任何其他角色都更喜欢花时间解决棘手的问题，同时也讨厌那些妨碍工作的不必要任务。开发人员满意度低很好地表明组织复杂性是软件团队面临的问题。
简化是一种失败的策略
当公司意识到自己的团队陷入了复杂性之中时，他们通常会启动一个“简化项目”，旨在恢复组织的简单性。简化是一种失败的策略，原因有两个：复杂性的增加速度比任何组织简化其环境的速度都要快，而且这些“简化项目”在他们想要简化的复杂环境中运行。
简化的一个常见起点是通过尽可能停用或整合来减少应用的数量。停用应用要求团队了解所有上游和下游依赖关系、谁在使用应用、如何替换功能、在何处和如何存档或迁移数据，并处理此类工作中出现的许多其他复杂问题。不幸的是，为实现这一目标而投入的大量努力并没有带来同样显著的复杂性降低。公司在不影响核心业务或用户体验的情况下可以停用的应用数量是有限的，但是工程师可以创建的新软件组件的数量没有限制。在停用一个应用所花费的 12 个月中，很可能已经创建了数百个新的微服务。由于健康的技术环境会随着时间的推移而增长，因此将环境保持在固定数量的应用或软件组件以降低复杂性是不切实际的。
简化项目通常包括重新设计组织结构以消除沟通流程的复杂性。最不复杂的组织结构涉及大型等级团队，所有工作人员都同地办公。最复杂的组织结构涉及小型、分布式的自主团队。康威定律向我们表明，大型登记团队可能会生产单体应用，而小型分布式团队则可能使用微服务等模块化架构来开发应用。微服务架构等模块化架构模式可以快速生产高质量软件，这意味着更复杂的组织结构更有可能取得成功。尽管“简化”组织结构使其更易于理解，但对简化项目的最终目标适得其反。
简化既重要又值得，但最好将其内构为软件团队（和团队）的持续改进，而不是一劳永逸的活动。简化可能会延迟达到复杂性极限，但不会使组织恢复在创业环境中享受的快节奏自由。
提升复杂性极限
What are the challenges of adopting SOA and microservices?
为了恢复软件团队的效率，组织需要提高复杂性极限。提高复杂性极限本质上意味着增加每个团队在影响工作满意度以及团队交付软件的质量和速度之前可以应对的组织复杂性。
平台工程是寻求提升组织复杂性极限的重要概念。强大的平台工程团队专注于通过将组织复杂性从日常工作中抽象出来，以减少软件团队的认知负荷。如果实施得当，平台工程可以使团队重新平衡大部分精力以解决棘手的问题，减少花在应对组织复杂性上的时间。
Can SOA and microservices coexist?
正是出于这个原因，Atlassian 创建了开发人员体验平台 Compass。Compass 让软件团队可以轻松地通过组件目录、指标和记分卡来应对组织的复杂性，并专注于创建健康的工程文化，从而帮助提升复杂性极限。这里的关键点是，Atlassian 内部的组织复杂性并没有降低，事实上，随着越来越多的组织成员转向微服务架构，组织复杂性还在持续增长。我们减少了软件团队应对这种复杂性所花费的时间，这是简化项目和提升复杂性极限的区别。
Atlassian 拥有 10000 多名员工和超过 17000 个软件组件，但我们的软件团队在很大程度上可以像初创公司一样自由地运营，快速交付高质量的软件。我们成功的关键？提升复杂性极限以提高软件团队的效率。
以下是开始提升复杂性极限的两个操作：
- 跟踪和评估您的 DORA 指标。您的团队的 DORA 指标如何？如果您还没有跟踪这些指标，那么 Compass 会提供开箱即用的 DORA 指标。
- 了解和评估开发人员满意度。开发人员在您的软件团队中感觉如何？大多数组织都会进行员工满意度调查。询问按职能领域细分的结果，以深入了解开发人员的满意度。关键问题包括对以下陈述进行评级：
- 我很自豪能交付
- 我的工作压力是可以管理的
- 我明白我的工作对公司目标有何贡献
或者，Compass 会在 CheckOps 例行程序中捕捉这些信息，各团队在例行程序中分享他们上周的感受，以及本来可以做得更好的细节。
提升复杂性极限需要将工具、流程和例行程序结合起来。像 Compass 这样的开发人员体验平台可以帮助您了解系统运行状况、绘制依赖关系并创建持续的例行程序，帮助提升复杂性极限并释放组织中软件交付团队的潜力。
立即免费试用 Compass。
How does each architecture impact deployment and DevOps practices?
Both SOA and microservices deployments benefit from Open DevOps practices. However, the specifics will differ depending on the architecture.
SOA typically involves monolithic deployments, where teams deploy an entire application as a single unit. This approach requires careful coordination between teams. It can be time-consuming and complex, especially for large applications.
DevOps emphasizes collaboration and automation between development and operations teams to address these challenges. This enables more frequent and reliable deployments. By automating testing, configuration management, and infrastructure provisioning, DevOps can help streamline SOA deployments and minimize errors.
Microservices architecture enables more granular deployments. Teams deploy each microservice independently.
DevOps principles are also essential for microservices deployments. DevOps practices such as continuous integration and continuous delivery allow teams to automate the process of testing, deploying, and building microservices. This facilitates rapid and frequent releases.
分享此文章
下一主题
推荐阅读
将这些资源加入书签，以了解 DevOps 团队的类型，或获取 Atlassian 关于 DevOps 的持续更新。
Compass 社区
教程：创建组件
