The Serverless Full Stack - Glynn Bird - Codemotion Amsterdam 2018
•Download as PPTX, PDF•
0 likes•104 views
The document discusses serverless computing and functions-as-a-service (FaaS). It describes how FaaS can be used to build application components and simplify application architecture. Examples of application functions include authentication, image uploading and resizing, ordering, and reading bitcoin prices from an API. The document also provides examples of deploying code for FaaS and choosing appropriate services for application components like sessions, files, and databases.
Recommended
Recommended
More Related Content
Similar to The Serverless Full Stack - Glynn Bird - Codemotion Amsterdam 2018
Similar to The Serverless Full Stack - Glynn Bird - Codemotion Amsterdam 2018 (20)
More from Codemotion
More from Codemotion (20)
Recently uploaded
Recently uploaded (20)
The Serverless Full Stack - Glynn Bird - Codemotion Amsterdam 2018
- 1. The Serverless Full Stack Glynn Bird - IBM AMSTERDAM - MAY 2018
- 2. IBM Cloud / © 2018 IBM Corporation 2 > Dev < Ops @glynn_bird
- 3. Cloud computing 3IBM Cloud / © 2018 IBM Corporation Physical servers Containers Virtual servers @glynn_bird
- 4. "Severless" doesn't mean "no servers". 4IBM Cloud / © 2018 IBM Corporation @glynn_bird
- 5. Serverless Computation ≍ Functions-as-a-Service 5IBM Cloud / © 2018 IBM Corporation F-a-a-S f f f f f f f f f f f f f f f f f f Work @glynn_bird
- 6. 6IBM Cloud / © 2018 IBM Corporation @glynn_bird
- 7. 7IBM Cloud / © 2018 IBM Corporation @glynn_bird
- 8. 8IBM Cloud / © 2018 IBM Corporation @glynn_bird
- 9. 9IBM Cloud / © 2018 IBM Corporation @glynn_bird
- 10. 10IBM Cloud / © 2018 IBM Corporation @glynn_bird
- 11. App LogicFile storage DatabaseStatic file server 11IBM Cloud / © 2018 IBM Corporation Components Session Store @glynn_bird
- 12. Attempt 1 - the monolith 12IBM Cloud / © 2018 IBM Corporation File storage Web server Database Application Stack Operating System @glynn_bird
- 13. 13
- 14. Attempt 2 - separate servers 14IBM Cloud / © 2018 IBM Corporation Database Operating System File storage Web server Application Stack Operating System @glynn_bird
- 15. Attempt 3 - add load balancers 15IBM Cloud / © 2018 IBM Corporation Database Web server Application Stack Operating System Web server Application Stack Operating System Web server Application Stack Operating System LOAD BALANCER SessionFiles @glynn_bird
- 16. App LogicFile storage DatabaseStatic file server 16IBM Cloud / © 2018 IBM Corporation Components Session Store
- 17. Static file server 17 ● version control your static HTML, CSS, JavaScript, icons and images ● use a CDN service to serve them out ● continuous integration! @glynn_bird
- 19. 19 ● store uploaded content in Object Storage ● use a CDN service to serve them out File storage @glynn_bird
- 20. Authentication 20IBM Cloud / © 2018 IBM Corporation ● /auth/register ● /auth/confirm ● /auth/login ● /auth/logout @glynn_bird
- 21. 21IBM Cloud / © 2018 IBM Corporation Posting ● /pic/upload ● /pic/favourite ● /pic/share ● /pic/resize @glynn_bird
- 22. 22IBM Cloud / © 2018 IBM Corporation Purchase ● /order/start ● /order/done ● /order/quit @glynn_bird
- 23. 23 f /auth/register f /auth/confirm f /auth/login f /auth/logout f /pic/upload f /pic/favourite f /pic/share f /pic/resize f /order/start f /order/done f /order/quit @glynn_bird
- 24. F-a-a-S makes things simple 24IBM Cloud / © 2018 IBM Corporation Web server Application Stack Operating System File storage Web server Application Stack Operating System Web server Application Stack Operating System LOAD BALANCER @glynn_bird
- 25. F-a-a-S makes things simple 25IBM Cloud / © 2018 IBM Corporation Object Storage f /pic/resize Node 7.1 @glynn_bird
- 27. 27 PROVIDERS
- 28. 28 @glynn_bird
- 29. 29 @glynn_bird
- 30. Deploying code 30IBM Cloud / January 31, 2018 / © 2018 IBM Corporation $ wsk action create hello hello.js action name code @glynn_bird
- 31. Deploying code 31IBM Cloud / January 31, 2018 / © 2018 IBM Corporation $ wsk action update pic/resize --kind nodejs:6 x.zip action name runtime code @glynn_bird
- 32. Deploying code 32IBM Cloud / January 31, 2018 / © 2018 IBM Corporation $ wsk action update pic/resize --kind nodejs:6 x.zip --web true action name runtime code @glynn_bird
- 33. Code 33IBM Cloud / © 2018 IBM Corporation const cloudant = require('cloudant') const readBitcoinPrice = require('./btc.js') const main = function(args) { return readBitcoinPrice().then((data) => { const db = cloudant({url: args.url, plugin: 'promises'}) return db.insert(data) }) } @glynn_bird
- 34. App LogicFile storage DatabaseStatic file server 34IBM Cloud / © 2018 IBM Corporation Components Session Store
- 36. 36 @glynn_bird
- 38. 38 @glynn_bird
- 39. App LogicFile storage DatabaseStatic file server 39IBM Cloud / © 2018 IBM Corporation Components Session Store
- 40. 40IBM Cloud / January 31, 2018 / © 2018 IBM Corporation Glynn Bird Developer Advocate IBM @glynn_bird
- 41. Image credits 41 Prototype app created with proto.io https://unsplash.com/photos/2h5eBF8aRhM https://unsplash.com/photos/ngqyo2AYYnE https://unsplash.com/photos/9A64wd1QaAU https://unsplash.com/photos/A4z0UBgAwyc https://www.netlify.com/press/
Editor's Notes
- I'm a developer and the promise of "the cloud" was that it would allow infrastructure to be easier to provision & manage. But as a direct consequence of cloud computing, my role as developer became a "DevOps role. I was no longer only responsible for the code that runs, I was increasingly responsible for the infrastructure it runs on - servers, networking, security, operating systems, storage etc. I understand the "DevOps" thing - I've done it, but I'd rather it were MORE Dev and LESS Ops. I didn't ask to be a SysAdmin - I just want to write code!
- The story of the cloud computing (in brief) is how the size of the unit of computing that you buy has gone down from - physical servers that you owned and hosted, to physical servers that you racked in someone else's data centre to physical servers that you leased per unit of time to virtual servers that could be spun up and down on demand to containers that can be brought to life in an "instant" Costs have fallen dramatically. The size of the unit of computing you can buy is fallen to near zero and the speed at which a unit of computing can be brought to bear has fallen to near zero. So now we enter the "serverless" era….
- The word "serverless" is very misleading - serverless doesn't mean no servers, it just means your code is running on servers that you are not responsible for. The story of serverless platforms is the story of Cloud computing taken to its logical extreme. I'll show you today how you can build a full dynamic website that is "serverless" from top to bottom.
- "Serverless" builds on containers but instead of having long-running containers, a serverless service will have many short-running containers instead. A better name for "serverless" is "functions-as-a-service". You deploy as many functions (sometimes called actions) to a cloud-based service and then feed it work. The serverless service manages the scale required and you only pay for what you use. If you use nothing, you pay nothing. No fixed costs!
- So let's imagine we have an idea for a web app. It might be a website to start with, but maybe later we'll make an iPhone/Android app out of it. It's called InstaPuppy - a photo sharing website for dogs
- You can sign up - get a username & password and then login.
- Once you're in you can share pictures with your friends - but the twist is they have to be pictures of dogs.
- You can favourite other pictures, share them with you friends, and so that we can make some money….
- There is a payment path to by prints of the pictures you like.
- To build such a system we're going to need five pieces of technology a static file server - something to deliver our HTML, CSS, JavaScript, Fonts and icons to our users file storage- somewhere to store our uploaded data - this needs to be resilient, unlimited in capacity and cheap. This is our store of unstructured data database - a structured data store to keep our users, file meta data, purchases app logic - this is the code of our application e.g code that decides whether a username & password is correct to and to allow people to log in session store - another data store, but this time storing temporary sessions. The user gets a cookie that identifies them and allows them access to a single user account for a time. The session (stored on the serve side) is paired with that cookie and stores a small piece of data about that user and their recent activity. Session stores need to be fast!
- Our first stab at making this app is to rent a server for $10 a month and put EVERYTHING on it. We can choose an operating system, add the packages we need to run our app (Java, Node.js, PHP whatever). We can use the server's hard disk for storage and run a web server (Apache Httpd/Nginx) and a database (MySQL).
- Although it's cheap and convenient to run everything on once box, it has some drawbacks if the box goes down (either with a fault or for maintenance), your site is down if you get a lot of traffic then your application is difficult to scale
- So let's split out the web server which is serving out static content and doing our "business logic" and file storage from our database. So we have two separate servers, connected by a private link (your database server is unlikely to be on the public internet). But now we have two single points of failure. If either of these systems goes down, we are offline - 0.99 * 0.99 = 0.98. We've added more capacity, but we've made our system less resilient!
- To add resilience we need at least two of everything. Multiple app servers behind a load balancer and multiple databases (with private replication channel) behind its own load balancer. But what about file storage. We can't have each app server storing uploaded content on its own hard disk any more...
- So let's not built it that way. Let's see if we can build a full dynamic website, where all the components are "serverless" - not "serverless" as in "functions as a service" necessarily, but serverless in the sense that I (the developer) don't have to deal with servers operating systems networking uptime scaling
- Instead of running multiple web servers on servers which you have to mange, much better to put your static content in Git and hand it over to a service that will serve it out for you. Services such as Github Pages or Netlify will serve out your static site for free (paid plans available) and serve your content via a CDN so static assets are brought closer to your users. Closer = faster in distributed system. You don't even have to think about it. They'll also handle HTTPS termination, custom domains, caching and more.
- You don't have to go back to having complete HTML pages which you have to edit laboriously. Using tools like Jekyll, you can build websites using themes, layouts and includes so that common code remains modular.
- Every cloud provider has an Object Storage service that allows unlimited, PAYG storage of unstructured data, such as your uploaded dog pictures. They are very cheap per GB and have an extremely high up time - Amazon claims 99.999999999% (9 9s). You usually get to decide how "resilient" your storage is to be i.e. how many copies are stored in the same/different geographies. You may also be able to tie your Object Storage bucket to a CDN service to allow the uploaded content to be served out too. That's one less thing for you to think about. Now we've ticked off 2 of our 5 things using serverless technology.
- We can identify the smallest actions that our app needs to be able to function. A user registers with an email and password. We send them a confirmation email the use clicks on a link in the email and they get get confirmed The user can log in to a confirmed account with their email & password The user can log out
- Once logged in a user can - upload a picture favourite someone else's picture share a picture the resize action is used by the /pic/upload endpoint so that we have images of the right size and a thumbnail image
- We are going to use an external payment service like Stripe or PayPal we need an place to start the process after which the user is bounced to the payment provider if they enter payment details correctly they are bounced back to the "done" endpoint or if they fail or cancel they reach the "quit" endpoint
- By doing this we have identified a number of actions that require computing resource. Each of these is a small piece of code that does the work - THESE ARE OUR SERVERLESS ACTIONS! We'll see how to create a serverless action in a moment
- Remember our old application stack where we had to run a web server, on our own application stack on an operating system. We had to manage server patches and version changes and reboots. We had to manage the load balancing of the traffic
- With serverless, we don't need to run a web server at all - we need LESS CODE - just the bit that processes the data. We don't care about operating systems or scale anymore. We don't need a load balancer or a queue - that is handled by the framework. We simply need to say "here's the code". You need to run this on PHP7.1, Node 8.2, or whatever. I'll send you work.
- AWS Lambda was the first serverless platform and is the biggest. They don't need MY help to promote that product any more so let's look at some others….
- Microsoft, Google and IBM's clouds all offer "functions-as-a-service" offerrings, so if you're application is on those Clouds, you probably want to use fhe F-a-a-S that comes with that plaform. You will also see F-a-a-S services attached to other tech services, usually ones which do event-driven, real-time things. e.g. Iron.io allows you to attach functions to things arriving in their queue product. Twillio allows you to execute code in response to incoming message or call events. If you're developing apps with those services, then the build-in F-a-a-S makes sense. If you don't want to be locked into a vendor, then you might look around for an open-source F-a-a-S product and you'll come across Apache OpenWhisk. You can run OpenWhisk yourself or you can consume it as a service from one of a number of providers. I
- OpenWhisk is open-source. You can run it on your local machine for development, or you can run it and manage it yourself on your own computing infrastructure. In the spirit of a "serverless full stack", we probably don't want to do any Ops ourselves… so
- it's best to pick an "OpenWhisk-as-a-service" provider - IBM is one of those, but there are others so you are not locked into a single provider.
- Code can be deployed in a UI, but I prefer the command-line tools because I can script everything. "wsk" is the OpenWhisk command-line client - in this example, I'm deploying a "hello world" action that is in a JavaScript file. It's that simple
- Actions can be grouped into "packages". This is handy because you might want a package to share configuration with every other action in the package. The hierarchy is also useful because it matches the structure of our API. We are also doing two extra things: specifying the exact Node.js runtime to use e.g. Node.js 7.12 and, providing a zip file full of code instead of a single file - now I can have Node.js code with dependencies too.
- Finally, here's a really quick way of turning your code into an API call with "--web true". There's a fully featured API Gateway but this is a really simple way to do it.
- Just to get an idea of how simple the code is, here's a Node.js script that reads the current Bitcoin price from an API and writes it to the database. I could trigger this every minute and I would have a "cron" running in the Cloud with no infrastructure. Notice how simple the code is. It only deals with one task, it has very little scaffolding (no web server , queue etc)
- So that's ⅗ of our components built using serverless technology. Now the difficult bit. Scaling the storage of state is much harder. You can't just spin up lots of stateless machines and put them behind a load balancer. Luckily, this too is a solved problem….
- First the session store. I'm going to use Redis. Redis is an in-memory database. It's really fast and often used for caching to speed-up and take the load off slower back-end systems. In this case we can use it to store sessions - we can create time-limited keys that relate the session token to a blob of data that describes who's logged in.
- Redis is open-sourced and easily built to run on your own machine. Running it in a resilient cluster is harder, but the folks as Compose.com are here to help. They offer a number of databases as easy to run services for a small fee. Just choose the one you want and click deploy and it's available in minutes. One tip is that your Redis cluster should preferably be in the same data center as your F-a-a-S code - nearness = speed in a distributed system.
- I've chosen Apahce CouchDB as the database. There are any number of other databases I could have used, but Apache CouchDB is open-sourced, easy to get started with - you don't have to tell the database about the schema you are using. I could run it myself, but as I need a "serverless" solution, I need a Database-as-a-service
- For that I'm choosing Cloudant - it is a Apache CouchDB as a service. Sign up and you get a URL and start saving data right away.
- So now I have all parts of my application running on serverless or "as-a-service" technology. For low traffic sites, this can result in zero costs, because these services usually have a generous free tier. If you application is successful and you're making money, then you pay for the resources you use…. More important than that, I am no longer doing "Dev Ops". I'm only writing code!