把握行业变革关键节点,12 月 19 日 - 20 日,AICon北京站即将重磅启幕! 了解详情
写点什么

微软世界中的 S+S

  • 2008-01-29
  • 本文字数:1852 字

    阅读完需:约 6 分钟

最近, David Chappell 发表了一篇名为《微软世界中的 S+S 》的白皮书,抛开微软是这份白皮书的赞助者这一背景不谈,对于那些想要了解微软提出的“S+S”战略的人来说,它倒是一份理想的材料。白皮书的副标题是“写给 IT 决策者的技术总览”,很显然这篇论文有一定的针对性。

微软是创造新名词的行家里手,这样做的目的往往更多的是出于市场方面的考虑。通过新名词,一来可以迅速的吸引众人的眼球,二来也可标榜自己与他人的不同,彰显企业的个性。至于其技术内涵,反倒被放在了第二位。无疑,微软的“S+S”又走上了以前“微软制造”的老路。很少有人能清楚地说明白微软的“S+S”战略到底是什么,认为“S+S=SaaS”的人恐怕不在少数,甚至有人认为 S+S 就是另一种形式的 RIA (注:见该文的评论)。面对媒体,微软对“S+S”的宣传内容也显得空泛,离确保该战略成功的执行层——第一线的开发人员——很远。

名词的制造者不一定是最佳的诠释者,在 COM 时代 Don Box 就已经为我们示范了一个先例。如今,David Chappell 又为我们贡献了一个样板。微软赞助这份白皮书的原因显然是为了更好地向技术人员普及“S+S”。微软这样做已经不是第一次了,在.NET 刚面世的那段日子里,微软就用过类似的手法——花钱请人撰写.NET 相关的技术文章。

从白皮书的内容来看,David Chappell 出色地完成了这项任务。文章的内容主要包含 3 部分内容:

  • S+S 介绍
  • 进一步了解服务
  • S+S 中的应用平台

对于那些急于了解“S+S”的人来说,白皮书的第一部分是一个非常好的起点。David Chappell 如此定义“S+S”:

……,S+S 的真实含义变得清楚起来:第一个“S”指的是内部(on-premises)软件——完全受控于使用它的组织的软件,第二个“S”即 SaaS。

“内部软件”并不是什么新鲜事物,它运行于组织内部(不一定是同一物理地点),要么是购买的成品软件,要么就是自行开发的系统。很明显,从这个定义上看,微软并不打算放弃在其收入比重中占有明显优势的软件业务,同时由于 SalesForce.com Google Amazon 等这类新型软件服务提供商的兴起,使得微软又一次将目光瞄上了 SaaS。如果你认为微软就此止步,那就大错特错了。作为平台提供商的微软深知平台的力量,在“S+S”战略中,应用平台同样也有其重要的位置:

无论如何,没有明显的理由说明这两种平台(注:内部软件平台和 SaaS 平台)应该显著的不同。事实上,很容易的想到有朝一日这些技术会聚合在一起。假使有一个对内部(on-premises)和 SaaS 环境都适合的单一平台,企业就可以在需要的时候移动应用程序。正如以后所描述的,微软正打算这样做,为内部(on-premises) 和 SaaS 应用提供单一的平台技术。

接着,白皮书从提供服务和服务计费两个方面对服务进行了进一步的说明。其中:

  • 提供服务
    • 定位消费者:企业用户还是普通消费者。前者是付费用户,使用高级功能,且一般有明确的 SLA(服务水平协议);后者是免费使用,使用大众功能,一般没有明确的 SLA(但是有隐式的 SLA。如果服务的质量不好,即使免费也不会有人使用)。
    • 选择实现风格:单租户还是多租户。前者是为每个客户起一个服务实例;后者则是多用户共享一个服务实例。
  • 服务计费,一般采用按使用功能付费的形式。

在最后一部分,白皮书以微软的 BizTalk 为例,说明了“S+S”中的应用平台的情况。对应“S+S”的定义,平台类型分为两种:(内部)软件平台和 SaaS 平台。软件平台,微软已经相当成熟,而目前努力的方向则是 SaaS 平台。白皮书明确区分了 SaaS 平台和可编程服务,其中最大的区别莫过于前者可以运行客户自己创建的软件,客户创建的应用在服务提供商处运行;而可编程服务只能被客户软件调用。最后,白皮书道出了微软的“S+S”战略中应用平台的愿景:

通过在两个平台提供相似的 API,开发人员在创建应用时,可以无需事先考虑它是否是内部运行或是作为服务运行。一个应用可能一开始是本地运行的,然后为了获得更大的容量和更低的成本转而移到一个服务提供商处运行。

