我们与28位分别来自23家企业的高管人员进行了交流&＃xff0c;希望了解这些负责立足于云环境进行应用程序开发与部署的技术领导者如何看待相关议题。
当被问及“开发人员需要在处理云应用时注意什么?”时&＃xff0c;各位企业高管人员给出了以下意见与建议&＃xff1a;
应用程序性能管理应该分为主动与被动两类&＃xff0c;特别是在面对开发与生产等不同场景的情况下。我们需要在开发阶段获取更多测试信息。APM工具将帮助我们在应用直接触及生产环境前对其加以测试&＃xff0c;并有效缩短产品进入生产环境并被交付至用户手中的周期。
了解应用程序的十二因素。如何对应用程序中的服务进行远程消费?了解其中的关联性是解决问题的关键所在。
开发人员应当保持云中立性。所有应用程序都需要具备可移植能力。对于高级应用程序&＃xff0c;我们需要将云因素排除在设计蓝图之外。在编写应用时&＃xff0c;保持其云中立特性、构建通用API并封装特定的云依赖关系。大家不要假定使用某种特定虚拟机。为应用选定运行区域&＃xff0c;这对安全性非常重要要。不过VCenter不具备分区特性&＃xff0c;因为其主要面向私有云所构建。我们需要在设计之初考虑到这些前提。如果大家打算面向公有云进行应用开发&＃xff0c;则需要利用微服务实现规模扩展——即考虑单一服务规模所带来的多重影响。沙箱属于Amazon以及V Container接口的缩影&＃xff0c;大家可以借此了解二者之间的冲突点所在。
跳出固有思维&＃xff0c;因为老派开发人员采用的方法往往无法适应当前需求。了解业务需求与客户需求&＃xff0c;并为问题提供最为简单的解决方案。针对需求进行实现方法定制。保持统一的发展愿景&＃xff0c;同时着眼于目标及需要解决的问题进行知识共享(使用JetBrains中的UTrack以及JIRA实现协作&＃xff0c;尽可能提高社交水平)。大家需要通过添加简化要素尽可能降低应用复杂度。
积极动手。选定一款简单应用&＃xff0c;然后立足于AWS进行构建——这也正是AWS的最大价值所在。API与使用指南都是学习云服务相关知识的绝佳途径。
考虑应用何时需要进行规模扩展&＃xff0c;应用中的哪些组件需要进行规模扩展。立足于容器架构实现诸如登录等功能&＃xff0c;从而建立共享式应用。必须保证自己具备按需扩展的能力。审视使用模式并考虑不同类型的用户是否应当采用同样的使用模式。了解我们不希望亲手构建的部分——换言之&＃xff0c;了解我们可以直接使用哪些后端即服务选项(例如API网关以及数据管理服务)。了解哪些元素可以具备云服务供应商锁定特性在&＃xff0c;则哪些能够帮助我们在市场上获取差异性优势。
利用逻辑、数学与艺术手段构建用户界面——同时使用各类更为先进的编程语言。利用自己的技能对应用做出转型。寻找一位导师&＃xff0c;在其帮助下打下坚实的专业知识基础&＃xff0c;这些都将在未来起到重要作用。另外&＃xff0c;在工作中保持激情。
利用黑客马拉松活动实现快速高效的应用开发。认真审视安全性。鼓励开发人员与软件团队参与黑客马拉松&＃xff0c;从而快速构建应用程序并提供更出色的用户体验。部署前快速发现问题&＃xff0c;而非完全依赖于测试部门。
考虑哪些组件可以发生故障&＃xff0c;利用AWS与GCQ启动对应实例&＃xff0c;直接查看哪些组件正常起效而哪些遇到了问题。持续测试并了解开发成果的实际执行效果。
不要对应用程序的运行位置进行假设。保证所构建的应用能够运行在任意环境当中。从起步阶段将安全考量纳入开发流程。构建抽象机制&＃xff0c;从而保证应用可由一种云环境迁移至另一种当中。不要过度依赖于单一云环境或者技术方案。
安全性——关注最为重要的方面&＃xff0c;特别是隔离各租户的数据并保护敏感数据。
可扩展性——必须有能力在特定时间段内处理峰值资源需求。
成本控制——优化应用程序以实现成本效益&＃xff0c;由于公有云资源在进行性能与扩展性优化时成本较高&＃xff0c;这一点也变得愈发重要。基础设施成本如今主要由软件厂商而非客户承担。
日志记录——最重要的是能够调试问题并捕捉一切与故障相关的信息&＃xff0c;从而在尽可能无需客户协助的前提下实现问题修复。
可部署性——SaaS的一大重要优势在于能够随时实现快速部署。我们的架构必须能够处理实时部署&＃xff0c;从而轻松应对客户直接可见的零宕机时间效应。
多租户——这一点对于内部环境开发人员而言最难解决&＃xff0c;因为此类应用并非面向防火墙后的单一客户所构建。
自动化——底层基础设施必须以自动化方式实现设施部署与扩展性调整&＃xff0c;且无需大量人为介入。
了解如何利用特定指南资料实现模式设计。云环境下的设计模式往往缺乏充足的说明素材&＃xff0c;从业者对其亦理解不深。我们需要率先考量模式相关问题。对设计模式进行抽象化处理&＃xff0c;从而确保我们始终参与其中并由此实现职业生涯积累。在了解到基础模式之后&＃xff0c;大家可以逐步体会更为复杂的执行模式。不要重复过去犯过的错误。很多人都从阅读说明文档开始学习。事实上&＃xff0c;观察他人的工作成果&＃xff0c;掌握他人的工作经验并阅读博文以及在线资源等都是很好的学习方式。很多企业已经开始公开讨论其云架构。大家不妨观察十家不同企业所使用的架构与实现模式。这将帮助大家在构建自己的解决方案时拥有更为开阔的思路。
不要忘记&＃xff0c;云环境是一套非常强大的开发平台。充分利用云与其它各类资源。利用云服务实现快速迭代、频繁部署并最终打造出高质量应用。
可扩展性与安全性。开发人员需要从起步阶段认真思考安全性需求。将零宕机时间作为前提性目标。
性能与指令。尽可能在代码中添加指令&＃xff0c;从而简化未来的故障排查工作。数小时的服务宕机有可能带来数百万美元损失。了解APM配置并构建修复指令。另外&＃xff0c;在性能层面确定哪些状况可以接受&＃xff0c;而哪些绝对不能接受。
脱离应用本身从技术层面审视V5原则。服务器架构正是我们的指向目标(例如Amazon Lambda——其中包含一段代码&＃xff0c;在被调用时会运行Nano服务)。
目前已经有大量平台开始引入众多业务功能&＃xff0c;这意味着我们可以借此创建预测模型&＃xff0c;同时定义业务算法并为预测模型提供分析素材。立足于开发领域的知识&＃xff0c;并将其与抽象思维结合起来。Google Tensor Flow、Google Now以及微软目前都开始提供开源机器学习服务。大家可以考虑如何利用这些新成果解决问题。
考虑到越来越多的应用遭受黑客攻击&＃xff0c;我们需要始终将安全性作为关注重点。安全性与可靠性可谓相互依存。确保应用具备应对流量峰值以及长期发展所需要的扩展能力。尽快帮助客户从应用中获取价值。
了解当前可供使用的各类工具。着眼于规模化及性能水平进行应用设计。预测可能发生的变化。着眼于产品的当前作用&＃xff0c;并预测其如何与企业环境下的其它产品进行集成。保证应用具备可扩展能力。将安全性引入其中&＃xff0c;否则我们的应用将无法通过合规审查。将用户体验视为设计工作的核心。
自动化与验证机制。如果大家在云应用中使用现代工具方案&＃xff0c;但却发现其并不适应当前实际需求&＃xff0c;那么请果断将目光转回较为陈旧的实现模式。通过互联网了解其它厂商的实际作法。尽可能利用开源工具实现大规模迁移(例如Netflix)。通过这种方式&＃xff0c;大家将获得出色的思维方式与解决方案。
安全性为先&＃xff0c;保证应用中不存在可被利用的漏洞。坚持使用多租户环境以实现规模化成本效益。
开发者与DevOps团队需要以云原生角度理解应用程序&＃xff0c;而非服务交付方式。很多工具内置有大量功能&＃xff0c;但往往并不切合我们的实际需求。因此大家应当进一步学习与性能表现、用户体验以及面向最终用户的应用服务效果相关的知识。了解应用是否可用且是否具备用户友好特性。掌握应用依赖性与可扩展性。与DevOps及运维团队交流&＃xff0c;从而了解代码成果的实际运行情况。
大家对于开发人员处理云应用的方式这一议题又有哪些观点?请在评论中与我们分享。
本文转自d1net&＃xff08;转载&＃xff09;
京公网安备 11010802041100号