PaaS

云计算的拐点隐现 华为云开源两款容器技术

百般思念 提交于 2019-12-28 18:03:56
【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 日前,全球云原生领域最大的峰会之一KubeCon+CloudNativeCon首次登陆中国。近年来,中国是北美之外对Kubernetes热情最高的地区,业界领先企业悉数到场。华为云BU PaaS产品部总经理廖振钦在大会主论坛发表了《进入垂直行业,Kubernetes帮助各产业加速向云原生迁移》的主题演讲,表示容器既需要在技术角度做演进,更要深入到行业中实践。 雷锋网获悉,据Gartner预测,到2020年,全球容器市场将超过20亿美金,容器逐步成为企业数字化转型标配,Kubernetes则是容器技术的核心。 华为云与容器 在容器领域,华为云打的也是全栈的招牌,提供基础设施、交付、运维、容器化架构转型的全流程服务,不过华为云与容器的联系不仅于此。 雷锋网了解到,华为很早就接触并在云原生领域做贡献。早在2015年,华为就加入Kubernetes社区并作为创始会员之一参与发起成立CNCF基金会;2016年,华为成为国内第一家发布基于Kubernetes的容器服务CCE;2017年华为成为第一批成为全球Kubernetes认证的服务提供商,并且CCE也首批通过了Kubernetes的一致性认证。截止目前,华为云在CNCF基金会,全球贡献3000+ PR,全球排名第三,国内排名第一。咪咕互娱、猪八戒

视频云下半场 向前走还是向“厚”走?

放肆的年华 提交于 2019-12-27 17:54:14
【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> Photo by Thomas William on Unsplash 从2016年至今,流量的增长基本进入到了平稳期,此时,面向产业界和开发者,我们如何提供更多、更新的能力给到他们,提升平台的用户体验?本文来自腾讯云视频业务产品总监黄斌在LiveVideoStackCon 2019深圳站上的精彩分享,希望和业界一起探讨视频云下半场的方向与定位,也希望与产业界同仁一道,共建更好的大视频生态。 文 / 黄斌 整理 / LiveVideoStack 1.直播行业中的难点 腾讯云内部最早在2015年下半年开始进入视频云领域,将腾讯多年在音视频编解码、音视频通信以及海量并发业务的经验逐渐开放,当时我们也是新进者,定位是在OVP(在线视频平台),类似国外的brightcove及国内的CC视频,我们在教育、在线视频等领域进行了尝试。不过真正确定业务重点方向是在2016年,2016年也是国内的直播元年,行业的爆发让团队意识到直播的流量是非常大的,在高并发情况下如何能做到视频流畅无卡顿、并能提供丰富的IM通信、保证互动连麦等环节的正常进行,这正是我们的技术优势所在,我们抓住了直播的这个风口。 我自己将市面上的产品按照碎片消费、按需点播、实时互动和定时播放四个维度分为四个部分,右上象限这类实时性高,低制作成本的这些应用

需求开发应用部署“一条龙”,平安云如何加速容器场景落地

邮差的信 提交于 2019-12-27 16:17:17
【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 2019年6月20日,由Rancher Labs(以下简称Rancher)主办的第三届企业容器创新大会(Enterprise Container Innovation Conference, 以下简称ECIC)在北京喜来登大酒店盛大举行。本届ECIC规模宏大,全天共设置了17场主题演讲,吸引了近千名容器技术爱好者参加,超过10000名观众在线上直播平台观看了本次盛会。 来自Rancher、阿里云、百度云、平安科技、中国联通、飞贷金融科技、中国人寿、SmartX、华泰保险、厦门航空、JFrog、新东方、Cisco等近20家企业的技术负责人出席了本届ECIC,在大会现场带来了关于企业容器项目实践经验的精彩分享。 大会现场,平安科技CTO及总架构师方国伟提出,近年来在云计算赛道上,容器因为它轻量、灵活、易管理、易迁移等特性被企业广泛采用,如一辆高速前进的方程式赛车脱颖而出,成为了企业云化历程中的大势所趋。在未来3年,平安云将会重点投入容器建设,解决容器快速交付的难题,并且进行微服务的支撑。 以下是平安科技CTO及总架构师方国伟的演讲实录: 大家上午好!谢谢梁胜博士,谢谢Rancher邀请我们在企业容器创新大会上分享。 先和大家介绍一下平安科技的容器应用情况,我们从2014年开始关注容器技术

2020,软件新风口:aPaaS!

