We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

FaaS You Like It: Create Serverless Functions & Run Anywhere

00:00

Formal Metadata

Title
FaaS You Like It: Create Serverless Functions & Run Anywhere
Title of Series
Number of Parts
490
Author
License
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
"Serverless" is a hot topic right now, and something that a lot of developers are keen to try. A lot of focus has been on implementations that are proprietary to and only run on a single provider's cloud. In this talk, I'll show how you can develop "serverless" functions on your laptop, with an open source platform and run them where you like. However, if you attend a Serverless event, you may come away with the impression that it's a world of proprietary walled gardens from the major cloud providers.
Computing platformFunction (mathematics)BuildingData managementData modelDependent and independent variablesWordCartesian coordinate systemProjective planeBitLaptopOpen sourceBoss CorporationBuildingMoment (mathematics)Endliche ModelltheorieMultiplication signServer (computing)Dependent and independent variablesComputer animation
Server (computing)Structural loadComputer clusterComputer animation
AbstractionOperator (mathematics)Computer animation
Function (mathematics)Computing platformFunctional (mathematics)Functional (mathematics)Service (economics)Computer animation
Integrated development environmentMobile appBoss CorporationStructural loadMultiplication signSoftware developerDatabaseTouchscreenServer (computing)Computer animation
Multiplication signFrequencyUtility softwareTerm (mathematics)Functional (mathematics)
Computer programmingExplosionSystem callComputer programmingTraffic reportingComputer animation
Formal languageComputing platformCloud computingLatent heatFunctional (mathematics)WritingFunctional (mathematics)Point cloudBitFormal languageMultiplicationCASE <Informatik>Computer animation
Functional (mathematics)Formal languageComputer animation
Computing platformOpen sourceElectronic program guideLink (knot theory)Open setComputing platformMereologyRepresentation (politics)Projective planeComputer animation
Function (mathematics)Medical imagingFunctional (mathematics)Functional (mathematics)Endliche ModelltheorieComputer animation
Point cloudLaptopPoint cloudDirectory serviceoutputFunctional (mathematics)Computer fileBoilerplate (text)Server (computing)Context awarenessWebsiteMetadataCodeScripting languagePoint (geometry)Client (computing)Product (business)WindowRevision controlSoftware developerInstallation artRun time (program lifecycle phase)Computer animationSource code
Function (mathematics)Software developerLibrary (computing)outputError messageFunctional (mathematics)outputCuboidFunction (mathematics)Formal languageLibrary (computing)Error messageFunctional (mathematics)Panel paintingComputer animation
Network socketFunction (mathematics)Streaming mediaError messageState diagramoutputServer (computing)Error messageStreaming mediaOpen sourceoutputSoftware maintenanceService (economics)Computer animation
Medical imagingDirectory serviceComputer animation
outputComputer programmingCASE <Informatik>Windows RegistryBinary codeFunction (mathematics)Functional (mathematics)Point (geometry)Wave packetType theoryComputer fileResultantSource code
ArchitectureProcess (computing)Service (economics)Revision controlSensitivity analysisFunctional (mathematics)Function (mathematics)MetadataServer (computing)LaptopData storage deviceMappingError messageInstance (computer science)Computer architectureComputer animation
InfinityPrisoner's dilemmaFactory (trading post)Message passingStandard errorSource code
Function (mathematics)Default (computer science)Computer configurationFunctional (mathematics)Functional (mathematics)International Date LineComputer animation
DataflowFunctional (mathematics)Java appletDialectCodeFunctional (mathematics)LogicMobile appDataflowComputer animation
Row (database)BitMultiplication signComputer animation
MIDIComputer-generated imageryRow (database)Functional (mathematics)Group actionComputer animation
AbstractionFunction (mathematics)Computing platformOpen sourceFormal languagePoint cloudLaptopDatabaseFunctional (mathematics)Computing platformFunctional (mathematics)Open sourceLaptopRepresentational state transferDevice driverConnected spaceEvent horizonQuicksortService (economics)Point cloudTable (information)BitProduct (business)Computer animation
Point cloudOpen sourceComputer animation
Transcript: English(auto-generated)
Hi, everybody. My name is Ewan Slater. My talk today is Faz You Like It, and it's about how you can have serverless, but with a bit more freedom, like, for example, having serverless on your laptop. I work for Oracle, but what I'm talking about here
isn't really my day job. I'm going to talk about FN Project, which is an open source project that Oracle sponsor that I contribute to and try not to let my boss know how much time I spend on it. So, serverless. Is anybody here using serverless at the moment?
What are you using? No, but which platform? Yeah, serverless. The CNCF definition of serverless, and I've put some of the words in bold, is it refers to the concept of building and running applications
that do not require server management, so it's not like a traditional application. We're not going to kick it off and then worry about how it runs after that. And it also describes a finer-grained deployment model where applications are bundled together as one or more functions, and then they're uploaded to a platform,
and then they're executed and they're scaled and billed in response to the exact demand needed at the moment. So not only do we not want to know about them when they're running, but we actually just want them to die when they've finished. This is actually my favorite working definition,
and what this says to me is it's like you want the nice thing, but you don't want all the crap that goes with it and the unpleasantness of, for example, killing a cow or building a whole load of that. So it's really about abstraction. You've still got servers, you've still got network,
you've still got all of the infrastructure and the operations associated with it, and what you want is the capability that that delivers, but you don't want to have to look after it yourself. And that enables us to focus in on delivering the functionality that the business want,
and we're going to deliver that functionality using functions or functions as a service. So if we're in the FAS world, what we're doing is we're writing small functions. If they get big, then you should reappraise
whether you need more functions or whether you should be doing that. They should do one thing, preferably well, and they should be easy to understand so that should make them easy to write, easy to get right, and easy to fix. And then we're going to run them on top of our serverless platform,
which is abstracted infrastructure. And one of the upsides as a developer is it avoids this kind of situation. The business has asked you to go and build something, and you know there's a whole load of setup work that needs to be done beforehand, like installing a database or an old app server or whatever,
and then the boss comes along and thinks you've just been sitting around wasting time for three days because he can't see anything on a screen to play with. Another advantage is in terms of resource utilization. Because our functions are only going to run for a short period of time and then go away,
we should be able to get better utilization of our infrastructure. We're not going to have stuff running when it's idle. And about a year ago, University of Berkeley did a report on serverless, and they said customers benefit from increased programming productivity, and in many scenarios we see cost savings as well.
So this is lovely. Sorry. There are no silver bullets. There are only double-edged swords. And for the record, I am not telling you to go and write everything from now on as serverless and go and rewrite everything you have as serverless.
I didn't say that. So amongst the downsides, it's shiny. It's a new thing. People go, hmm, I would like to play with this new thing. And this leads to what I would call CV++ programming. I want this for my next job,
so let me go and write this other thing that doesn't need serverless in a serverless way. The other problem that we tend to come across is one of lock-in, because you can't just take a serverless function that's written for one serverless platform and go and run it on another one.
Yeah? You're kind of tied to the serverless platform. And then, and this is a big one for me personally, you might find that the platform is tied to a specific cloud vendor, which means that if you decide you don't want to be with that cloud vendor anymore, or you might find that you're writing for customers
who want to be on different clouds, you've got a bit of a problem. So it can be a cage. It's a very nice cage, but I would make sure that you know you've got enough room in there before you get in behind yourself and close the door. And I've been involved with serverless now
for two, two and a half years, and in that time, I've come across people who've been concerned about all of these different freedoms. So portability, that ability to move between clouds and on-premises. Decentralization, people who say specifically, I want to run across multiple clouds in case one has a problem.
Packaging, yeah, they might choose to say, I want to package my cloud functions in the same way that I package my microservices. Local testing, the ability to actually test your stuff locally and see what's going on. And one that led me in, which was language.
Because my favorite language is Ruby. And two and a half years ago, if you went to write serverless functions and you wanted to write them in Ruby, there was very little out there that would let you do it. So I started looking around for something, and I came across the FN project,
which was one of the few that treated Ruby as a first-class citizen. So you can get FN project at fnproject.io, and that will give you a link across to GitHub and a whole bunch of guides. It's a serverless platform. It is container-based. It's open source, Apache 2.0.
It's part of the CNCF landscape and has a representation with CNCF. And what we do is we model functions as containers. So you take the function and its dependency, and you create a self-contained Docker image. And then when it's invoked,
you're going to get that container stood up, and it will run, and then it will go away. So it's ephemeral. It's also a good reason to make your function stateless, because if you write something inside the container on your next invocation, you shouldn't expect to find it there. And the good news is it will run on any cloud,
as long as that cloud will let you run Docker. It will run on-premises, or you can run it on your laptop, in fact, anywhere that you have installed Docker. So if you go to the site and you look at the guides, you'll get an install guide, and there will be a cURL script you can run
if you're on Linux. And then you can go, and after that's all finished, you run FN start minus D. It will tell you don't use that for production because you're supposed to use Helm chart. If you, because production, it should be on Kubernetes. If you run version, you should get back as client version or server version.
If you're on Windows, I know some people who run this on Windows subsystem for Linux. I've not tried that myself. You can run it on Windows on a VirtualBox VM. MacWorld is even easier. You just go brew install FN, and again, you come down, you do FN version. You should get the two and do the start.
That's right. So now we've got it installed. We want to create our first function. So you do FN init minus minus runtime. If you're me, you go Ruby, and then you give it a function name. And it creates a function in the directory
with the name that you gave it. And so you get boilerplate function. And because it's cloud native, there's a YAML file created for you as well because it can't be cloud native unless there's some YAML. So we have a look at our function. We've got require FDK, which is function development kit.
And then we have a boilerplate hello world function will be generated for you. So def my function. Context is like metadata around the call, and the input's actually the input you've been given. And then that's passed to the handle method of the FDK. You point it at the function, and it'll go and run.
And the func YAML just carries some data about the file, in particularly the entry point. We say when the container comes up, it's going to run Ruby func rb. So what we've created is our function code inside a function container, usually sitting on top of the FDK.
And the FDKs, they just basically make it a lot easier for you to write functions. You include the gem or the library or the package, whatever your language calls that kind of thing. Write the function to the function interface, and the FDK provides input data to the function and writes the output and the errors. And we have these FDKs available out of the box.
Come on, quickly. Damn thing. Right, Ruby FDK. What happens if you make helpful suggestions on an open source project?
There. Yeah, and then the person who started it left, so I kind of am the Ruby FDK maintainer. So what happens, all the FDKs work pretty much the same way. The container comes up, the FDK opens a socket, the FN service connects to the socket, and then we get past the input.
It's passed as HTTP over the sockets, which we call HTTP stream. We execute the function, giving it the input and the context, right back on HTTP stream. Errors are written to standard error, which then goes to syslog. You're not playing, are you? If you don't have an FDK,
it's not actually a problem because it's Docker-based. If you run FN init in a directory with a Dockerfile in it, it will assume you want to build a function out of that Dockerfile. So you can either bring your own Dockerfile, or you can template, sort of bring your own image. And we also have a facility called hotwrap,
which is if you've got a command line program and you want to just turn that into a function without doing too much work, you include the hotwrap binary in the Dockerfile and make that the entry point and tell it to go and run that. And it will take the input, feed it into standard input of the command line program and take the output back on standard out
and then ship it back out again. So now we've created our function, we need to deploy it. So we create an application, and then we do the deploy, telling it which app it's going to go to, and then what you'll see is it will do a multi-stage build and push it to your Docker registry.
It could be yours, in this case it's Docker hub. And then your function's created. You might decide that you don't actually want to push it to a registry. So if you're sitting on a train or something like that and you don't really want to be pushing to Docker hub, in which case you say deploy minus minus local, it does the build of the container but doesn't actually push it anywhere else.
And then you want to invoke it. So from the command line, fn invoke fosdem hello, hello world. Now obviously you're not going to be invoking it from the command line most of the time, so you can do an inspect of your function and you get that beautifully memorable URL or come out,
which is the one that it's using internally. You also see things like there's an idle timeout on the function, which I'll talk more about in a sec. And you can do a curl to that URL, but it's easier if you can create a more meaningful URL. So we have a thing called create trigger, the only type is HTTP at the moment,
and you can give it hello URL, and then you wind up with a more meaningful trigger endpoint, which you can hit and get the same result back. You can also have that created for you automatically when you do the init, so you say minus trigger, see, I'm not biased, I'm including node in this,
minus trigger and it will tell it to create there, or you can even just include it in the funk.yaml file for the function and it will create it for you and deploy. So we've got our function container, we've got our function code, we've got our fdk, that is running in Docker, it's actually running in Docker, in Docker.
So the FN server itself runs Docker internally, and then within that we run the function containers. A couple of reasons for that, in the early days it made things a lot more stable because if something blew up we contained the problem. These days the main reason for that
is that it gives us much less sensitivity to the external Docker version because we control the internal Docker version. The actual full architecture for deployment, we'd have Kubernetes, on my laptop I just only ever run Docker,
Docker, FN server, function, we've got a container registry, a metadata store which holds things like the endpoints and a syslog service for errors. Okay, I'm gonna need to go quicker. When an invocation comes in, the request comes in, then the FN server will go and look at the metadata store, say what function maps to that URL,
have I already got an instance of that function running? If I haven't, well if I have I just give the work to it, if I haven't then I stand it up if necessary pulling from the container registry, send the output back to the user, anything that's gone wrong gets written to the syslog service.
So if you raise an exception, then that is going to wind up in the syslog. That's a joke, don't worry, there is actually a book, this is actually a book, prisoner in a toothpaste factory, assuming that you're not a prisoner in a toothpaste factory but you do want to get messages to the outside world, you can just write to standard error
and hope that the police are reading the log and will come and rescue you because you're being held prisoner in a toothpaste factory. I said about the idle timeout, well you were useless anyway. I said about the idle timeout, the functions run at least once and then it waits for that idle timeout before terminating, just so if we get a lot of invocations on the same function
you're not having to pay for the startup cost every single time, you can configure that up or down, your FDK needs to handle multiple invocations or if you're not using one and writing your own you need to remember that and it's another good reason to make your function stateless because you don't want dirt hanging around
from a previous use. Orchestration, the functions are quite small so they're not going to do a great deal individually so we need a way to orchestrate them. In FN we have something called Flow, it's promises based orchestration, unfortunately for those who like XML and YAML and things like that,
it's not a new dialect of that, it's Java or Python and you use that to compose your functions together, it can be synchronous, asynchronous in series, in parallel and it's written in your code as a function and you deploy it within the app as a function. Only your good sense stops you putting business logic into the function,
remember the flow is supposed to be a conductor, not an instrumentalist, if you start getting it to do both at once things will go wrong. Right, I think I've got just time, possibly for some Shakespeare. There is always time for Shakespeare,
so FN in blank, well let's hope so. So what I have is this on bit bucket, I've taken Shakespeare's comedy as you like it,
I've come up with all the different functions that are required for the play to be performed. One got the right result, well that was it, that was it. So if you look at a flow,
so what we see in here is there's the, this is the action of the play,
various characters are added and then we invoke different things, they get disguised, and at the end of the day they should all preferably have a happy ending and get married and one, two, three, four, five, yes, we've had four weddings and no funerals. So, with apologies to Shakespeare.
Yeah, so serverless, it's abstracted infrastructure on top of which we run ephemeral functions for higher productivity and lower costs, but you should beware of lock-in and you have an option, you don't have to just go with AWS or Azure or Google and be locked into the cloud as well as the platform.
FN Project is an open source serverless platform, it's container based, you can write your functions in any language, you can run it in any cloud or on premises or on your laptop. Questions? I guess I've got a minute or two. Otherwise, grab me afterwards, I'm really easy to convince to talk with beer
or tweet me at you and Slater. We are, we were looking at CRDs. I would have to go and check because actually most of the time,
as I said, I don't run it on Kubernetes, I just run it on Docker. Any more for anymore? How do you connect such a function to the database? The question was, how do you connect such a function to the database
and what, well, there's a couple of ways I've seen this done, one I approve of and one I don't, and you can shut up. It is. So, I have seen people do things like wrap a JDBC driver and credentials into a function container
and then use that, and I just look at that and think that's horrible. I don't think the credentials should be in there, and you're opening a JDBC connection that was designed to be a long-lived thing. Me, I would go for a REST API of the database if it has one.
If not, then I would have some, either be sticking stuff into an event service or a queue, which was then going to be read and polled by the database, or just actually, probably if it was me, something with a little bit of Ruby and Sinatra that stood in front of the database, and you send something to it, and then it sorts out writing to the tables
and things appropriately. Okay? Thanks a lot.