API也就是我们常说的应用程序接口,是以编程语言提供的结构,允许开发人员更容易地创建复杂的功能。它们抽象出更复杂的代码,并提供一些简单的语法来使用。
而微服务架构是一项在云中部署应用和服务的新技术。微服务不需要像普通服务那样成为一种独立的功能或者独立的资源。定义中称,微服务是需要与业务能力相匹配。微服务作为一项在云中部署应用和服务的新技术已成为当下最新的热门话题。但大部分围绕微服务的争论都集中在容器或其他技术是否能很好的实施微服务,我们认为API应该是重点。
本文主要讲的是如何让企业高管了解API和微服务的价值,如何将单一的遗留应用程序转换成微服务和API以及如何围绕API和微服务组织团队?
一、如何让企业高管了解API和微服务的价值?
主要有两种方式。首先,一般很少有企业高管了解API和微服务平台的投资商业价值,因此很少有人能够成功地理解API和微服务架构的抽象价值。尽管如此,大多数人还是都能理解相互依赖的商业投资策略。在这种情况下,需要高于单个项目的分析,来确定可能推动业务变化的已知业务变更计划组合和激发这些变化的行业压力。评估并比较在有或者没有API和微服务的情况下,响应这些变化的成本和时间价值。
换句话来讲,要将对话提升到项目组合级别,因为这是API和微服务协同效应所发挥出最大影响力的地方,并以业务变更投资术语(而不是架构价值术语)进行对话。其次,一些业务计划蕴含内置的API价值,可以把这些价值单独出售。例如,如果一个公司