该供应商编写的技术底漆已经被网络世界编辑，以消除产品推广，但读者应该注意到它可能会倾向于提交者的做法。有个足球雷竞技app
软件定义的数据中心（SDDC）技术的采用是动态可扩展性和业务敏捷性雷竞技电脑网站的巨大潜力推动，但过渡充满了复杂性是需要考虑的。
这个生态系统依赖于通过虚拟化对物理资源(主要是计算、网络和存储)的抽象或池化。通过软件编排新的或更新的服务，这些资源可以在不需要人工干预的情况下实时供应。从本质上说，这是对现代数字商业的敏捷性要求的技术响应。
术语SDDC可以应用到今天的公共云（当然亚马逊和谷歌和微软的云资格），以及未来的私有云和混合云的组织加速他们对提供数据中心基础设施作为服务（IaaS）的过渡。雷竞技电脑网站而作为当今企业数据中心，未来的SDDCs可能会支持你的开发雷竞技电脑网站和维护打包的应用程序和应用程序的混合。
SDDC的原则之一是容量是动态可扩展的;当然不是无限的，但这也不是一个坏的想法。这意味着对能力的处理与过去有所不同。启动新服务器以满足激增的需求，根据预定义的策略自动连接这些服务器，然后在需求减弱时销毁它们的能力，将成为新的SDDC范式。资源利用率不再用于警报生成阈值，而是成为扩展算法的输入。
该基础设施可以自我调节，弹性和自动化的，但是这并不能免除我们的性能监控的要求。相反，它从移动基础设施的能力管理应用程序（或服务）的响应时间的重点。提供服务的应用程序可以由组件和服务依赖于不同的堆栈和平台混合泳，要求至少有几个不同的方法来性能监控。事实上，通过对多个监控解决方案 - 而实际需要 - 可能会导致一些操作上的挑战，包括：
- 监视深度不一致
- 有限的端到端性能可见性
- 服务的重点，而不是用户的焦点
由于交付应用程序需要数十个、数百个甚至数千个服务，服务质量不再由单个组件的性能或运行状况来定义。虚拟化会模糊关键性能的可见性，同时复杂的服务依赖关系甚至会挑战最好的性能分析师和最有效的作战空间。要做到这一点，就得面对假阳性的雪崩，“内部”警报更多的是信息性的，而不是可采取行动的。
考虑了一分钟一个流行的SaaS应用程序 - Salesforce的。它提供从云服务，就像你自己内部构建的应用程序可能有一天可以从您的私人云SDDC作为提供服务。你怎么了，作为负责贵公司的应用服务的IT团队中的一员，评估Salesforce的服务质量？
您不太可能关心所使用的vm数量、这些vm的利用率或应用程序和DB服务器层之间隧道中的网络拥塞。你不会想听到Salesforce的REST API到KiteDesk的吞吐量。相反，你关心的是最终用户的体验。登录到应用程序需要多长时间?网站导航的响应性如何?用户是否遇到错误或可用性问题?
这个示例说明了如何将SaaS应用程序的服务质量抽象为最终用户体验(EUE)。随着您的私有SDDC越来越方便地将应用程序作为服务交付，它提供了一个宝贵的教训——服务质量是在消费者的眼中。
这并不意味着数据中心监控已经过时了。雷竞技电脑网站您仍然需要监视基础设施和应用程序服务，至少作为一种细化自动化行为和策略定义的方法。但对EUE的洞察确实提供了一个透镜，通过它来限定这些内部指标。
再举一个例子，比方说，一个新的应用程序服务器的动态添加，以帮助支持日益增长的需求，通过新的网络隧道连接到数据库层。应用服务器的新位置上添加了几百微秒到隧道的等待时间。难道这是一个问题吗？
那要看。对于一些应用将是EUE没有明显的差异。但对于其他人，在这一层网络延迟甚至几百微秒可能会降低用户的体验就容忍错误的一边的东西。显然，一个情景，可以忽略不计，而其他需要立即关注 - 对课程的修复，也能保证政策调整，以防止复发。
只有EUE才能把服务质量放到有意义的角度。
虽然EUE作为一种共享的业务和IT度量——一种“最好拥有”的视图——在过去几年里变得很流行，但SDDC的抽象和复杂性将使它成为作为服务交付的应用程序的关键度量。
正如应用程序依赖于多个平台和堆栈一样，您的最终用户也是如此。浏览器和移动应用程序可能主导了新闻，但是有许多应用程序使用不同的客户类型，从Oracle表单和SAPGUI到RMI和虚拟桌面基础设施。
因此，你需要选择合适的EUE的监测方法，以确保所有重要应用程序（至少）的代表。四种流行的方法包括：
- 基于浏览器的应用程序的JavaScript注入
- 综合监控(通常也用于基于浏览器的应用程序，尽管有些应用程序包括非web)
- 基于探针的监视，其中网络探针包括理解终端用户操作的面向事务的解码
- 代码注入(或“修饰”)
随着IT继续朝着面向服务的IT前进，它的角色必须转变为具有竞争力的应用程序服务提供者——而EUE将成为成功组织使用的最重要的质量度量。