No server ready:
the last two years is no server software development lively topic. Leading this technology is AWS, and each cloud vendors have developed their own technical standards, seamless migration before the various cloud vendors do if, from now seems almost impossible, but I believe it is possible for the future of this technology innovation there will be a third-party seamless or uniform standards, we look forward to this day.
Since no optimization point of service is very prominent, such as: 1. To achieve rapid business on line 2 without operation and maintenance personnel to maintain basic resources, reduce operating costs, higher system-level 3 security, reduce development costs 4, 5.... suitable for micro-services framework, under these advantages and attract a large cloud vendor recommendation, many users will try their original Lambda to migrate business use on-prem reconstruction of the way, but these attempts must first ask the user's personnel ability to continue to split into Function in micro-services basis, the business can be made stateless. 
Business Evolution 1
From the original giant business Refactor to Function, which developers have become increasingly demanding, requiring developers to fine-grained split the business to meet the demands of this new technology.
Practice sharing:
As customers in the original application On-premises have been unable to meet the ever-expanding business, the code needs to be on cloud after the reconstruction of the original application. The customer does not have a strong technical architect or developer, outsourcing almost all junior staff. After our engineers who assisted the customer's outsourcing staff to do a Python-based Lambda Demo test, they have begun outsourcing their own use SpringBoot of the original cloud applications on reconstruction aid Lambda technology, and to a certain stage they found this technique is not the staff can fully grasp, and finally had to give up the use of Lambda, a return to EC2 deployment. The following is done deletion of certain customer business architecture design: 
Business Architecture Figure 2
1）业务及人员
这种新技术是要求开发人员必须具备一定微服务的能力，能够应用进行拆分，并能够通过业务代码解决新技术存在一些缺点，还要求开发人员对原来的业务逻辑完全掌握。在新技术并不完善的情况下，并不是所有业务场景都合适重构为Serverless服务。此客户情况如下：
- 开发人员与架构师对微服务掌握程度并不够
- 对要进行拆分的业务逻辑只是表面上的理解
- 开发人员的代码能力并不高
- 客户的业务属于重型且持续交易电商平台
- 客户的测试流程并不完善
Timeout报错日志图3
2) 技术选型：
在进行技术选型时，必须有一到两个人员对某一技术有一定掌握，前期进行大量测试与预研，充分掌握此技术缺点与优化。Lambda技术出现并不长，必然存在一些不完善，这样就要求开发人员能够对这些不完善有所掌握，并能够通过其他技术手段解决Lambda存在的缺陷，以满足业务持续服务的要求。
1. 冷启动时间
2. 开发语言是否合适
3. Lambda的请求并发与内存配置容量上限
4. AWS各个服务Timeout时间
5. 在Lambda内存达到上限后，重启的问题
6. 使用Lambda预热方案能否满足未来业务扩展
7. 微服务化后，能否集成CI/CD功能
实践总结：
用户在经历以上使用体验后，慢慢知道有些业务还要具备一定能力后，才能够去尝试，而不是急于求成，需要听更多专业人员的建议，一步一个脚印完成业务迁移，先从简单再到复杂，先从Rehost再到Refactor，如果要Refactor必须经过大量验证测试。以下是经历过此案例后一些建议：
1. Lambda合适在轻量级业务场景
2. 做足冷启时间评估与测试
3. 能够更细粒度拆分业务，以Function方式写业务
4. 掌握并测试AWS各个服务的限制（例如：API gateway的Timeout 20秒，Lamdba的内存上限3GB等）
5. 选择更轻量开发语言（例如：Nodejs/Python等），尽量减少部署包的大小
6. 非常熟练自己的业务
7. 具备高级以上开发工程师
8. 使用完善的监控，不断优化Function
Refactor是迁移当中最高级且最复杂的方式，最好有专业人员进行协助与指导，避免重复的成本浪费。建议如果客户的业务确实需要进行重构，请必须经过大量的功能与性能测试验证。（此文章若有错误，请指正，谢谢！）
参考学习地址：
https://blog.csdn.net/j01G58UC80251/article/details/78591424
https://www.jeremydaly.com/lambda-warmer-optimize-aws-lambda-function-cold-starts/
As a professional enterprise cloud computing services, Booz cloud for customers to provide operational services on AWS: architecture, including consulting services, migration services, cloud security integration services, hybrid cloud management services, data services and large DevOps service. Currently, Booz cloud vendor certification has been made in big data, DevOps, architecture, databases and operating systems, with branch offices in Shanghai, Nanjing, Hangzhou, Wuhan and other places. Innovative service model, lead the development of IT services, Booz cloud will continue to invest resources to carry out intelligent hybrid cloud management platform, the map database of research and development.