Cloud native是一代人中最大的推动者。它让开发人员只需开发。只关注真正重要的东西:创建客户想要(喜欢)的软件使用。
本文从三个方面介绍Cloud-native:
云原生架构:它是什么以及它为什么重要
云原生架构充分利用公共云的分布式、可伸缩性和灵活性,最大限度地集中精力编写代码、创造业务价值和让客户满意。
将云本地化意味着抽象出基础设施网络、服务器、操作系统等的许多层——允许它们在代码中定义。
尽可能多的基础设施(服务器、数据库、操作系统等等!)可以通过运行一个快速脚本在几秒钟内上下旋转。
开发人员所要担心的就是如何协调他们所需要的所有基础设施(通过代码)和应用程序代码本身。
为什么云原生架构很重要?
Cloud native消除了限制,缩短了实现业务价值的路径。
有一个很少被人说出来的事实:唯一真正重要的是你的客户正在与之互动的东西。
你越不必担心代码之外的其他事情,这会给你的业务带来活力,就越好。
这就是cloud native的意义所在。
让我们用一个例子来说明这一点。
假设您的手机银行应用程序的用户反馈表明,用户确实需要账单拆分功能。
在旧世界中,您可能首先想知道如何部署它,需要什么样的网络,要用什么编写它……然后慢慢地想知道真正重要的是什么(代码!客户!)当利基技术问题笼罩在地平线上时,幻灯片就出现在了背景中。
在新的世界里,一个像样的云原生设置消除了对服务器、操作系统、编排层、网络的需要……将代码放在您所做的一切的前面和中心。
你(或你的团队)可以直接尝试。检验假设。实验。
也许这种数据库最适合账单分割功能?还是那个?合并一个机器学习工具怎么样?
任何一种“如果我们这样做了会怎么样…”的问题都可以(几乎)立即在实践中进行测试,为您提供一个数据驱动的答案,您可以在此基础上进行构建。
当你受到基础设施的限制时,你的想法就会被锁定。当你想测试一些东西的时候,你马上就会碰到一堵砖墙:硬件!
无论您提出什么解决方案,都将始终是基于数据中心的局限性的折衷方案。但妥协并不总能赢得顾客!
当云消除了这些限制,而不是专注于技术时,你可以专注于客户体验。想想产品,而不是管道。修复应用程序中的错误,而不是数据库复制。
所有这些都意味着你可以在最快的时间内从一个想法到一个应用。
在一个云端世界,你的想法收集反馈,而不是灰尘!
但是,除了简单的“它让你专注于代码”之外,云原生架构还有很多好处。这就是我们现在要说的。
云原生架构的好处:释放你的想法
我来介绍塔拉。
Tara是一个正在接受培训的开发人员。因为她在云计算的原生世界中长大,她将成为一个很棒的开发人员,而不必知道服务器是如何工作的。
当她了解到在cloud native出现之前人们必须经历什么才能完成他们的工作时,她会感到惊讶。
这就相当于回首过去,想知道当飞行中的计算机只能用穿孔卡片编程时,他们到底是如何成功登上月球的。
Tara将带我们了解云本地架构是如何打开你的想法的!
1. 消除对快速创新的限制
这就是生活的循环。最上面是用户。最底层是Tara和她的团队。
Tara在这个圈子里走得越快,向用户提供功能并获得他们的反馈,想法就越快变成让客户满意的现实。
通过从这个圈子里移除耗时的中转站,CloudNative让Tara比以前更快地穿梭。
还有其他的把戏。一个例子是流量转移:这允许你“切换”(即释放)一个给定的功能给一小部分用户,获得反馈,然后慢慢扩大访问越来越多的用户。
还记得我们上面分钱的例子吗?能够立即测试东西和必须等待购买新数据库(例如)在上市时间上的差异真的加起来了。
这是不同时间尺度的示意图(是的,这有点做作,不一定处处如此,但它说明了这一点)。
在本例中,几天后,Tara和她的团队部署了一个账单拆分功能的原型,并正在收集反馈。在旧世界,她还会一直在等服务器!
试图强迫Tara等三个星期,让一个新的服务器来尝试一个想法,她不会有太大的印象。与此同时,她甚至可能去建立一家竞争对手银行。
2. 拉近与用户的距离
开发人员通常不了解用户真正想要什么。
你在用户和开发者之间设置的每一个过程都是一个地方,在那里,最初的设想可能会误入歧途。
开发团队离客户越近,产品就越好。正如我们所看到的,cloud native的主要好处就是:消除了非以客户为中心的活动。
不过,这更深入了!由于朝着快速创新的方向发展,客户现在期望快速交付MVP,因为他们知道MVP会随着时间的推移而改进。人们并不期望新的应用程序马上就能拥有大量的功能和无bug的体验,但他们确实期望随着时间的推移不断改进。
您的客户还需要小型、快速的发布。它不仅属于神秘的Netflix工程师或编辑CIO.com的人的领域。
客户期望的这种转变可能是永久性的。这对你来说意味着原型现在和产品一样重要。
而且,因为云原生架构允许您向一小部分用户推出功能,所以您可以在实际情况下与实际客户测试原型。不是UAT环境中的测试人员!
这样,Tara就可以得到无可辩驳的证据,证明用户喜欢(比如说)她的新账单分割功能,然后再进一步开发(或放弃)这个想法。
3. 非常便宜而且容易获得新的工具和服务
云原生基础设施的进入壁垒(成本和工作量方面)是尽可能低的。
首先,在云计算中,你只需为你使用的东西付费,不必预先购买任何东西。
(事实上,一些云提供商会允许您免费入门,免费访问某些功能。他们也有有用的价格计算器)
其次,这些云提供商正以疯狂的规模经济进行运营,这意味着您可以访问尖端的基础设施和工具,而在您自己的数据中心部署这些基础设施和工具所需的成本仅为一小部分。
第三,一旦您完成了初始帐户设置,访问云提供商的大量基础设施或工具几乎与从Just Eat订购比萨饼一样复杂(选择配料=>订购=>消费)。
这些优点意味着您可以以最小的成本、风险和精力尝试新的实例类型、数据库、工具以及所需的任何东西。
正是快速创新和实验所需要的。
如果Tara想看看数据库X或Y是否工作得最好。。。她可以随意尝试!或者如果她想测试一个快速脚本?在AWS Lambda上敲五分钟看看。看看机器学习能增加什么价值怎么样?一旦她有了这个想法,她就可以旋转起来玩。
试着说服Tara,她需要经历一个漫长的采购过程,以购买一系列的硬件和工具,她的团队现在必须永远管理…只是为了测试一个想法?
云原生架构的更多好处:云中的透明度、安全性和基于事件的乐趣
云和内部部署之间的一个主要区别是,默认情况下,在云中,发生或更改的所有内容都“存储”为透明记录的事件。
你确切地知道发生了什么(或正在发生什么),何时何地。
这有一些有趣的结果!
1. 基于事件的乐趣实现自动化工作流
默认情况下,云是基于事件的。
这可以让你建立一个令人敬畏的工作流程。就像你在Amazon上搜索“云原生傻瓜”一样,这不仅会立即触发搜索,还会更新你的推荐、搜索历史、你看到的广告等等。这都是基于事件的魔术。
关键是:所有的活动都可以在全球范围内获得!
因此,如果一个团队发布一个事件(例如,有人搜索某物),那么其他团队中的其他人可以开始使用这些事件作为他们自己域中特性的触发器。因此,一个事件可以触发多个反应,每个反应都是由业务中的不同团队为自己的目的构建的。都是完全独立的。
很多魔法。
为了在prem上做到这一点,Tara需要类似于三个不同的Kafka实例和大量精巧的基础设施。
在云端,Tara说:当X事件发生时,做Y。她不必为别的事担心。
2. 透明性和可观察性允许快速解决问题
在prem上运行的服务器是一个黑匣子。
相比之下,云原生技术可以自动记录正在发生的事情,并为您提供漂亮的指标、多彩的仪表盘和自动通知。
因此,Tara可以创建一个无服务器的函数,运行它并在出现问题时通过Slack或SMS发出警报。
这是开箱即用的!
这开启了史诗般的可能性。
如果你写了蹩脚的代码(再多的技术也救不了你……),它可以提醒你问题,并在你意识到问题存在之前解决它们。
如果你是一家银行,而你的客户不能转账,开发团队会在呼叫中心被愤怒的信息淹没之前知道有问题。您的部署可以发布给少数用户,以透明地测试它,并在出现问题时自动回滚,只影响少数客户。
它甚至可以帮助您采取数据驱动或数据科学的方法来进行业务决策。比如说,50%通过Tara电子商务结账的客户实际上并没有完成交易。如果你怀疑(比如说)按钮的位置导致了下降,你可以很容易地做一个分割测试,记录有多少人退房,并制定出最佳的解决方案。
从商业角度来看,这是巨大的。从技术角度来说,这是如此简单(只要你去云原生)。
3. 您可以自动化您的安全标准,以消除快速创新的最大障碍
如果没有安全方面的专业知识,使用on-prem
,您可能会遇到大量的攻击,包括大量的开放端口和防火墙等。根据我的经验,甚至没有人知道哪个端口是开放的,因为跟踪它的电子表格已经四个月没有更新了。
在云层中,更容易使攻击面低得多。例如,如果您创建一个容器或一个ServerLess函数,除非您允许,否则没有人可以访问它。访问管理、角色和策略的声明性特性防止未经授权的个人在不属于他们的地方乱翻。你的云服务提供商处理了大量的安全技术,所以你需要的安全技术就更少了。
您的安全标准可以很容易地在整个基础架构中定义和复制。其他人甚至很容易理解安全性是如何定义的。
这意味着安全配置可以自动部署、测试、监视和报告整个IT产业。不要被人嗤之以鼻!如果您的任何团队试图部署违反这些规则的东西,他们的管道可以识别它,并在造成任何损害之前停止。
通过使安全标准易于使用(对于人和机器而言),您可以立即消除对快速、有效安全性的最大限制,并通过将其转换为自动脚本使其立即可扩展。
它也不再是公司里只有少数人能理解的神秘的黑暗艺术。相反,每个人都知道它是如何工作的,这就打破了责任的孤岛。
毕竟,如果塔拉没有一种保证安全的方法,那么她编码的速度有多快并不重要!
这里有很多话要说。查看法规遵从性和代码的最大好处,以及如何将安全性转移到管道中。
云原生架构的最终目标:快速、数据驱动
最终,您要寻找的最终目标是:
每当有人说“如果……这个怎么办?”
你可以自信地向前冲,回答:让我们试试吧!
发展成为一门科学:你假设、测试、分析数据并总结下一步行动。
销量下降了吗?把按钮留在原来的地方。
销售量增加了吗?为每个人移动按钮!
Tara可以在早上有一个想法,它将在当天下午之前投入生产,而不会影响质量、安全性或性能。
而不是制定一个商业计划,包括她需要多少硬件和它的成本。
但…没那么简单吧?
好 啊。这一切听起来都很棒。但我们知道,在现实生活中,让油轮掉头并不是那么简单。
我们明白了。
但我们之前已经加入了大型组织,并在短短几周内启动了云原生项目。
只用了五个星期,我们就帮助Green旗提供了一个无服务器的云端平台,以摆脱他们遗留下来的技术,为现代救援服务打下基础。
新功能现在可以在不到30分钟的时间内从开发人员转到产品,使用的基础设施更具成本效益。
我们帮助Direct Line Group创建了一个ServerLess的保险初创公司,该公司利用机器学习以个人为基础对待客户。用DLG自己的话来说,它是“为明天而建”:也就是说,围绕着实验而建,这样他们就可以从客户想要的东西中选择方向,并相应地进行调整。
但是一旦你有了你的架构,你会怎么做呢?你还得写代码。下一章让我们来看看如何在云原生环境中开发软件。
原文地址:https://www.contino.io/insights/what-is-cloud-native-architecture-and-why-is-it-so-important
除特别注明外,本站所有文章均为老K的Java博客原创,转载请注明出处来自https://javakk.com/1910.html
暂无评论