Month: January 2018

DevOps 的未来在于掌握多云环境

  DevOps 是一套能将软件开发和各 IT 团队之间的流程自动化的实践组合,通过它可以更快速、更可靠地构建、测试并发布软件。DevOps 的概念是基于 IT 和业务团队之间建立协作文化的前提下,此前两者的职责是相对独立的。这样做的好处是增加信任、加速软件发布,以及提高快速解决关键问题的能力。 也就是说,要想组建一个成功的 DevOps 组织,IT 领导者需要从更广泛的角度考虑如何在他们的团队和更广泛的组织内促进文化和组织转变,而不是仅仅部署新技术。一个成功的 DevOps 战略要求开发团队和运营团队共同关注同一个问题:公司需要采取哪些措施来满足其数字转换目标。因此,要摒弃孤立的团体和职责,将他们原地整合为一支能够在解决技术难题和达成技术目标上胜任多任务处理的团队。 归根结底,一支成功的 DevOps 团队需要所有成员都团结一心,并且都专注于寻求快速持续创新、安全与运营需求之间的平衡。现在,DevOps 自身也在演进,其未来的发展将取决于能否掌握多云生态系统。 在云计算方面,两个趋势日趋凸显: 云服务的日益多样化造就了混合云和多云基础架构 DataOps 的出现对管理数据基础架构的开发人员提出了更高要求 混合云结合了私有云和公共云部署,通常用于执行特定的任务或支持某一特定的应用程序。多云意味着在同一异构 IT 环境中使用两个或多个云管理平台。采用多云的目的在于:最小化数据泄露和丢失、通过冗余减少停机时间、避免供应商锁定,以及增加功能性以满足业务中不同团队的不同项目需求。简而言之,企业正突破混合云,朝向多云领域积极发展。 采用混合云和多云的企业数量日益增加。 一方面,创建和收集的数据比以往任何时候都多。另一方面,更多的用户(从金融到市场,从销售到人力资源等各种岗位)在工作中需要利用这些数据。这给 IT 人员带来巨大压力,他们不仅要管理复杂程度更高的基础架构,还需要赋予更多用户利用数据处理更多事务的能力。这正是 DataOps 的用武之地: “根据所要求的数据起源,将不同来源的数据进行组织并确实交付至众多用户,以支持可重复数据流。” 因此,针对这些新应用程序的部署和协作过程,公司需要制定专门的 DevOps 策略。任何组织使用的 DevOps 工具都必须具备将代码可靠地部署到公共云、私有云、混合云,以及 Google、HPE、Amazon Web Services 等全球知名服务提供商的能力。 DevOps 要时刻走在行业最前沿 长久以来企业公司在云计算方面的竞争一直给 DevOps 团队带来巨大压力。但多云计算将这种压力提升到一个全新的强度。DevOps 团队需要提高敏捷性,并增强扩展性。要更广泛地落实持续集成和持续发布这样的概念和方法,而且,要让自动化发挥更大作用。 然而,在多云环境中掌握 DevOps 的意义不止是速度更快、效率更高。举例来说,增加云环境运行时间容易产生问题。相比之下,构建源生云应用程序更合适。传统的应用程序趋向于单一化,以 VM 的形式运行,使用向上扩展架构,并且通常开发、部署和维护难度更大。相对而言,源生云应用程序更加模块化,并且更注重以服务为导向,由容器和服务的集合组成,基于横向扩展架构,并且易于自动化、迁移和扩展。如果您还没有在云中执行 DevOps,那可要抓紧时间跟上潮流;因为是否为“源生云”将至关重要。 将 DevOps 从单一云或混合云迁移至多云世界还需要新的平台和工具。在此,我们所指的是要积极采用行将迅速改变游戏规则的各项技术。 […]


Apache Beam in 2017: Use Cases, Progress and Continued Innovation

This blog was originally published by Anand Iyer & Jean-Baptiste Onofré [@jbonofre] on the Apache Beam blog.  On January 10, 2017, Apache Beam (Beam) got promoted as a Top-Level Apache Software Foundation project. It was an important milestone that validated the value of the project, legitimacy of its community, and heralded its growing adoption. In the past year, Apache […]


How APIs, Edge Computing and AI will Evolve in 2018

  If you’ve spent any time reading the round-up of 2018 technology predictions, you’ve likely seen Artificial Intelligence (AI) highlighted in nearly every one. The reason for this is because AI has a seemingly limitless number of applications and use cases for the enterprise. In fact, according to Gartner, over 85% of customer interactions will be managed without […]


2 Key Takeaways from the 2017 Gartner Market Guide for Data Preparation

