从开发人员到(解决方案)架构师。一份简单的指南。
如果你没有接受过正规的计算机科学教育,但已经从事开发工作多年,或者你只是一名初级工程师,但你的经理已经问过你,你认为自己几年后在技术领域会发展到什么程度。你想成为一名架构师,但不确定需要什么,并且想更好地了解自己应该专注于哪些方面。你想了解自己的技术差距在哪里,以及需要哪些软技能。这篇文章就是为你准备的!
架构师是一个涵盖性术语,指的是专注于设计或完善软件解决方案以造福客户的角色。但根据您所在的组织,架构师的职责有所不同。
售前解决方案架构师
售前解决方案架构师也可以称为客户工程师或销售工程师,他们通常专注于确保自己代表的技术符合客户的用例及其所需的功能,同时帮助客户设计集成系统,或提供最佳应用方案。他们会绘制概要图表、进行探索、确定范围,并在技术协调期间为销售代表提供支持。
售后解决方案架构师
一些售前架构师也负责售后工作,这意味着在完成销售流程并达成交易后,您可以专注于协助实际实施。他们可能只是进行系统总体设计并概述实施过程,或者亲自参与,与技术实施团队一起执行。
软件架构师
软件架构师是一个非常实际的职位,负责构建并经常实施软件解决方案。软件架构师相当于售后人员,通常针对产品或特定技术。软件架构师不一定面向客户。
再次强调,需要澄清的是,每个角色的指定和职责可能因行业而异。
技术共同点
无论哪种类型的架构师,共同点都是技术。架构师天生就是技术型人才,他们能够将技术规范与复杂的安全需求、治理细节、隐私合规与主权以及法律责任联系起来。他们关心的不是具体实现的细节,而是全局。部署管道、堆栈层级、系统级性能、用户管理、位置、基础设施组件……这些才是架构师真正感兴趣并投入精力的事情。
解决方案架构师参与的流程阶段
我现在担任解决方案架构师的角色,并将专注于这个特定的维度,因为软件架构师参与了与软件开发周期相关的过程,而这个过程描述起来要复杂得多。
解决方案架构师通常面向客户,参与并与客户进行大量沟通。他们的主要目标是发现并确定系统需求和/或当前技术状态,以及起草理想状态并确定或建议最理想的解决方案。
发现
SA(解决方案架构师的缩写)参与发现阶段。这是与客户沟通的早期阶段,会提出许多问题。SA 需要全面了解客户、他们的产品或项目、他们的目标以及他们面临的问题,以便将这些信息转化为切实可行的解决方案建议。
发现会议上最重要的技能不是技术性的:解决方案架构师需要能够
- 多听少说
- 做出正确的假设并与客户验证
- 在充分理解所有问题和需求之前不要提出解决方案
- 非常客观
与许多人的想法相反,即使是代表品牌的建筑师,如果认为客户并不需要,也不太可能推行带有偏见的解决方案。这不仅关系到你的声誉,而且大多数建筑师都以推广稳固系统的基础而自豪。
稳固系统的基础
可靠且设计精良的系统具有一些共同的特征。它们都致力于实现可扩展性、稳健性、弹性、可恢复性和安全性等重要特性。架构师还希望他们的系统具有高可用性,有时他们还要求系统能够实现全球分布,而如今,由于云端能够保证全球资源调配,因此这已不再是问题。
范围
需求是用于衡量系统成功与否的记录在案的功能,取决于系统是否得到满足。它们通常与那些基础概念相对应。例如,系统可能需要达到一定比例的正常运行时间(对于关键任务应用程序,通常为 99.995%,即每天约 4 秒的停机时间——您可以在此处计算 SLA https://uptime.is/)。该需求与……相对应High Availability
。
将需求和功能纳入范围的过程也由架构师完成,并且通常(从技术上来说)由客户在某个阶段结合业务目标进行验证。待办事项列表通常是在范围界定过程中直接生成的用户故事和功能需求,以及功能的验证和优先级排序,最终形成发布版本的结果。
我应该关注哪些技术?
这个问题很难回答,因为它很大程度上取决于软件架构师或解决方案架构师正在设计或评估的系统类型,所使用的技术可能千差万别。如果您的目标是成为一名从事 Web 解决方案的架构师,我将重点介绍一些您可能需要了解的技术和专业领域。
云景观
这并不是说没有架构师仍在自我管理环境中工作,但如果您打算加入其中,您可能需要了解三大公共云提供商(AWS、Azure和GCP)是谁,以及他们的产品和拓扑。
您可能还想了解云原生技术,并探索热门和趋势。
此外,了解某些术语以及某些机制在云中的工作原理也非常有用。例如
基础设施和基础设施配置
基础设施的配置实际上并非架构师的职责范围,通常由系统工程师、运维人员或其他角色(具体名称可能因组织而异)完成。然而,架构师可能需要在部署流程执行之前或之后验证或分析部署流程和基础设施的设置,原因如下:
- 成本评估
- 符合架构定义(安全性、性能、技术定义等)
- 风险评估
- 重新配置
尽管基础设施配置(尤其是云中的基础设施配置)依赖于提供商,但您需要了解和理解一些概念。
联网
你需要充分理解互联网的运作方式以及所涉及的各个层面。一些重要的概念和重点领域包括:
- 每种类型的网络层模型(TCP/IP、vLab、ISO/OSI)
- TCP/UDP/HTTP 协议
- SSL、TLS 和其他网络安全概念(防火墙、密钥、VPN、VPC、专用链接、网络对等以及 OWASP 清单)
我强烈推荐大家阅读《计算机网络,一种自上而下的方法》这本书来了解这些概念,我在攻读软件工程学分时必须阅读它,它是该主题最好的书籍之一。
我还建议您下载并安装Wireshark进行数据包嗅探或 TCP 分析,以了解有关段、报头和其他网络概念的更多信息。虽然市面上有更复杂的工具,但这款工具非常适合入门。它是一款开源、免费且功能强大的工具。
硬件
是的,你需要了解硬件。这在决定基础设施配置时尤其重要,如果你发现性能问题,需要进行纵向/纵向扩展或纵向/横向扩展,或者在系统内部扩展时,需要确定具体的规格。以下概念
以及诸如此类的概念
- 大端和小端
除非你真的在数据中心工作,走在机架之间,否则你可能不需要了解电源等其他组件。只需要了解满足软件需求的必要规格即可。虽然我一直建议你了解得越多越好!但你还需要了解:
- 操作系统(ø)
- 虚拟化(大多数服务器实际上是物理服务器上的虚拟机)
- 容器化以及容器化和编排软件(例如Docker和Kubernetes)
(ø) 我不会提供有关计算机物理组件的内容链接,因为来源太多,您只需快速进行谷歌搜索并选择您最感兴趣的内容即可。
我可以给你的一个重要建议是,无论你最喜欢什么操作系统,你可能都需要熟悉 Unix 和类 Unix 系统和架构,并且熟练使用 shell,因为它是远程执行代码、部署包和代码以及访问系统的首选方式。
数据库
随着应用程序越来越以用户为中心,存储和操作数据的任务变得越来越重要。数据存储不仅仅与用于存储数据的软件有关,它还是应用程序成功的关键部分。架构师需要充分意识到
您可能想调查哪种产品对应哪种提供商,并想了解事务和 ACID 合规性等概念
您可能认为我有偏见,但我建议您前往 MongoDB 免费学习平台(又名MonogDB University),那里有大量关于所有这些主题的信息,而且其中很多信息 - 与许多人的想法相反 - 非常客观。
架构模型
显然,建筑师需要了解建筑!而建筑是一个不断发展、充满活力的领域!
你需要熟记这些概念,并了解它们何时是需要遵循的方法。我倾向于认为,一个优秀的架构师就像一个优秀的开发人员一样,永远不会有偏见,他们会努力找到问题的正确解决方案,而不是为了实现一个偏好的解决方案而去寻找问题。
所有这些范例都与软件和技术相关,你可能想探索和尝试一下。例如:
- docker(容器化/虚拟化)
- kubernetes(容器的编排/管理)
- kafka(事件流平台)
- 无服务器函数(很大程度上依赖于提供商,是一种在触发器上执行函数并避免大型后端实现的方法)
不用说,许多提供商将拥有工具和连接器、模块和最佳实践或指南,以根据其基础设施架构和产品实现每种不同类型的模式。
部署管道和发布模型
架构师通常负责设计部署流水线,这往往取决于应用程序的发布模型。如果您正在使用持续集成模式,则可能需要使用 CI/CD 自动化工具来支持它。您应该熟悉以下概念
- 行动
- 触发器/事件
- 基础设施即代码
以及相关软件(同样,选项可能取决于云提供商的选择)
在自动化领域,你可能还需要设计针对不同领域(从代码健全性到性能)执行测试自动化的方法,并且必须了解工具的实现和配置,例如
- SonarQube(代码质量)
- SolarWinds(性能监控或可观察性)等
访问控制和治理
在很多情况下,架构师肯定要对软件/平台安全负责,如果不是对其实施,那么就是对其设计或评估负责。
对于架构师来说,了解控制软件代码库和数据访问的多种方法以及他们设计的应用程序所提供的服务非常重要。
建筑师深知
并且必须了解在应用层和低层实现它们的不同方法。
为了降低风险,架构师最好了解他们的应用程序或平台或他们使用的软件可能面临哪些漏洞。
治理具有多种含义和影响,而且它是如此交叉,我只能将它映射到它可能连接的不同维度。
例如,根据授权粒度设计基于角色的访问是访问治理策略的一部分,而提供设置这些规则的能力的软件功能可确保符合ISO27001或 GDPR 等标准的法律合规性。
API 和应用程序层
大多数现代 Web 开发架构模式都严重依赖 API。架构师负责的软件或平台很可能不仅会使用数十个 API,还会暴露其中一些 API。
不用说,我在文章中提到的 100% 工具都是基于 API 的,云提供商提供的大多数服务也是如此。
因此,架构师需要精通 API 设计和维护,并且非常熟悉以下概念和模式:
- REST API和JSON标准
- GraphQL
- SOAP(虽然现在使用较少,但许多遗留系统仍然使用或公开 SOAP 服务)
- 以及其他 API 替代方案,例如Java Servlets
在您抱怨某些提到的 API 架构的过时之前,请记住,解决方案架构师很多时候会协助迁移遗留系统,为此,他们需要知道他们面临的是什么!
为了有效地设计和维护,甚至评估现有解决方案,架构师了解并实施Open API 规范和Swagger非常有用
架构师需要设计来自所有这些 API 的数据的连接,有时还需要聚合。因此,他们还需要很好地理解如何使用和分发这些数据,并且需要了解以下概念:
在应用程序开发方面,架构师可能不需要知道或了解高级语言的实现细节,但大多数架构师都会这样做,因为很大一部分架构师曾经是开发人员。
高级图表、UML 和其他类型的图表
建筑师用图表说话。相信我。他们常常需要表示非常复杂的系统和关系,而做到这一点的唯一方法就是熟练地用形状和箭头来表示实体。
这就是建筑师学习的原因
建筑师通常负责与客户进行通话,他们需要具备出色的公开演讲和演示技巧:从制作令人印象深刻的幻灯片到用每个人都能理解的语言表达复杂的技术思想。
销售量
一些组织聘请建筑师参与其销售流程,并从技术角度为销售代表和客户提供建议。
这些组织很可能会提供其销售流程和所用方法方面的培训,并加强特定技术或软件的架构师。
我所有的编码技能都会浪费吗?
绝对不是!我可以从个人经验中说,作为一名软件开发人员,我所学到的一切帮助我快速理解系统和决策,分析现有的代码库和配置,并与其他架构师和开发人员建立融洽的关系。有些解决方案架构师需要定期构建 PoC,而你的编码技能不仅有帮助,而且必不可少。
结论
好吧,我知道这已经很长了,而这只是冰山一角!软件和解决方案架构师是一条非常有价值的职业道路,许多开发人员不想转到行政、项目或客户管理职位,而想继续留在技术领域时,都会选择这条道路。
免责声明:我添加了来自相当知名的网站的资源链接,但如果您想贡献更好的资源,请在评论中添加它们!
如果您有更多问题,请在Twitter上联系我,分享和点赞!
文章来源:https://dev.to/this-is-learning/from-developer-to-solutions-architect-a-simple-guide-2b91