BootDev创立之初，致力于为大网站出示全自动部署解决方法。我们的优势，简易通俗化地讲，划算且快；技术专业地说，大家让大网站以成本低，快速率交货內容！大家有工作能力在顾客自身的AWS账户下部署一个全自动伸缩式架构，适用高总流量高可用性，简省网站应用云的学习培训周期时间和应用风险性。
BootDev有着七年的Drupal工作经验，Drupal也是大家最善于的物品之一。大家都知道，Drupal因其极性能卓越规定知名，却一样也是世界上最难的开源系统CMS，这一没有之一。妄自尊大地说，BootDev都可以把Drupal搞好，也有别的哪些网站做不太好？
2014年底的情况下碰到那样一个顾客，这是一个旅游咨询新闻媒体的中大中型drupal AWS网站，恰好是二者的融合。
那时候他有五个子网站，PV数为150万/月，存有下列一些状况：
网站cron job计划任务一直会让服务项目挂了，每星期必须重启服务器处理。
有八个网页页面服务器节点（Web nodes）和一个数据库查询，MemCache，CDN，AWS S3早已部署
Git都还没架好，没法立即部署编码到8台网络服务器
每个月AWS网络服务器开支在8000 USD上下，价格比较贵
网络服务器一直处在高负荷情况，cron job始终完毕不上
图象被存储在不一样文档架构和系统软件中
缓存文件访问率低
沒有浏览器缓存
对比亚洲地区相近的网站（如 cityweekend.com / scmp.com）7人上下的技术性精英团队，这一顾客仅有前端开发1人
顾客网站的状况可以说十分糟糕，可是我与精英团队的小伙伴们临危授命，扭转局势。
大家从Drupal网站自身及其AWS网络服务器两层面同时进行干了改善，并立即出示的是一个优秀的后台管理和健全的架构。对网站主来讲，不只是死而复生的一根稻草，也是省掉早期艰辛的学习培训周期时间和冗杂的架构基本建设。下列便是大家那时候的架构图：
进行制订架构，大家开展了下列配制。
<AWS 配制>
架构的版本控制不能少。
创建一个新的架构是耗时费力烧钱的，最先你得解决不计其数条主要参数，并且你永远不知道在其中的哪一条主要参数是对的，哪一条会毁了你全部架构。BootDev因而坚信，架构务必还要做版本控制，自然大家也是那样开展的。我们可以在一个真正的工作环境下，及时回到到上一个版本号的架构，那样大大减少了由于配制或一些不正确导致的损害。我们自己自身会根据AWS Cloudformation和OpsChef部署一个全自动伸缩式架构到大家的网站，一切对于架构的实际操作都是有版本控制，因而碰到一切状况，我们可以一下子回到。
全自动伸缩式，轻松解决总流量波峰波谷，更划算。
如同上一条提及的，因为全自动伸缩式架构的置备，大家因而不用为网站总流量高峰期忧虑。以前一直standby的8台网络服务器也相对地降到2台，尺寸由Xlarge变为Large。当总流量来临时性，网站服务器的扩大全过程只需十分钟，付款花费也即付即得，网站主不必为事先存留的设备付费，要是给自己应用的设备付费。
AWS Cloudforamtion 适用应用好几个域（Domain Sharding）
这代表着你能关联好几个域名跳转你的CDN資源（遍布），因此 浏览量的电脑浏览器能够 在不一样网站域名另外下载页面。
AWS动态性CDN的极致应用
大家把域名跳转Cloudfront，而Cloudfront会像服务器代理一样从本来的地区取得数据信息。那样能够 避免DDOS，这一构想和CloudFlare是一样的。不仅这般，动态性CDN能够 协助大家当网站处在高浏览量情况下，不用真实浏览网络服务器。这一高新科技难题取决于，每一个behavior里的一切path，都是有许多应用参数必须自身配制，自然你也能够 挑选把这一切能够 交到BootDev。
AWS S3适用数据库，我们可以分次设置储存在AWS S3里图象的header，那样能够 危害电脑浏览器和CDN的缓存文件个人行为。例如，你在其中一个浏览量安装了一张图片，一样的照片会被缓存文件，而不容易被同一台机免费下载，合理地节省了网络带宽成本费。
