AICon 上海站|日程100%上线,解锁Al未来! 了解详情
写点什么

微软世界中的 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:351089
用户头像

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

关注

评论

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

四、《图解HTTP》- 状态码

懒时小窝

HTTP 状态码 图解https

六、《图解HTTP》- 用户身份认证

懒时小窝

HTTP 图解https

Java将PDF拆分为多个 PDF 文件

在下毛毛雨

Java PDF 拆分PDF

N、《图解HTTP》读书笔记 - 附录

懒时小窝

资料 图解https 参考数据

【SimpleFunction系列二.3】Redisson分布式锁8种锁模式剖析

莫逸风

分布式锁 redisson 分布式锁

Linux实用命令lsof命令

flow

8月月更

私有化输出的服务网格我们是这样做的

阿里巴巴云原生

阿里云 Kubernetes 云原生 服务网格

GitLab 自动删除项目?仅需四步,丝滑迁移至极狐GitLab

极狐GitLab

git DevOps gitlab 敏捷开发 极狐GitLab

C#/VB.NET:在不同Excel工作簿之间复制单元格区域和工作表

Geek_249eec

C# Excel VB.NET 单元格区域 工作表

一篇文章让你重学HTTP!

Albert Edison

https 计算机网络 HTTP 8月月更

离线渲染与实时渲染杂谈——从发布会上的产品展示说起

3DCAT实时渲染

二、《图解HTTP》- HTTP协议历史发展(重点)

懒时小窝

HTTP 图解https

三、《图解HTTP》- 报文内的 HTTP信息

懒时小窝

HTTP 图解https

开源一夏 | 使用 JavaScript 的响应式计数器动画

海拥(haiyong.site)

开源 8月月更

巨细靡遗流程控制,Go lang1.18入门精炼教程,由白丁入鸿儒,Go lang流程结构详解EP09

刘悦的技术博客

Go 教程 Go web go语言 Go 语言

【SimpleFunction系列二.2】SpringBoot注解整合Redisson分布式锁

莫逸风

分布式锁 redisson 分布式锁 企业级应用

共建共享数字世界的根:阿里云打造全面的云原生开源生态

阿里巴巴云原生

阿里云 开源 容器 RocketMQ 云原生

新零售标杆 SKG 全面拥抱 Serverless,实现敏捷交付

阿里巴巴云原生

阿里云 Serverless 云原生 合作案例

【计算讲谈社】第八讲:AI 技术的“纺织业”是什么?

大咖说

人工智能 商业化

高效能团队的Java研发规范(进阶版)

木小风

编程规范 Java core

王熙凤穿越到 2022 年,一定会采购的单点登录服务

Authing

五、《图解HTTP》- RSS和网络攻击

懒时小窝

HTTP 图解https

注册配置、微服务治理、云原生网关三箭齐发,阿里云 MSE 持续升级

阿里巴巴云原生

阿里云 微服务 云原生 网关

ASP.NET Core SignalR概述

辣么大

.net SignalR 8月月更

七、《图解HTTP》- HTTP首部和HTTP协作服务器

懒时小窝

HTTP 图解https

动手实操,让你的 Kubernetes 集群弹起来!

以尘

弹性 ACK Kubernetes 集群 ClusterAutoscaler Erda

终、《图解HTTP》读书笔记 - 汇总篇(总结)

懒时小窝

读书笔记 读书 HTTP 图解https #读书

场景品牌易观千帆,助力数智化需求持续升级

易观分析

数字经济 数智化

开源一夏 | AngularJS对于SQL的操作心得以及DOM的研究

恒山其若陋兮

开源 8月月更

MobTech ShareSDK 使用简介

MobTech袤博科技

开发者 sdk MobTech袤博科技

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