跟風遠走 提交于 2019-12-27 15:08:09
【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> PaaS平台大家都不陌生,但我想说的是,aPaaS可能会成为2020软件行业的主角。 为什么这么说呢? 这还得从云计算说起 aPaas是衍生在云平台之上的,如果开发一款应用,需要涉及大量基础技术或者基础设置。如果从技术层次上划分来说,分为以下几层: application层 data层 runtime层 middleware层 OS层 virtualization层 servers层 storage层 networking层 在以前软件开发及维护过程中需要购买并维护这9层设施,而一些公司可以将这9层基础技术或者基础设施打包起来出售,就是云计算了。 于是,云计算、云服务就变成了我们服务底层的水电煤,我们每个月交钱就可以了,比自己维护这9层来说简单了很多。 针对这9层,于是就有了 IaaS、PaaS和SaaS。而aPaas是介于PaaS和SaaS之间的一层,它的英文全称是:application Platform as a service,应用程序即服务。 基于aPaaS的解决方案,支持应用程序在云端开发,部署和运行,提供软件开发中基础工具用户,数据对象,权限管理,用户界面等功能。 那么,aPaaS能干什么呢? 提供应用的快速开发环境,用户在几个小时内就可以完成应用开发,测试,部署,并可以随时调整和更新代码。

HostOS和GuestOS的简单名词解释

百般思念 提交于 2019-12-27 03:00:55
今天在看容器技术的博客时,发现有些名词不甚了解,因此记录一下: OS :操作系统 VM ( 虚拟机 ) 里的OS 称为 GuestOS 物理机里的OS 称为 HostOS SaaS :(软件即服务)     应用 PaaS :(平台即服务)       软件部署平台 IaaS :(基础设施即服务)    cpu、内存、存储 IaaS + PaaS 组合成 CaaS CaaS是由Docker引入的 hyper-v :虚拟化技术 来源: CSDN 作者: weixin_40705360 链接: https://blog.csdn.net/weixin_40705360/article/details/103720730

大规模产品技术团队需求管理实践

陌路散爱 提交于 2019-12-26 17:23:45
【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 背景 随着业务的发展,组织会从创业期的一个主要产品,扩展到多个产品。从产品技术的角度,也会逐渐抽象出共享技术部门,进而发展为技术中台、业务中台。随着产品线的扩大,产品需求管理(背后是协作协同、资源调度),就变成了一件愈来愈复杂的事情。如果不能妥善处理,会造成协同困难、效率低下,无法支撑业务发展。本文介绍有赞从由单一产品到多产品线,产品技术团队从百人到千人规模的需求管理实践。 组织目标与产品需求待办列表之间的关系 成功的商业组织,未必是资源多,而是把资源用到了对的地方。一维之上有二维,系统之上有系统,在更高维度才能看清楚低维度系统的全貌。从产品看技术,从业务看产品,从行业看业务。产品需求,从源头上来看,承载的是一个组织的战略目标和客户的诉求。 有赞使用的是 OKR 来管理战略目标,我们常说不积硅步无以至千里, O 就是千里之外的目标,是指南针; 从OKR出发衍生的需求待办列表,就是使得我们致千里的硅步。以产品和服务为载体的商业组织,无论目标多么远大,最终是落实在一条条需求上。产品需求的取舍依据是组织的目标,要与这个源头对齐,也就是需要与 OKR 对齐,以避免资源和时机的浪费。 需求待办列表的产生与更新:多方做输入, 产品负责人做决定 产品需求从”事“的角度来源于战略。从”人“的角度来自内外部客户、干系人

SaaS,PaaS和IaaS在一张图中进行了解释

若如初见. 提交于 2019-12-26 08:09:42
本文英文原址: https://m.oursky.com/saas-paas-and-iaas-explained-in-one-graphic-d56c3e6f4606 Photo by Cathal Mac an Bheatha via Unsplash The Pizza-as-a-Service metaphor was firstly introduced by Albert Barron in 2014 as a visualization of the differences between Infrastructure-as-a-service (IaaS), Platform-as-a-service (PaaS) and Software-as-a-service (SaaS). At first sight it looks brilliant — but if you look in depth, it falls apart. This diagram wants to illustrate that you need to do less and less, but the items that are listed and increasingly “outsourced” don’t fit the comparison. I’ll look at

【美团·成都沙龙报名】美团收银系统微服务架构实践