The recently released 2017 Gartner Market Guide for Data Preparation ([1]) estimates that Data Preparation is well on its way to a $1B market, quickly growing from around $780M in 2016. The analyst firm’s Market Guide series is meant to cover new and emerging areas where software products and organizational requirements are still being defined for what Gartner would […]


Talend Integration Cloud 101 – SDLC and Code Promotion Pipeline

  Talend Integration Cloud puts powerful graphical tools, prebuilt integration templates, and 900+ connectors and components at your fingertips to connect databases, big data sources, on-premises, and cloud applications. This enables faster design of cloud-to-cloud and hybrid integration workflows in Talend Studio and the ability to publish them to a fully managed cloud. Once a […]


Talend 成功之道

  熟悉我先前 Talend 博客 读者或许已经注意到,我常常论及通过设计模式和最佳实践来构建更好的解决方案。我的博文也往往篇幅较长,在此向愿意拨冗浏览的读者致以谢意。本文将重点关注适用于 Talend 解决方案的方法论。希望最后大家达成这样的通识:任何成功的 Talend 项目都应当运用恰当的方法,否则项目必然难逃败局。 圆凳需要三条腿才能站稳,对吧?我认为可将软件开发项目比作这样的圆凳,同样需要三条凳腿,分别定义如下: 用例 – 解决方案明确定义的业务数据/工作流要求 技术 – 我们创建、部署和运行解决方案的工具 方法 – 业界公认的行事方式 软件项目通常只关注用例和技术堆栈,往往会忽略方法。在我看来这是一种错误的认知,也是事倍功半乃至无功而返的根源。在规划成功的 Talend 项目时,应以将最佳实践纳入作业设计模式 (JDP&BP) 以及 数据模型设计 (DMD&BP) 作为基本目标。在众所周知的圆凳方法论当中,这些原则恰如相应的凳腿。我在 JDP 和 BP 博文中探讨了一些基本的规则,其中一致性或许是最为重要的普适性规则。原因很简单:即使您是做事的方式有问题,或者说得更委婉些,方式不够恰当,那么后续若还沿用相同的方式,纠正起来便会更容易。我对此深以为然,因而认为成功的方法应当包含一致性。 成功的三大支柱 我们下面进一步详述。以凳腿来类比成功支柱,每个支柱各司其职,共同服务于更大的目标。软件并不神奇,应当理解自启用到停用的演变过程和生命周期,这是成功实施的基础。严谨的开发者很少忽略这一点,但往往屈服于业务压力,而大多数情况下,所运用的方法受到影响最大。由于将其弃之不顾,隐藏的长期成本会急剧上升。最严重时可能导致项目全盘失败,即便是最好的情况,也可能造成项目质量不如人意,缺乏竞争优势和/或延长交付周期。 因而我们需对此认真以待。以下是要考虑的启动概要: 可根据需要进行修改;具体情况各不相同,但要求大多类似。我们接下来继续探讨。 何谓成功之道? 成功的方法无非是得到真正采纳并付诸实践,仅此而已。当软件项目团队应用某种方法论时,便也知晓如何统筹规划以实现预期结果。如果缺少适当定义及采行的方法论,多少有些像西部电影或“打哪儿指哪儿”的场景那样随性,窃以为对于软件项目将毫无助益。方法论作为第三条凳腿必不可少。 谈到方法论,人们可能会洋洋洒洒涉及众多话题。不过本质而言,讨论首先应侧重于规划软件项目的设计、开发、发布、部署和维护。 这一环节通常称为 “软件开发生命周期 ” 简称 SDLC,多数情况下是在设置、管理、协调和测评所需资源、重要里程碑和实际可交付成果方面要迈出的第一步。很多读者已经了解两种最常见的 SDLC 方法: 瀑布式 – 严格规定的步骤(阶段),可划定整个软件结果范围 敏捷式 – 灵活的迭代方法(冲刺),可优化早期结果 JEP+ – 一种混合型“最佳”方法,包含所有重要内容 如果没有 SDLC 方法,我认为相比因误导、错误配置、结果出错导致未达到原定目的而产生的成本,原先所设想的省去这项工作(是方法也是工作)而带来的节约只能说是得不偿失。软件失误代价几何?无需具体到数字,必然十分巨大。因此首先要选择一种适合的 SDLC,并将方法落到实处。道理显而易见。敏捷开发似乎已成为整个软件行业通行的标准,不妨以此为起点。两种方法论基本任务相似,只是具体方式有所不同。本文不会深入研究这些问题,仅就两个不可或缺的方面进行说明。 瀑布式 SDLC: 瀑布式 […]