Serverless Computing
Someone Else's Servers
  
Tusa Viktor @ Xively
@talien
github.com/talien
  
	- Different aspects
	
		- Business: What you pay for
		
		
 
		- Developer: What your program use
		
		
 
		- Ops: What you manage
		
			- Number of servers/databases/log lines/metrics
 
		
		 
	
	 
  
	- Mainframes
	
		- Time-shared usage
 
		- Not easy to extend capacity
 
	
	 
	- PCs/Data Centers
	
		- Roles are separated on different servers
 
		- Monolith applications
 
		- Easier to extend capacity
 
	
	 
	- Virtualization/Containerization
	
		- Fine-grained capacity on different apps
 
		- Still need to know the whole capacity
 
	
	 
	- Public Cloud/IaaS/PaaS
	
		- "Capacity is not my problem anymore"
 
		- Computational unit is still one container/server
 
	
	 
  
	- Hardware management
	
	
 
	- OS management, patch management
	
	
 
	- App management
	
	
 
  
	- New computational model
 
	- Computational unit is 1 function call (Function-as-a-Service)
 
	- If no function call happens, nothing to pay for
 
	- Other category: Backend-as-a-Service, DB-as-a-Service
 
  
	- Event driven architecture
 
	- Triggers + Functions
	
		- Messages, Schedules, State changes
 
	
	 
	- Billing unit: GB-seconds
 
	- Constraints:
	
		- memory
 
		- execution time (5 min in Lambda)
 
		- parallelization
 
	
	 
	- Stateless
 
  
	- 
Common aspects of application
	
		- Authentication, Authorization, User tracking
 
		- eg: Auth0, Firebase
 
	
	 
	- Heavily used in Mobile development
 
	- API driven
 
	- Easy to integrate
 
  
	- AWS Lambda
	
		- First amongst public clouds
 
		- Nicely integrates with other part of AWS
 
	
	 
	- Azure Functions
	
		- Very similar to AWS Lambda
 
		- Two "Consumption Plans"
 
	
	 
	- Google Cloud Functions
	
	
 
	- OpenWhisk/IBM Bluemix
	
	
 
	- Over kubernetes serverless:
	
		- Funktion, Kubeless, Fission
 
	
	 
  
	- Event-driven, "nanoservices"
 
	- Supports popular runtimes
	
	
 
	- IoT is main target
 
	- Events, Triggers
	
		- HTTP triggers
		
		
 
		- Pub/Sub triggers
 
		- Message queue triggers
 
		- State changes
		
			- Uploaded file to blob storage
 
		
		 
		- Scheduled events ("cloud cron")
 
	
	 
  
	- Not easy to estimate costs upfront
 
	- Can be expensive
	
		- 3mill req, each 1 sec, 512 MB memory
 
		- AWS: 15$, Azure: 20$
 
		- smallest instance: 5$/month both in Azure/AWS
 
	
	 
	- "Cold start"
	
		- First call after idle time is slow
 
	
	 
	- Function initialization is not deterministic
 
  
	- Patching is not in our hand (fixed runtimes)
 
	- No service discovery
 
	- Cannot attach debugger
	
	
 
	- Hard to test locally
	
		- AWS SAM Local
 
		- Azure Functions Runtime
 
	
	 
  
	- Formerly JAWS,
 
	- First framework to utilize AWS Lambda/API GW
 
	- CLI written in node
 
	- Support major serverless platforms
	
		- AWS
 
		- Azure
 
		- Google Cloud
 
		- OpenWhisk
 
	
	 
  
	- Lot of Cons, but what are the pros?
 
	- 
Very easy to deploy
 
	- Ideal for prototyping
 
	- No need for classic ops (patch management, software install & config, ssh, etc).
 
	- Free tier can handle small websites
 
	- Use cases:
	
		- Event driven architecture 
 
		- IoT
 
		- Automation
 
	
	 
  
			 
		 
		    Made with Slides.com