被刻印的时光 ゝ 提交于 2019-12-25 19:09:58
【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 【美团技术沙龙】由美团技术团队和美团科协主办,每期沙龙邀请美团及其他互联网公司的技术专家分享来自一线的实践经验,覆盖各主要技术领域。 活动时间 :2019年12月28日 14:00-17:30 活动地址 :四川省成都市武侯区都会路66号城南天府大厦(5楼成都人才服务中心)·蓉漂咖啡逐梦厅 报名链接 : 点我报名 出品人:李战涛 | 美团高级技术专家 2017年加入美团,目前负责美团收银系列产品研发&团队管理工作,在美团期间,推出美团收银青春版等产品,目前美团收银产品在餐饮收银线上、线下市场市占均是第一。之前在小米工作过若干年,负责小米商城的在线促销系统、小米售后&仓库系统、大数据团队研发管理工作。 活动简介 美团收银系统为餐厅经营管理提供一体化的解决方案,在to B产品上,做好PaaS平台建设,打造核心竞争力,修炼好大团队规模化高效研发方法论,以便能深入参与广大餐饮商家生意,帮商家提高经营效率、改进经营质量,逐步建立和拓展健康的餐饮合作生态体系;同时打通线上和线下,让美团C端能提供更丰富的产品形态,提升用户就餐体验。 本次技术沙龙主要围绕美团收银系统微服务平台架构设计,以会员营销平台领域为例介绍微服务的设计原则,并且如何通过设计良好的灰度发布实践来保障发布的安全和质量

什么是多租户

强颜欢笑 提交于 2019-12-25 18:09:12
【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 多租户技术(英语:multi-tenancy technology)或称多重租赁技术,是一种软件架构技术,它是在探讨与实现如何于多用户的环境下共享相同的系统或程序组件,并且仍可确保各用户间数据的隔离性。 由于云计算议题的发烧,在共享的数据中心内如何以单一系统架构与服务提供多数客户端相同甚至可定制的服务,并且仍然可以保障客户的数据隔离,让多租户技术成为云计算技术下的显学。 历史 多租户技术源于1960年代,许多公司为了要使用更多的运算资源,向持有大型主机(Mainframe)的供应商租用一部分的运算资源,而这些用户经常会用到相同的应用程序,当时会以用户在登录系统时输入的数据来决定用户的账户ID,基于这个ID,Mainframe的供应商即可利用此ID来计算运算的资源使用量,包含CPU,存储器与磁盘或磁带等,这个作法也被SAP公司用在其R/1到R/3的产品线。 到了1990年代,应用程序服务提供者服务(application service provider)模式出现,它的作法与运作模式与租用大型主机时相同,不过租用的资源是在软件上,除了操作系统以外也包含了其上的应用程序,例如ERP系统或是CRM等应用,系统可能会运行在数台不同的机器上,或是在相同的主机但共享不同的数据库,以区分并计算客户的资源使用量

阿里巴巴基于 Kubernetes 的实践经验

|▌冷眼眸甩不掉的悲伤 提交于 2019-12-25 11:18:24
【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 本文整理自孙健波在 ArchSummit 大会 2019 北京站演讲稿记录。首先介绍了阿里巴巴基于 Kubernetes 项目进行大规模应用实践过程中遇到的问题;随后会逐一介绍解决这些问题的现有实践及其本身存在的局限性;最后会介绍阿里巴巴目前正在进行的尝试和社区在这一领域的发展方向。 如今,阿里巴巴内部维护了数十个大规模的 K8s 集群,其中最大的集群约 1 万个节点,每个集群会服务上万个应用;在阿里云的 Kubernetes 服务 ACK 上,我们还维护了上万个用户的 K8s 集群。我们在一定程度上解决了规模和稳定性问题之后,发现其实在 K8s 上管理应用还有很大的挑战等着我们。 应用管理的两大难题 今天我们主要讨论这两个方面的挑战: 对应用研发而言,K8s API 针对简单应用过于复杂,针对复杂应用难以上手; 对应用运维而言,K8s 的扩展能力难以管理;K8s 原生的 API 没有对云资源全部涵盖。 总体而言,我们面临的挑战就是:如何基于 K8s 提供真正意义上的应用管理平台,让研发和运维只需关注到应用本身。 研发对应用管理的诉求 1. K8s all in one 的 YAML 文件 让我们来看一下这样一个 K8s 的 yaml 文件,这个 yaml 文件已经是被简化过的,但是我们可以看到它仍然还是比较长