Masashi Terui @ marcy_terui
I’m a Developer and Cloud Architect.
I’m a Remote-Multi-Worker at Section-9 / Serverworks Co., Ltd. / Freelance
I’m an author of the serverless deployment tool “Lamvery”.
I’m around 30 years old. I’m a father of my son and my daughter.
https://willy.works/
2
3
4
5
・・・
6
7
8
9
10
11
12
13
Serverless
Framework
14
Congratulations on the release candidate version “1.0” 🍻🍻🍻
The ecosystem-oriented full stack framework (from 1.0)
Multi language (Node.js, Python, Java), Multi platform (in the future)
Resources management, Scheme migration
Pluggable architecture
https://github.com/serverless/serverless
Apex
15
Simply and multifunctional framework
Single binary (Golang)
Many language support (Node.js, Python, Java, Golang)
Easy to use, but lack of flexibility
Integration with front-end tool chain (Browserify, Webpack etc…)
https://github.com/apex/apex
Chalice
16
Python micro-framework by Amazon (like Flask)
Routing annotation
Automatic IAM policy generation
Very easy to use
Monolithic
https://github.com/awslabs/chalice
Zappa
17
Serverless (Lambda + API GW) to be WSGI-compatible
Support some of major Python WAF (Django, Flask etc..)
A lot of libraries are available for the major frameworks
Monolithic, Traditional way
https://github.com/Miserlou/Zappa
Lamvery
18
Python virtualenv environment optimization (with Node.js support)
YAML + Jinja2 configuration file (Not JSON!!)
Safety and flexibility deployment/rollback by alias swapping
Focus to the lifecycle of the function, event driven architecture
https://github.com/marcy-terui/lamvery
Matches
(I think)
19
Serverless framework : Building an application that have many APIs
Apex : Building a lot of small APIs by front-end engineers
Chalice : Building a small application easily
Zappa : Building an application on the traditional way
Lamvery : Building the event driven functions more simply and safety
20
21
Serverless
Use cases
22
Simply and small APIs (for Static web site, Native Application)
Event-driven parts of the services
API Backends (for Single Page Application, Native Application)
Micro services platform
23
24
Benefits
25
Minimize/Optimize the cost
Fully managed
Minimal implementation
Automation
Eliminate waiting and polling
etc…
26
27
Issues
28
Our applications will not be micro-services by serverless
FaaS will invite us to micro-services, but too complex to use as is
We need a framework
All the frameworks doesn’t solve some problems of the monolithic frameworks
Dependencies management for the libraries and functions
Partially deployment (Grouping functions)
Establishment of debugging method and monitoring method
29
Proposal
30
Tagging functions and deploy/manage using the tags
Use aliases/staging effectively (like Lamvery)

http://qiita.com/marcy-terui/items/900b72efb38f9b26e8f0
Declare the bundled libraries for each functions
Dependency visualization for libraries & functions
Let's think together about debugging and monitoring :-)
31
Unlimited Frameworks

Unlimited Frameworks

  • 2.
    Masashi Terui @marcy_terui I’m a Developer and Cloud Architect. I’m a Remote-Multi-Worker at Section-9 / Serverworks Co., Ltd. / Freelance I’m an author of the serverless deployment tool “Lamvery”. I’m around 30 years old. I’m a father of my son and my daughter. https://willy.works/ 2
  • 3.
  • 4.
  • 5.
  • 6.
  • 7.
  • 8.
  • 9.
  • 10.
  • 11.
  • 12.
  • 13.
  • 14.
    Serverless Framework 14 Congratulations on therelease candidate version “1.0” 🍻🍻🍻 The ecosystem-oriented full stack framework (from 1.0) Multi language (Node.js, Python, Java), Multi platform (in the future) Resources management, Scheme migration Pluggable architecture https://github.com/serverless/serverless
  • 15.
    Apex 15 Simply and multifunctionalframework Single binary (Golang) Many language support (Node.js, Python, Java, Golang) Easy to use, but lack of flexibility Integration with front-end tool chain (Browserify, Webpack etc…) https://github.com/apex/apex
  • 16.
    Chalice 16 Python micro-framework byAmazon (like Flask) Routing annotation Automatic IAM policy generation Very easy to use Monolithic https://github.com/awslabs/chalice
  • 17.
    Zappa 17 Serverless (Lambda +API GW) to be WSGI-compatible Support some of major Python WAF (Django, Flask etc..) A lot of libraries are available for the major frameworks Monolithic, Traditional way https://github.com/Miserlou/Zappa
  • 18.
    Lamvery 18 Python virtualenv environmentoptimization (with Node.js support) YAML + Jinja2 configuration file (Not JSON!!) Safety and flexibility deployment/rollback by alias swapping Focus to the lifecycle of the function, event driven architecture https://github.com/marcy-terui/lamvery
  • 19.
    Matches (I think) 19 Serverless framework: Building an application that have many APIs Apex : Building a lot of small APIs by front-end engineers Chalice : Building a small application easily Zappa : Building an application on the traditional way Lamvery : Building the event driven functions more simply and safety
  • 20.
  • 21.
  • 22.
    Serverless Use cases 22 Simply andsmall APIs (for Static web site, Native Application) Event-driven parts of the services API Backends (for Single Page Application, Native Application) Micro services platform
  • 23.
  • 24.
  • 25.
    Benefits 25 Minimize/Optimize the cost Fullymanaged Minimal implementation Automation Eliminate waiting and polling etc…
  • 26.
  • 27.
  • 28.
    Issues 28 Our applications willnot be micro-services by serverless FaaS will invite us to micro-services, but too complex to use as is We need a framework All the frameworks doesn’t solve some problems of the monolithic frameworks Dependencies management for the libraries and functions Partially deployment (Grouping functions) Establishment of debugging method and monitoring method
  • 29.
  • 30.
    Proposal 30 Tagging functions anddeploy/manage using the tags Use aliases/staging effectively (like Lamvery)
 http://qiita.com/marcy-terui/items/900b72efb38f9b26e8f0 Declare the bundled libraries for each functions Dependency visualization for libraries & functions Let's think together about debugging and monitoring :-)
  • 31.