本文版权归作者所有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。
转载自夜明的孤行灯
本文链接地址: https://www.huangyunkun.com/2017/05/17/heroku-vs-paas/
写完这篇博客,发现一个问题,这里比较的其实本质是App engine而不是PAAS平台。相对的其实应该是Azure的App Service,AWS的AWS Elastic Beanstalk。
有很多应用目前是放在Heroku上的。Heroku的功能自然没得说,好用简单,各种第三方服务可以很轻易的集成。但是Heroku从中国大陆访问问题很严重,基本处于不可访问的状态,所以就需要找个国内的类似的服务商或者外国服务商但是从中国大陆访问速度可以接受的。
Paas这种生意一般都是大厂在做,然后比较一番,其实也没有多少,阿里云之前有个ACE后面死掉了,AWS中国还在测试,京东容器服务也是在内侧中,算来算去,功能上和Heroku接近的只有百度云应用引擎,新浪SAE。
我关注的点主要在于代码能否自动构建,支持语言,绑定域名和价格
名称 | 代码自动构建 | Java | Python | Node | 绑定域名 | 价格(Java 512M) | 数据库 | 其他第三方服务 |
Heroku | 支持 | 支持 | 支持 | 支持 | 支持 | 35 | 支持 | 多 |
百度云应用引擎 | 不支持 | 支持 | 支持 | 支持 | 支持 | 21 | 支持 | 基本没有 |
新浪SAE | 不支持 | 支持 | 支持 | 不支持 | 支持 | 72 | 支持 | 少 |
如果是Java应用新浪SAE其实价格是不占优势的,而百度云BAE看起来似乎是合适的替代品。
相比于Heroku的buildpack模式,百度云BAE支持的以下几种:
- nodejs-web
- php-web
- java-tomcat
- java-jetty
- python-web
- lighttpd-static
还支持php和python的worker。
BAE的发布需要自己打包上传,当然这还包括依赖的jar包。
我个人而言,还是不是很喜欢BAE这种方法,因为习惯了Heroku那种上传自动编译搞定所有事情的方法确实很简单。
本文版权归作者所有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。
转载自夜明的孤行灯
本文链接地址: https://www.huangyunkun.com/2017/05/17/heroku-vs-paas/
Azure Web App