作为微软赞助的白皮书,不可避免地会具有一定的倾向性。但是,通观全文并没有发现明显的贬低竞争对手,抬高自己的内容。而且文中所提的软件和 SaaS 并存的观点,在目前看来也确实具有其现实意义。值得注意的是,作为靠平台起家的微软,在“S+S”战略中也没有忘记对平台的控制,只是这一次它的野心要更大一些——创建一个适用于软件和 SaaS 的公共平台。这对于微软平台的 ISV 来说,无疑是个利好。这使得他们现有身份不变的同时,还有机会以较低的成本成为 SaaS ISV。面对微软联盟咄咄逼人的气势,其他联盟该如何反击呢?或许,这只是市场重新洗牌的开始。

2008-01-29 10:351357
用户头像

发布了 255 篇内容, 共 68.3 次阅读, 收获喜欢 10 次。

关注

评论

发布
暂无评论
发现更多内容

如何理解鲁棒性?为什么robustness会翻译为鲁棒性?

九章云极DataCanvas

TiDB Operator高可用配置

TiDB 社区干货传送门

集群管理 管理与运维 安装 & 部署

TiDB 生产集群与加密通讯TLS的辛酸苦辣 - 工具篇

TiDB 社区干货传送门

集群管理 管理与运维 备份 & 恢复

【社区智慧合集】TiDB 相关 SQL 脚本大全

TiDB 社区干货传送门

PyFlink 最新进展解读及典型应用场景介绍

Apache Flink

大数据 flink 实时计算

收官!OceanBase第五届技术征文大赛获奖名单公布!

OceanBase 数据库

数据库 oceanbase

企业真的需要一个私有化的即时通讯吗?

BeeWorks

Vue实现登录功能

Geek_7ubdnf

Vue

版本控制 | 设计师和美术人员的理想版本控制软件是?

龙智—DevSecOps解决方案

版本控制 版本控制软件

OpenMLDB v0.7.0 发布

第四范式开发者社区

人工智能 机器学习 开源 特征 数据库·

35张图,直观理解Stable Diffusion

OneFlow

人工智能 深度学习 Stable Diffusion

企业移动应用APP是否能实现统一整合与管理呢?

BeeWorks

Getaverse入选KuCoin Labs首批孵化项目

Geek_Web3

#区块链# 元宇宙 web3

代码质量与安全 | 展望:2023年商业软件开发的五大关键目标

龙智—DevSecOps解决方案

静态代码分析

【Unity渲染】一文看懂!Unity通用渲染管线URP介绍

3DCAT实时渲染

Unity 渲染 实时云渲染 渲染服务 Unity3D

TiDB Operator升级

TiDB 社区干货传送门

实践案例 集群管理 管理与运维 安装 & 部署

2022年IAA行业品类年度表现总结

易观分析

视频 IAA

JDBC的基本概念

Geek_7ubdnf

Java

【UE虚幻引擎】手把手教学,UE新手打包全攻略!

3DCAT实时渲染

游戏开发 虚幻引擎 虚幻引擎5 UE5 游戏开发引擎

Hackathon特别策划 | 72小时灵感冲刺,创意就该这么玩

LigaAI

敏捷开发 研发管理 hackathon 黑客马拉松 企业号 1 月 PK 榜

互联网医疗月度观察:规范化、合法化的网络售药新时代到来

易观分析

互联网医疗

软件测试/测试开发 | 静态扫描体系集成

测试人

软件测试 持续集成 jenkins 自动化测试 测试开发

【1.6-1.13】写作社区优秀技术博文一览

InfoQ写作社区官方

热门活动

软件测试/测试开发 | 单元测试体系集成

测试人

软件测试 单元测试 自动化测试 JUnit 测试开发

通过TiDB Operator升级TiDB集群

TiDB 社区干货传送门

集群管理 管理与运维 故障排查/诊断 安装 & 部署 扩/缩容

【从零开始学爬虫】采集丁香医生新冠问答数据

前嗅大数据

数据采集 爬虫教程 爬虫案例 爬虫工具 爬虫技术

微信小程序实验案例:简易成语小词典

TiAmo

小程序 微信小程序

火山引擎DataTester:一次A/B测试,帮助产品分享率提升超20%

字节跳动数据平台

大数据 AB testing实战

TiCDC 集群工作过程解析

TiDB 社区干货传送门

岁末年初再添佳誉丨Kyligence 荣获多个奖项及榜单认可

Kyligence

数据分析 多维数据库

Inspur KOS 龙蜥衍生版面向智慧新媒体转型的探索与实践 | 龙蜥案例

OpenAnolis小助手

龙蜥社区 CentOS迁移 浪潮信息 KOS 服务器操作系统

微软世界中的S+S_SOA_胡键_InfoQ精选文章