云原生并不是指应用所在位置,而是指其构建和部署方式。
在“什么是云原生?”视频中,Andrea Crawford 概述了一些关键概念:
微服务(也称为微服务架构)是一种架构方法,单一应用由许多松散耦合并且可独立部署的小型组件或服务构成。 这些服务(也称为微服务)通常具有自己的技术栈,包含数据库和数据模型,并且通过结合使用 REST API、事件流和消息代理彼此通信。
因为微服务可独立部署和重新部署,而不会影响或中断最终用户的体验,因此对于自动化迭代式交付方法(如持续集成/持续部署 (CI/CD) 或 DevOps)而言,微服务是绝配。
除了用于创建全新的云原生应用外,微服务还可用于对传统的单体式应用进行现代化改造。
在 IBM 对 IT 高管、开发高管和开发人员进行的一项调研中,87% 的微服务用户同意,为采用微服务而花费精力和成本是物有所值的。
开发人员通常在容器内部署微服务;容器作为可执行的轻量级应用组件,结合了应用源代码(在本文所讲述的情况下,是微服务代码)以及在任何环境中运行这些代码所需的所有操作系统 (OS) 库和 依赖项 。 容器是现代云原生应用的事实 计算单元,与虚拟机 (VM) 相比,体量更小,资源效率更高,可移植性更好。
容器通过在混合多云环境(公有云、私有云和本地基础架构)中实现统一的部署和管理体验,放大了微服务的优势。 但随着云原生应用的激增,容器及其管理复杂性也与日俱增。 使用容器化微服务的大多数组织还使用容器编排平台(如 Kubernetes),以大规模自动执行容器部署和管理。
IBM 客户发现,自己需要投入越来越多的精力,以改进现有应用,构建新应用以及增强用户体验。 云原生应用通过提高应用性能、灵活性和可扩展性,满足了这些需求。
优点
缺点
云原生应用通常具有相当具体的功能。 可以设想一下云原生应用如何用于旅行网站。 网站所涵盖的每个主题(包括航班、酒店、租车、特别活动)都是一个微服务。 每个微服务都可独立推出新功能,而不会影响其他微服务。 特别活动和折扣也可以独立扩展。 虽然旅行网站作为一个整体呈现给客户,但每个微服务保持独立,可以根据需要进行缩放或更新,而不会影响其他服务。 以下是其他云原生应用的几个示例。
IBM Cloud Garage 为 IBM 客户提供咨询专业知识,帮助他们快速构建可扩展的创新型云原生应用。 它提供创新中心,可供所有规模的企业用于设计和构建应用以满足现实世界的业务需求。
无论是创建新的云原生应用还是对现有应用进行现代化改造,开发人员都须遵循一组统一的原则:
云原生应用通常依赖于容器。 容器的吸引力在于非常灵活、轻便而且可移植。 早期使用容器的用户往往侧重于无状态应用,无需将用户数据从一个用户会话保存到下一个用户会话。
但是,随着越来越多的核心业务功能移至云端,必须在云原生环境中解决持久存储问题。 这就需要开发人员考虑采用新的方法来处理云存储。
正如云原生应用开发采用微服务和模块化方法,在存储方面也必须使用云原生存储。 云原生数据可能位于任何位置 — 如事件日志或系统日志、关系数据库以及文档或对象存储。
数据位置、保留时间要求、可移植性、平台兼容性和安全性仅仅是开发人员在规划云原生存储时必须考虑的几个方面。
支持云的应用最初开发时是为了在传统数据中心内部署,但后来改为在云环境中运行。 而云原生应用是只为在云中运行而构建的。 因此,云原生应用具有可扩展、独立于平台以及由微服务组成等特点。
在云计算的短暂历史中,“云就绪”的含义已发生多次变化。 最初,该术语适用于旨在通过互联网工作的服务或软件。 而现在,它更常用于描述在云环境中工作的应用,或已针对云环境重新配置的传统应用。 术语“云原生”的历史要短得多,是指从一开始就是为了仅在云中运行以及为了利用云架构的特点而开发的应用,或已使用云原生原则重构和重新配置的现有应用。
基于云的服务或应用通过互联网交付。 字面上它是适用于任何云产品的通用术语。 云原生则是更具体的术语。 云原生描述旨在云环境中工作的应用。 该术语表示依赖于微服务、持续集成和持续交付 (CI/CD) 并可通过任何云平台使用的应用。
云优先描述的是业务战略,组织承诺在推出新的 IT 服务、更新现有服务或取代原有技术时优先使用云资源。 成本节约和运营效率推动这一战略的发展。 云原生应用与云优先战略完美匹配,因为它们仅使用云资源,并且旨在利用云架构的有益特性。