- 序言
- 云原生
- Kubernetes 架构
- Kubernetes 中的网络
- Pod 状态与生命周期管理
- 集群资源管理
- 控制器
- 服务发现
- 身份与权限控制
- 存储
- 集群扩展
- 资源调度
- 用户指南
- 资源对象配置
- 命令使用
- 集群安全性管理
- 访问 Kubernetes 集群
- 在 Kubernetes 中开发部署应用
- 最佳实践概览
- 在 CentOS 上部署 Kubernetes 集群
- 生产级的 Kubernetes 简化管理工具kubeadm
- 服务发现与负载均衡
- 运维管理
- 存储管理
- 集群与应用监控
- 分布式跟踪
- 服务编排管理
- 持续集成与发布
- 更新与升级
- 领域应用概览
- 微服务架构
- Service Mesh 服务网格
- 大数据
- Serverless架构
- 边缘计算
- 人工智能
- 开发指南
- CNCF
- 附录说明
云原生编程语言
以下内容来自Joe Duffy的博客,Hello, Pulumi!。他说这些是为了说明为什么要创造Pulumi,在此我引用它说明为什么会有云原生编程语言。
对于每一个serverless函数来说,我都要写几十行的JSON或者YAML配置。要链接到一个API端点,我还要学习晦涩的概念,执行一系列复制-粘贴的低级工作。如果我想在本机上运行一个小的集群的话,那么Docker还是很棒的,但是如果要在生产上使用的话,那么就要手动管理etcd集群,配置网络和iptables路由表,还有一系列与我的应用程序本身不相干的事情。不过Kubernetes的出现至少让我可以配置一次下次就可以跨云平台重用,但这还是会分散开发人员的精力。
我认为我还算一个经验丰富的工程师,已经在软件行业从业20年了,但是当我想要将自己的代码部署到云中的时候,我感觉自己就像是个傻子。真是太令人悲哀了!如果我掌握了这些能力,那么是世界就会出触手可及。我总是在淌这浑水,处理云的复杂性,而我真正想做的是花时间来创造业务价值。
关于编程的许多方面都经历了类似的转变过程:
- 在80年代初,我们使用汇编语言对微处理器进行了编程。最终,编译器技术进步了,我们可以同时处理多种常见的架构。像FORTRAN和C这样的Low-level的编程语言开始兴起。
- 在90年代初期,我们直接针对低级别操作系统原语进行编程,无论是POSIX系统调用还是Win32 API,并进行手动内存和资源管理。最终,语言运行时技术和处理器速度提升到了可以使用更高级别语言的状态,如Java。除了动态语言之外,这种趋势已经加速,如JavaScript统治了Web。
- 在21世纪初期,我们的编程模型中的共享内存并发性最好是原始的(我花了很多时间在这个问题上)。现在,我们简单地假设OS具有高级线程共享、调度和异步IO功能,以及编程到更高级别的API,例如任务和承诺。
我相信云软件也在进行类似的转变。从构建单一应用程序到构建真正的云优先分布式系统,我们正处在一场巨变中。然而,当海啸发生之前,人们几乎不知道它正在发生。
从上面的角度来看,使用“配置”情况是有道理的。在虚拟机的早期,我们利用现有的应用程序并将它们扔在栅栏上,以便有人添加一点INI或XML粘合剂,让它们在虚拟机内部运行,以实现更灵活的管理。随着我们将这些相同的虚拟机“提升并转移到云中”,这种配置方法一直伴随着我们。这将我们带到了大致正确的边界。
使用这种相同类型的配置表示基于容器的微服务、serverless和细粒度托管服务之间的关系导致了异常的复杂性。将应用程序转变为分布式系统应该是事后的想法。事实证明,云覆盖了您的架构和设计。表达架构和设计的最好的方式是使用代码,使用真正的编程语言编写抽象,重用和优秀的工具。
早些时候,Eric和我采访了几十个客户。我们发现,开发人员和DevOps工程师都普遍感到幻灭。我们发现了极端的专业化,即使在同一个团队中,工程师也不会使用同一种语言。最近几周我已经听到了这个消息,我期待有一天会出现NoYAML运动。
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论