Go containers? Go serverless?
Hausenblas, Michael
This talk compares the approaches using a simple Go app, once implemented as containerized microservices and once as a serverless app and discusses advantages and limitations of each approach. Increasingly, we find deployments of Go in either a containerized setup (read: Kubernetes) or serverless (think: AWS Lambda). This talk compares the approaches using a simple Go app, once implemented as containerized microservices and once as a serverless app and discusses advantages and limitations of each approach. We will review the workflow end-to-end, and touch on topics like defining domain boundaries, communication, sharing state, observability, and costs, both in terms of learning curve and actual money. Parts of the app will be demoed live.
 Okay, so the next talk is a good friend of mine and he's going to be talking about containers and serverless and other buzz words. Exactly. Any questions? A round of applause for him, please. Thank you. All right. Since I'm a bit behind, I will skip that first slide. It doesn't really matter. I'm a developer at the head hanging out at conference parties and pitching about other products, so that's fine. And all right. So what I want to do with this talk is imagine you have a monolith written go. Boss comes around, she tells you, modernize it, make it cloud native. And you go like, all right. So we have two options, very popular ones, containerized microservices on the one hand or the other hand, serverless lambda. So the model is really very, very simple. It's called imagine. You can upload some images and it extracts some metadata. Very simple. And I'm not going to go into detail here. I'm going to right jump into the first option and that is containerized microservices. And now there will be a live demo, which means I'm going to put away the mic for a moment. If you want to follow along, you can go to that GitHub repo and try it out yourself if you have a Kubernetes cluster running around. I got it. That's my job. All right. It's just a couple of commands, bringing up the storage and bringing up the app. Brilliant. Wow. And exposing that front end. So just want to give you a little bit of a feeling how that actually looks like. And now we should see if all the parts are up, we should see that front end up here. Okay. Cool. Yeah. Now we can upload something, blah, blah, blah, blah. And at some point in time, the metadata extraction will kick in, which is just a dimension here. And we're not going to wait for that. Yeah. Okay. So this is how it looks like. Supposed to work. Now, thank you. Let's have a look at how it is done. First we step back a bit and have a look at what is the underlying platform and that is Kubernetes. Kubernetes is a container lifecycle management system using declarative APIs and control loops and super extensible. A lot of moving parts there as a developer, you typically don't really have to deal with all these interfaces and so on. You can really focus on developing the application. However, if we look at that, we end up from that monolith with a couple of microservices. One that is essentially serving the static assets of the UI, CSS and so on. And exposing the HTTP API, allowing you to upload an image and to list the images and the metadata. And the other one is a batch metadata extraction. And again, the metadata is really just dimensions here. And then I'm using Minio, which is essentially a three clone, to store the images and the metadata. It essentially, this container as microservices set up just leverages the Kubernetes abstractions, deployment services and so on. And that's how it actually looks like. So you've got these three deployments there, with the parts there, everything stateless. The state is essentially in Minio. And then you have the endpoints there. And you've just seen how this deployed. It's pretty straightforward. The trick is a little bit how do you map or how do you extract how you break down that monolith into one or more deployments there? Alternative system designs, I could have just done a lift and shift, essentially taking that monolith and put that into a part. I could also have the different containers in one part and use a local volume to share the images and the metadata. Or I could have different parts and using persistent volume rather than Minio. Minio in that case is a little bit more flexible because I'm not dependent on the environment where I am to see what kind of read write volumes I have available. All right, let's move on to serverless. Here the demo is likely a video because it takes a little longer. Okay so there's a make file. I don't think you can really see that very well. Essentially using SAM, so the serverless application model CLI, which under the hood is just cloud formation. You have a couple of buckets there where you have the images, the code and so on. And then it deploys that taking too many minutes. We're not going to wait for that until it's there. And yeah, you see the stack coming up and at some point in time the Lambda functions are there. All the code is ready. The API gateway so that you can hit the functions there. And yeah, at the end of the day all that is needed is essentially in the last step to wire the front end which is statically served from an S3 bucket to the UI so that the front end actually has the correct HTTP end points. Yeah. Okay. End result should be the same obviously. Yeah, you've got CloudWatch for the logs. Not so super interesting but essentially more or less besides the provisioning, more or less the same steps. All right. So what is serverless? Service is really just an umbrella term. For a couple of things like functions of service, their databases and data stores, object storage, QS, query services and all of that essentially means you don't have to provision anything. You're only paying for what you're actually using. You're not paying all the time when it's running just for what you're actually consuming. Typically, everything is nicely managed there. There are nice APIs there. It's really kind of this operation model where you can focus on your business logic and leave the whole operational part to some provider. So functions of service. That's the service concept that I've been using here to implement that imagine application. It's essentially event driven. So you have some kinds of events that could be a HTTP call through the API gateway. It could be a new images uploaded into an S3 bucket or whatever. You have one or more short running stateless functions. And because they're stateless, it means you have to externalize the state. You need to put that somewhere. It could be, you know, a ration database. It could be an Ocicle database, message queue, whatever. So how does it look like? Serverless. Got three Lambda functions. One for uploading the image, one for listing the images and the metadata along with it, and one that does the metadata extraction again just a dimension. And using a three is the shared storage for the images and the metadata and serving the static assets for the UI. And as you have seen, using SAM to deploy the Lambda functions. If you're using SAM or something else, doesn't matter, but don't use the low level stuff. Don't use the manually doing the deployments of Lambda functions and so on. You will have a bad day. And if you look at the Git commit history, you will see how much pain I went through. So that is how it looks like, you have the buckets there and the Lambda functions and the HDP API gateway that triggers the respective functions there. And the metadata extraction is essentially triggered by a cloud event every, I think, one minute or whatever, looks into that bucket and sees if there is a new image extracting that and putting the metadata back then. All right. Alternatively, I could have used a trigger on that bucket where the image is uploaded to trigger that metadata extraction rather than using a periodic click, a cloud watch event. And I could have replaced the two-phase presigned URL that I have there to allow someone to upload something with something like Kumi2, for example. Definitely other options as well. These two came to mind. All right, have a look at comparison. How do they compare? Actually they're quite similar in certain things. They're different. But if you look, you have unit of deployments, part of the function. You have some artifacts you need to put somewhere, so container image in the case of communities, a zip file in case of Lambda, put them into registry, into a free bucket. The biggest difference there in terms of event triggers is that communities, it's not entirely true with Canadians now, but Vanilla communities doesn't really have this notion of events that you can use there in Lambda, where pretty much all the public cloud offerings that offer some functions of service they are built in. State, you can have state, stateful sets and other things, custom resources. In case of Lambda, it's stateless, right? There is no state in that function. Latency-wise, yeah, can be sometimes challenging. Get back to that in a moment. Observility, obviously, you're a bit more locked into if you're using Cloud Provider there. The main point, as I already mentioned, is serverless. You only really pay what you consume. And essentially, with all the stuff that I've been doing there, my bill was never more than one cent, that's pretty much it. The main point in terms of lift and shift, you can do that with communities. You can take an existing application, just put it in a container and run it. Not saying that's the best option, but you can. With serverless, you can't. You really need to re-architect. And local development, it's doable in communities. There are a couple of things that allow you to do it less painful, scaffold and many other things. With Lambda, it's limited. You can essentially only use Gateway and Lambda itself. So anything, any other, like the S3, whatever, I would need to go into life. It doesn't allow me to emulate that locally. So what's the good? In terms of communities, definitely provides portability. You can start on premises, move to Cloud, another Cloud. That's awesome. If that is a focus point. Because definitely, I would argue, developers can focus on the business logic. So the SAM CLI gives you quite a lot of leverage and you can more or less focus on the business logic really. And for both of the containers and serverless, solutions accounted and the ratio of code versus YAML is pretty much the same. So you will have to deal with YAML one way or the other. I'm sorry for that. It increases development velocity. So you get stuff faster out there, depending on how fine granular you do, the microservices could end up pretty much the same. Then not so great. In terms of communities, can be a bit of a pain point handling the container images, especially if you think about the overall development cycle. So imagine every time you change something in one of the services, you have to build a new image, you have to push it to registry, KUNIDIS needs to pull it and deploy it again. As I said, there are certain tools that allow you to shortcut certain of these phases, but that turns out to be for many people, many organizations, quite challenging. And the core DX of KUNIDIS is rather poor. It's not really a nice way for a developer to get into that. You really need to get the tooling right to make that not so painful. Serverless, you can have language dependent latencies. So obviously, JVM has other code start characteristics as Python, for example, and state hydration. So that's probably one of the most challenging things. Imagine your serverless function, your Lambda function, has some dependency. It needs to pull some state from whatever, some database out there, whatever. Before it doesn't have that state, it can't do it. It's work. It's what is referred to state hydration. Because it is stateless, you do have to do that every time. Doesn't matter how warm that functions, if everything is already there, you will need that or you will run into that issue. All right. The rest is just a couple of resources in articles and a few books that I can recommend that you can read there. And yeah, I think we have enough time for Q&A. And that was actually my main goal because I wanted to, because everything else is there, right? You can go to that repo and try it out yourself. Should be rather well documented. Just have a look at that repo. Slideshop as well on the website. So I'd like to hear from you. Where are you? Do you have a boss that comes up to you and says, let's modernize it? Do you have any questions, any concerns? No one in that position. One over there. Should I? If you wanted to run absolutely everything, so your front end behind the API gateway, how straightforward is authorization and authentication and so on? It was not the biggest problem. The biggest problem that I had was essentially passing the payload through the API gateway to the Lambda function. And that's where I ended up with the pre-signed URLs because the ping and JPEG just didn't go through. So that's one thing I ran into. Everything else, just the normal IAM policy then where you need to decide how to do things. But yeah, not that hard. So when you have around, let me say, 300 Lambda functions and they run and you change something and how do you ensure that everything still runs? So what are the quality strategies? That's an excellent question. It's one of the critique points I always have with Lambda that unless, so either you have a handful of functions, right? Or you're in a bad place. If you have a lot of functions, you need some kind of orchestration, effectively, that allows you to look all over that. There are certain projects. I know that IBM came up with a project. I think there is something at AWS as well. But many, many functions. So if you take an existing monolith and you end up with, let's say, 300, 400, whatever Lambda functions, you're probably ending up in a place where you need to write that kind of orchestrator yourself, right? To figure out what is going on, what is up, what is new, whatever. Yeah. Definitely not the best place. Any more questions? Yes. I'm just going to throw that in there. You can't, right? Thanks. Very nice talk. Thank you. Just a question. What do you think about hybrid architectures where Kubernetes will be served as a long term, you know, like main application controller? And the functions will be used only for heavy stuff, like not to rent lots of big machines, so it could be probably more efficient. So I've got the question right. It's like this hybrid setup where you assume, but let's put it that way. If you do have a Kubernetes cluster already, if you're subscribed to that, then it's perfectly possible and you probably should be using things like OpenFast, there's OpenWiz, there are many, many Q-blasts, there are many, many options that you can run as frameworks on top of Kubernetes. If you have already subscribed to the idea of Kubernetes, right? Again, the main point of Kubernetes being that portability, so you're not more or less not locked into a certain vendor's API. If portability is not that big of an issue, so that's where you have to somehow draw the line or see what works for you best. But definitely what you described as this bang bang or whatever you used, yes, I subscribed to that idea that if you are already committed to Kubernetes, if you have Kubernetes as the base platform, using serverless platforms on top of that, anything from Kennedy up to OpenWiz or whatever, definitely a great way to go. Not saying that everything is already very mature there, definitely not compared to Lambda, but it's getting there. Any more questions? Yes. For the serverless, how about the testing? How do you, what are your approaches on that? So that was probably the biggest pain point. So I initially was like, oh, cool. Sam allows me to do that locally, right? So I figured out actually all that works is the HTTP API gateway and the Lambda itself. So any kind of state, I had to go online, which means I ended up doing everything online. So essentially change something, and that's what the make actually does, right? Uploads it to a three bucket, kicks it off, deploys it, and it's there. In average, maybe once it's up, the initial CloudFormation deployment takes a few minutes, but once it's up, a matter of 10, 15 seconds until you have the new version there. It's not that bad, unless you have huge dependencies and you're pumping up, I don't know, 500 megabytes every time. But you end up, that's why I said it's very limited. I'm not saying that this might not change. Sam might become more powerful. Sam is essentially just using locally Docker to emulate that API that is has there. But again, it only gives you the HTTP API gateway and the Lambda function. Anything else you need to go online. Yes? What about serverless containers? So like Fargate, which is kind of like a managed environment for containers, deploying containers. Is it like trying to achieve the same abstraction layer that Kubernetes is trying to do, but in a more, in a, providing more of like a more managed environment? That's the question. And I wouldn't have expected anything else from Jana, obviously. So for the people who don't know what Fargate is, essentially, you think of it as, you already called it serverless container, whatever. You don't need to manage a Kubernetes cluster, whatever. You just say, here is my container image, whatever, and here, you know, run that task, long running or whatever. I find it great in the sense that, you know, all that management overhead goes away. I think we still have to see, and then you get up and running extremely quick. The challenge that I see is twofold. On the one hand, mentioned already the main point of Kubernetes being this portable system, but you can move between different environments. Can you do Fargate, I don't know, you know, in your on-premise environment, then move to the cloud. And the other thing, as I said, in terms of extending it, if you have the need, Kubernetes provides you with a wonderful extension mechanism called custom resources that allow you to essentially do any kind of workload, extend Kubernetes in a sense that it understands your workload. You might not have the same, yeah, possibilities there with Fargate. These would be the kind of limitations, otherwise I would say absolutely limitations. These are the current things that I don't really have a good answer to, but otherwise, yeah, absolutely, no doubt. Any more questions? We have two minutes. Okay. What's your opinion about versioning of serverless Lambda functions? So they are that because when I have APIs and I have versions, then I become trouble and if I have even smaller functions like serverless Lambda functions, the trouble gets even bigger, I guess, if I introduce versioning. That's kind of like implicitly done. So every time you deploy a new function, you get essentially a new zip file or whatever in there that's automatically done for you. I'm not entirely sure if you can actually go back that easily. I've never done that. But yeah, it's automatically done. So we don't really have to care about that in case of Lambda. I'm not sure. I've never tried that. Sorry. The question was, can you use two different versions of a function at the same time? And I said, I haven't tried it out. Might be the case. I'm not sure. All right. Cool. Thank you. Thank you.
 Okay, so the next talk is a good friend of mine and he's going to be talking about containers  and serverless and other buzz words.  Exactly.  Any questions?  A round of applause for him, please.  Thank you.  All right.  Since I'm a bit behind, I will skip that first slide.  It doesn't really matter.  I'm a developer at the head hanging out at conference parties and pitching about other  products, so that's fine.  And all right.  So what I want to do with this talk is imagine you have a monolith written go.  Boss comes around, she tells you, modernize it, make it cloud native.  And you go like, all right.  So we have two options, very popular ones, containerized microservices on the one hand  or the other hand, serverless lambda.  So the model is really very, very simple.  It's called imagine.  You can upload some images and it extracts some metadata.  Very simple.  And I'm not going to go into detail here.  I'm going to right jump into the first option and that is containerized microservices.  And now there will be a live demo, which means I'm going to put away the mic for a moment.  If you want to follow along, you can go to that GitHub repo and try it out yourself if  you have a Kubernetes cluster running around.  I got it.  That's my job.  All right.  It's just a couple of commands, bringing up the storage and bringing up the app.  Brilliant.  Wow.  And exposing that front end.  So just want to give you a little bit of a feeling how that actually looks like.  And now we should see if all the parts are up, we should see that front end up here.  Okay.  Cool.  Yeah.  Now we can upload something, blah, blah, blah, blah.  And at some point in time, the metadata extraction will kick in, which is just a dimension here.  And we're not going to wait for that.  Yeah.  Okay.  So this is how it looks like.  Supposed to work.  Now, thank you.  Let's have a look at how it is done.  First we step back a bit and have a look at what is the underlying platform and that is  Kubernetes.  Kubernetes is a container lifecycle management system using declarative APIs and control  loops and super extensible.  A lot of moving parts there as a developer, you typically don't really have to deal with  all these interfaces and so on.  You can really focus on developing the application.  However, if we look at that, we end up from that monolith with a couple of microservices.  One that is essentially serving the static assets of the UI, CSS and so on.  And exposing the HTTP API, allowing you to upload an image and to list the images and  the metadata.  And the other one is a batch metadata extraction.  And again, the metadata is really just dimensions here.  And then I'm using Minio, which is essentially a three clone, to store the images and the  metadata.  It essentially, this container as microservices set up just leverages the Kubernetes abstractions,  deployment services and so on.  And that's how it actually looks like.  So you've got these three deployments there, with the parts there, everything stateless.  The state is essentially in Minio.  And then you have the endpoints there.  And you've just seen how this deployed.  It's pretty straightforward.  The trick is a little bit how do you map or how do you extract how you break down that  monolith into one or more deployments there?  Alternative system designs, I could have just done a lift and shift, essentially taking  that monolith and put that into a part.  I could also have the different containers in one part and use a local volume to share  the images and the metadata.  Or I could have different parts and using persistent volume rather than Minio.  Minio in that case is a little bit more flexible because I'm not dependent on the environment  where I am to see what kind of read write volumes I have available.  All right, let's move on to serverless.  Here the demo is likely a video because it takes a little longer.  Okay so there's a make file.  I don't think you can really see that very well.  Essentially using SAM, so the serverless application model CLI, which under the hood is just cloud  formation.  You have a couple of buckets there where you have the images, the code and so on.  And then it deploys that taking too many minutes.  We're not going to wait for that until it's there.  And yeah, you see the stack coming up and at some point in time the Lambda functions  are there.  All the code is ready.  The API gateway so that you can hit the functions there.  And yeah, at the end of the day all that is needed is essentially in the last step to  wire the front end which is statically served from an S3 bucket to the UI so that the front  end actually has the correct HTTP end points.  Yeah.  Okay.  End result should be the same obviously.  Yeah, you've got CloudWatch for the logs.  Not so super interesting but essentially more or less besides the provisioning, more or  less the same steps.  All right.  So what is serverless?  Service is really just an umbrella term.  For a couple of things like functions of service, their databases and data stores, object storage,  QS, query services and all of that essentially means you don't have to provision anything.  You're only paying for what you're actually using.  You're not paying all the time when it's running just for what you're actually consuming.  Typically, everything is nicely managed there.  There are nice APIs there.  It's really kind of this operation model where you can focus on your business logic and leave  the whole operational part to some provider.  So functions of service.  That's the service concept that I've been using here to implement that imagine application.  It's essentially event driven.  So you have some kinds of events that could be a HTTP call through the API gateway.  It could be a new images uploaded into an S3 bucket or whatever.  You have one or more short running stateless functions.  And because they're stateless, it means you have to externalize the state.  You need to put that somewhere.  It could be, you know, a ration database.  It could be an Ocicle database, message queue, whatever.  So how does it look like?  Serverless.  Got three Lambda functions.  One for uploading the image, one for listing the images and the metadata along with it,  and one that does the metadata extraction again just a dimension.  And using a three is the shared storage for the images and the metadata and serving the  static assets for the UI.  And as you have seen, using SAM to deploy the Lambda functions.  If you're using SAM or something else, doesn't matter, but don't use the low level stuff.  Don't use the manually doing the deployments of Lambda functions and so on.  You will have a bad day.  And if you look at the Git commit history, you will see how much pain I went through.  So that is how it looks like, you have the buckets there and the Lambda functions and  the HDP API gateway that triggers the respective functions there.  And the metadata extraction is essentially triggered by a cloud event every, I think,  one minute or whatever, looks into that bucket and sees if there is a new image extracting  that and putting the metadata back then.  All right.  Alternatively, I could have used a trigger on that bucket where the image is uploaded  to trigger that metadata extraction rather than using a periodic click, a cloud watch  event.  And I could have replaced the two-phase presigned URL that I have there to allow someone to  upload something with something like Kumi2, for example.  Definitely other options as well.  These two came to mind.  All right, have a look at comparison.  How do they compare?  Actually they're quite similar in certain things.  They're different.  But if you look, you have unit of deployments, part of the function.  You have some artifacts you need to put somewhere, so container image in the case of communities,  a zip file in case of Lambda, put them into registry, into a free bucket.  The biggest difference there in terms of event triggers is that communities, it's not entirely  true with Canadians now, but Vanilla communities doesn't really have this notion of events  that you can use there in Lambda, where pretty much all the public cloud offerings that  offer some functions of service they are built in.  State, you can have state, stateful sets and other things, custom resources.  In case of Lambda, it's stateless, right?  There is no state in that function.  Latency-wise, yeah, can be sometimes challenging.  Get back to that in a moment.  Observility, obviously, you're a bit more locked into if you're using Cloud Provider  there.  The main point, as I already mentioned, is serverless.  You only really pay what you consume.  And essentially, with all the stuff that I've been doing there, my bill was never more than  one cent, that's pretty much it.  The main point in terms of lift and shift, you can do that with communities.  You can take an existing application, just put it in a container and run it.  Not saying that's the best option, but you can.  With serverless, you can't.  You really need to re-architect.  And local development, it's doable in communities.  There are a couple of things that allow you to do it less painful, scaffold and many other  things.  With Lambda, it's limited.  You can essentially only use Gateway and Lambda itself.  So anything, any other, like the S3, whatever, I would need to go into life.  It doesn't allow me to emulate that locally.  So what's the good?  In terms of communities, definitely provides portability.  You can start on premises, move to Cloud, another Cloud.  That's awesome.  If that is a focus point.  Because definitely, I would argue, developers can focus on the business logic.  So the SAM CLI gives you quite a lot of leverage and you can more or less focus on the business  logic really.  And for both of the containers and serverless, solutions accounted and the ratio of code  versus YAML is pretty much the same.  So you will have to deal with YAML one way or the other.  I'm sorry for that.  It increases development velocity.  So you get stuff faster out there, depending on how fine granular you do, the microservices  could end up pretty much the same.  Then not so great.  In terms of communities, can be a bit of a pain point handling the container images,  especially if you think about the overall development cycle.  So imagine every time you change something in one of the services, you have to build  a new image, you have to push it to registry, KUNIDIS needs to pull it and deploy it again.  As I said, there are certain tools that allow you to shortcut certain of these phases, but  that turns out to be for many people, many organizations, quite challenging.  And the core DX of KUNIDIS is rather poor.  It's not really a nice way for a developer to get into that.  You really need to get the tooling right to make that not so painful.  Serverless, you can have language dependent latencies.  So obviously, JVM has other code start characteristics as Python, for example, and state hydration.  So that's probably one of the most challenging things.  Imagine your serverless function, your Lambda function, has some dependency.  It needs to pull some state from whatever, some database out there, whatever.  Before it doesn't have that state, it can't do it.  It's work.  It's what is referred to state hydration.  Because it is stateless, you do have to do that every time.  Doesn't matter how warm that functions, if everything is already there, you will need  that or you will run into that issue.  All right.  The rest is just a couple of resources in articles and a few books that I can recommend  that you can read there.  And yeah, I think we have enough time for Q&A.  And that was actually my main goal because I wanted to, because everything else is there,  right?  You can go to that repo and try it out yourself.  Should be rather well documented.  Just have a look at that repo.  Slideshop as well on the website.  So I'd like to hear from you.  Where are you?  Do you have a boss that comes up to you and says, let's modernize it?  Do you have any questions, any concerns?  No one in that position.  One over there.  Should I?  If you wanted to run absolutely everything, so your front end behind the API gateway,  how straightforward is authorization and authentication and so on?  It was not the biggest problem.  The biggest problem that I had was essentially passing the payload through the API gateway  to the Lambda function.  And that's where I ended up with the pre-signed URLs because the ping and JPEG just didn't  go through.  So that's one thing I ran into.  Everything else, just the normal IAM policy then where you need to decide how to do things.  But yeah, not that hard.  So when you have around, let me say, 300 Lambda functions and they run and you change something  and how do you ensure that everything still runs?  So what are the quality strategies?  That's an excellent question.  It's one of the critique points I always have with Lambda that unless, so either you have  a handful of functions, right?  Or you're in a bad place.  If you have a lot of functions, you need some kind of orchestration, effectively, that allows  you to look all over that.  There are certain projects.  I know that IBM came up with a project.  I think there is something at AWS as well.  But many, many functions.  So if you take an existing monolith and you end up with, let's say, 300, 400, whatever  Lambda functions, you're probably ending up in a place where you need to write that kind  of orchestrator yourself, right?  To figure out what is going on, what is up, what is new, whatever.  Yeah.  Definitely not the best place.  Any more questions?  Yes.  I'm just going to throw that in there.  You can't, right?  Thanks.  Very nice talk.  Thank you.  Just a question.  What do you think about hybrid architectures where Kubernetes will be served as a long  term, you know, like main application controller?  And the functions will be used only for heavy stuff, like not to rent lots of big machines,  so it could be probably more efficient.  So I've got the question right.  It's like this hybrid setup where you assume, but let's put it that way.  If you do have a Kubernetes cluster already, if you're subscribed to that, then it's perfectly  possible and you probably should be using things like OpenFast, there's OpenWiz, there  are many, many Q-blasts, there are many, many options that you can run as frameworks on  top of Kubernetes.  If you have already subscribed to the idea of Kubernetes, right?  Again, the main point of Kubernetes being that portability, so you're not more or less  not locked into a certain vendor's API.  If portability is not that big of an issue, so that's where you have to somehow draw the  line or see what works for you best.  But definitely what you described as this bang bang or whatever you used, yes, I subscribed  to that idea that if you are already committed to Kubernetes, if you have Kubernetes as the  base platform, using serverless platforms on top of that, anything from Kennedy up to  OpenWiz or whatever, definitely a great way to go.  Not saying that everything is already very mature there, definitely not compared to Lambda,  but it's getting there.  Any more questions?  Yes.  For the serverless, how about the testing?  How do you, what are your approaches on that?  So that was probably the biggest pain point.  So I initially was like, oh, cool.  Sam allows me to do that locally, right?  So I figured out actually all that works is the HTTP API gateway and the Lambda itself.  So any kind of state, I had to go online, which means I ended up doing everything online.  So essentially change something, and that's what the make actually does, right?  Uploads it to a three bucket, kicks it off, deploys it, and it's there.  In average, maybe once it's up, the initial CloudFormation deployment takes a few minutes,  but once it's up, a matter of 10, 15 seconds until you have the new version there.  It's not that bad, unless you have huge dependencies and you're pumping up, I don't know, 500 megabytes  every time.  But you end up, that's why I said it's very limited.  I'm not saying that this might not change.  Sam might become more powerful.  Sam is essentially just using locally Docker to emulate that API that is has there.  But again, it only gives you the HTTP API gateway and the Lambda function.  Anything else you need to go online.  Yes?  What about serverless containers?  So like Fargate, which is kind of like a managed environment for containers, deploying containers.  Is it like trying to achieve the same abstraction layer that Kubernetes is trying to do, but  in a more, in a, providing more of like a more managed environment?  That's the question.  And I wouldn't have expected anything else from Jana, obviously.  So for the people who don't know what Fargate is, essentially, you think of it as, you already  called it serverless container, whatever.  You don't need to manage a Kubernetes cluster, whatever.  You just say, here is my container image, whatever, and here, you know, run that task,  long running or whatever.  I find it great in the sense that, you know, all that management overhead goes away.  I think we still have to see, and then you get up and running extremely quick.  The challenge that I see is twofold.  On the one hand, mentioned already the main point of Kubernetes being this portable system,  but you can move between different environments.  Can you do Fargate, I don't know, you know, in your on-premise environment, then move to  the cloud.  And the other thing, as I said, in terms of extending it, if you have the need, Kubernetes  provides you with a wonderful extension mechanism called custom resources that allow you to  essentially do any kind of workload, extend Kubernetes in a sense that it understands  your workload.  You might not have the same, yeah, possibilities there with Fargate.  These would be the kind of limitations, otherwise I would say absolutely limitations.  These are the current things that I don't really have a good answer to, but otherwise,  yeah, absolutely, no doubt.  Any more questions?  We have two minutes.  Okay.  What's your opinion about versioning of serverless Lambda functions?  So they are that because when I have APIs and I have versions, then I become trouble and  if I have even smaller functions like serverless Lambda functions, the trouble gets even bigger,  I guess, if I introduce versioning.  That's kind of like implicitly done.  So every time you deploy a new function, you get essentially a new zip file or whatever  in there that's automatically done for you.  I'm not entirely sure if you can actually go back that easily.  I've never done that.  But yeah, it's automatically done.  So we don't really have to care about that in case of Lambda.  I'm not sure.  I've never tried that.  Sorry.  The question was, can you use two different versions of a function at the same time?  And I said, I haven't tried it out.  Might be the case.  I'm not sure.  All right.  Cool.  Thank you.  Thank you.
Go_containers__Go_serverless__A_cloud_native_journey_ItwZQhBH5SU_0_143.png Go_containers__Go_serverless__A_cloud_native_journey_ItwZQhBH5SU_144_695.png Go_containers__Go_serverless__A_cloud_native_journey_ItwZQhBH5SU_696_1007.png Go_containers__Go_serverless__A_cloud_native_journey_ItwZQhBH5SU_1008_1895.png Go_containers__Go_serverless__A_cloud_native_journey_ItwZQhBH5SU_1896_2123.png Go_containers__Go_serverless__A_cloud_native_journey_ItwZQhBH5SU_2124_2411.png Go_containers__Go_serverless__A_cloud_native_journey_ItwZQhBH5SU_2412_2459.png Go_containers__Go_serverless__A_cloud_native_journey_ItwZQhBH5SU_2460_2567.png Go_containers__Go_serverless__A_cloud_native_journey_ItwZQhBH5SU_2568_3059.png Go_containers__Go_serverless__A_cloud_native_journey_ItwZQhBH5SU_3060_3851.png Go_containers__Go_serverless__A_cloud_native_journey_ItwZQhBH5SU_3852_6551.png Go_containers__Go_serverless__A_cloud_native_journey_ItwZQhBH5SU_6552_7223.png Go_containers__Go_serverless__A_cloud_native_journey_ItwZQhBH5SU_7224_7295.png Go_containers__Go_serverless__A_cloud_native_journey_ItwZQhBH5SU_7296_7391.png Go_containers__Go_serverless__A_cloud_native_journey_ItwZQhBH5SU_7392_7799.png Go_containers__Go_serverless__A_cloud_native_journey_ItwZQhBH5SU_7800_8015.png Go_containers__Go_serverless__A_cloud_native_journey_ItwZQhBH5SU_8016_8291.png Go_containers__Go_serverless__A_cloud_native_journey_ItwZQhBH5SU_8292_8543.png Go_containers__Go_serverless__A_cloud_native_journey_ItwZQhBH5SU_8544_8651.png Go_containers__Go_serverless__A_cloud_native_journey_ItwZQhBH5SU_8652_8735.png Go_containers__Go_serverless__A_cloud_native_journey_ItwZQhBH5SU_8736_8879.png Go_containers__Go_serverless__A_cloud_native_journey_ItwZQhBH5SU_8880_9119.png Go_containers__Go_serverless__A_cloud_native_journey_ItwZQhBH5SU_9120_9251.png Go_containers__Go_serverless__A_cloud_native_journey_ItwZQhBH5SU_9252_9455.png Go_containers__Go_serverless__A_cloud_native_journey_ItwZQhBH5SU_9456_9563.png Go_containers__Go_serverless__A_cloud_native_journey_ItwZQhBH5SU_9564_9611.png Go_containers__Go_serverless__A_cloud_native_journey_ItwZQhBH5SU_9612_12503.png Go_containers__Go_serverless__A_cloud_native_journey_ItwZQhBH5SU_12504_20783.png Go_containers__Go_serverless__A_cloud_native_journey_ItwZQhBH5SU_20784_20843.png Go_containers__Go_serverless__A_cloud_native_journey_ItwZQhBH5SU_20844_20999.png Go_containers__Go_serverless__A_cloud_native_journey_ItwZQhBH5SU_21000_21419.png Go_containers__Go_serverless__A_cloud_native_journey_ItwZQhBH5SU_21420_21659.png Go_containers__Go_serverless__A_cloud_native_journey_ItwZQhBH5SU_21660_34967.png Go_containers__Go_serverless__A_cloud_native_journey_ItwZQhBH5SU_34968_35088.png
Okay, so the next talk is a good friend of mine and he's going to be talking about containers and serverless and other buzz words. Exactly. Any questions? A round of applause for him, please. Thank you. All right. Since I'm a bit behind, I will skip that first slide. It doesn't really matter. I'm a developer at the head hanging out at conference parties and pitching about other products, so that's fine. And all right. So what I want to do with this talk is imagine you have a monolith written go. Boss comes around, she tells you, modernize it, make it cloud native. And you go like, all right. So we have two options, very popular ones, containerized microservices on the one hand or the other hand, serverless lambda. So the model is really very, very simple. It's called imagine. You can upload some images and it extracts some metadata. Very simple. And I'm not going to go into detail here. I'm going to right jump into the first option and that is containerized microservices. And now there will be a live demo, which means I'm going to put away the mic for a moment. If you want to follow along, you can go to that GitHub repo and try it out yourself if you have a Kubernetes cluster running around. I got it. That's my job. All right. It's just a couple of commands, bringing up the storage and bringing up the app. Brilliant. Wow. And exposing that front end. So just want to give you a little bit of a feeling how that actually looks like. And now we should see if all the parts are up, we should see that front end up here. Okay. Cool. Yeah. Now we can upload something, blah, blah, blah, blah. And at some point in time, the metadata extraction will kick in, which is just a dimension here. And we're not going to wait for that. Yeah. Okay. So this is how it looks like. Supposed to work. Now, thank you. Let's have a look at how it is done. First we step back a bit and have a look at what is the underlying platform and that is Kubernetes. Kubernetes is a container lifecycle management system using declarative APIs and control loops and super extensible. A lot of moving parts there as a developer, you typically don't really have to deal with all these interfaces and so on. You can really focus on developing the application. However, if we look at that, we end up from that monolith with a couple of microservices. One that is essentially serving the static assets of the UI, CSS and so on. And exposing the HTTP API, allowing you to upload an image and to list the images and the metadata. And the other one is a batch metadata extraction. And again, the metadata is really just dimensions here. And then I'm using Minio, which is essentially a three clone, to store the images and the metadata. It essentially, this container as microservices set up just leverages the Kubernetes abstractions, deployment services and so on. And that's how it actually looks like. So you've got these three deployments there, with the parts there, everything stateless. The state is essentially in Minio. And then you have the endpoints there. And you've just seen how this deployed. It's pretty straightforward. The trick is a little bit how do you map or how do you extract how you break down that monolith into one or more deployments there? Alternative system designs, I could have just done a lift and shift, essentially taking that monolith and put that into a part. I could also have the different containers in one part and use a local volume to share the images and the metadata. Or I could have different parts and using persistent volume rather than Minio. Minio in that case is a little bit more flexible because I'm not dependent on the environment where I am to see what kind of read write volumes I have available. All right, let's move on to serverless. Here the demo is likely a video because it takes a little longer. Okay so there's a make file. I don't think you can really see that very well. Essentially using SAM, so the serverless application model CLI, which under the hood is just cloud formation. You have a couple of buckets there where you have the images, the code and so on. And then it deploys that taking too many minutes. We're not going to wait for that until it's there. And yeah, you see the stack coming up and at some point in time the Lambda functions are there. All the code is ready. The API gateway so that you can hit the functions there. And yeah, at the end of the day all that is needed is essentially in the last step to wire the front end which is statically served from an S3 bucket to the UI so that the front end actually has the correct HTTP end points. Yeah. Okay. End result should be the same obviously. Yeah, you've got CloudWatch for the logs. Not so super interesting but essentially more or less besides the provisioning, more or less the same steps. All right. So what is serverless? Service is really just an umbrella term. For a couple of things like functions of service, their databases and data stores, object storage, QS, query services and all of that essentially means you don't have to provision anything. You're only paying for what you're actually using. You're not paying all the time when it's running just for what you're actually consuming. Typically, everything is nicely managed there. There are nice APIs there. It's really kind of this operation model where you can focus on your business logic and leave the whole operational part to some provider. So functions of service. That's the service concept that I've been using here to implement that imagine application. It's essentially event driven. So you have some kinds of events that could be a HTTP call through the API gateway. It could be a new images uploaded into an S3 bucket or whatever. You have one or more short running stateless functions. And because they're stateless, it means you have to externalize the state. You need to put that somewhere. It could be, you know, a ration database. It could be an Ocicle database, message queue, whatever. So how does it look like? Serverless. Got three Lambda functions. One for uploading the image, one for listing the images and the metadata along with it, and one that does the metadata extraction again just a dimension. And using a three is the shared storage for the images and the metadata and serving the static assets for the UI. And as you have seen, using SAM to deploy the Lambda functions. If you're using SAM or something else, doesn't matter, but don't use the low level stuff. Don't use the manually doing the deployments of Lambda functions and so on. You will have a bad day. And if you look at the Git commit history, you will see how much pain I went through. So that is how it looks like, you have the buckets there and the Lambda functions and the HDP API gateway that triggers the respective functions there. And the metadata extraction is essentially triggered by a cloud event every, I think, one minute or whatever, looks into that bucket and sees if there is a new image extracting that and putting the metadata back then. All right. Alternatively, I could have used a trigger on that bucket where the image is uploaded to trigger that metadata extraction rather than using a periodic click, a cloud watch event. And I could have replaced the two-phase presigned URL that I have there to allow someone to upload something with something like Kumi2, for example. Definitely other options as well. These two came to mind. All right, have a look at comparison. How do they compare? Actually they're quite similar in certain things. They're different. But if you look, you have unit of deployments, part of the function. You have some artifacts you need to put somewhere, so container image in the case of communities, a zip file in case of Lambda, put them into registry, into a free bucket. The biggest difference there in terms of event triggers is that communities, it's not entirely true with Canadians now, but Vanilla communities doesn't really have this notion of events that you can use there in Lambda, where pretty much all the public cloud offerings that offer some functions of service they are built in. State, you can have state, stateful sets and other things, custom resources. In case of Lambda, it's stateless, right? There is no state in that function. Latency-wise, yeah, can be sometimes challenging. Get back to that in a moment. Observility, obviously, you're a bit more locked into if you're using Cloud Provider there. The main point, as I already mentioned, is serverless. You only really pay what you consume. And essentially, with all the stuff that I've been doing there, my bill was never more than one cent, that's pretty much it. The main point in terms of lift and shift, you can do that with communities. You can take an existing application, just put it in a container and run it. Not saying that's the best option, but you can. With serverless, you can't. You really need to re-architect. And local development, it's doable in communities. There are a couple of things that allow you to do it less painful, scaffold and many other things. With Lambda, it's limited. You can essentially only use Gateway and Lambda itself. So anything, any other, like the S3, whatever, I would need to go into life. It doesn't allow me to emulate that locally. So what's the good? In terms of communities, definitely provides portability. You can start on premises, move to Cloud, another Cloud. That's awesome. If that is a focus point. Because definitely, I would argue, developers can focus on the business logic. So the SAM CLI gives you quite a lot of leverage and you can more or less focus on the business logic really. And for both of the containers and serverless, solutions accounted and the ratio of code versus YAML is pretty much the same. So you will have to deal with YAML one way or the other. I'm sorry for that. It increases development velocity. So you get stuff faster out there, depending on how fine granular you do, the microservices could end up pretty much the same. Then not so great. In terms of communities, can be a bit of a pain point handling the container images, especially if you think about the overall development cycle. So imagine every time you change something in one of the services, you have to build a new image, you have to push it to registry, KUNIDIS needs to pull it and deploy it again. As I said, there are certain tools that allow you to shortcut certain of these phases, but that turns out to be for many people, many organizations, quite challenging. And the core DX of KUNIDIS is rather poor. It's not really a nice way for a developer to get into that. You really need to get the tooling right to make that not so painful. Serverless, you can have language dependent latencies. So obviously, JVM has other code start characteristics as Python, for example, and state hydration. So that's probably one of the most challenging things. Imagine your serverless function, your Lambda function, has some dependency. It needs to pull some state from whatever, some database out there, whatever. Before it doesn't have that state, it can't do it. It's work. It's what is referred to state hydration. Because it is stateless, you do have to do that every time. Doesn't matter how warm that functions, if everything is already there, you will need that or you will run into that issue. All right. The rest is just a couple of resources in articles and a few books that I can recommend that you can read there. And yeah, I think we have enough time for Q&A. And that was actually my main goal because I wanted to, because everything else is there, right? You can go to that repo and try it out yourself. Should be rather well documented. Just have a look at that repo. Slideshop as well on the website. So I'd like to hear from you. Where are you? Do you have a boss that comes up to you and says, let's modernize it? Do you have any questions, any concerns? No one in that position. One over there. Should I? If you wanted to run absolutely everything, so your front end behind the API gateway, how straightforward is authorization and authentication and so on? It was not the biggest problem. The biggest problem that I had was essentially passing the payload through the API gateway to the Lambda function. And that's where I ended up with the pre-signed URLs because the ping and JPEG just didn't go through. So that's one thing I ran into. Everything else, just the normal IAM policy then where you need to decide how to do things. But yeah, not that hard. So when you have around, let me say, 300 Lambda functions and they run and you change something and how do you ensure that everything still runs? So what are the quality strategies? That's an excellent question. It's one of the critique points I always have with Lambda that unless, so either you have a handful of functions, right? Or you're in a bad place. If you have a lot of functions, you need some kind of orchestration, effectively, that allows you to look all over that. There are certain projects. I know that IBM came up with a project. I think there is something at AWS as well. But many, many functions. So if you take an existing monolith and you end up with, let's say, 300, 400, whatever Lambda functions, you're probably ending up in a place where you need to write that kind of orchestrator yourself, right? To figure out what is going on, what is up, what is new, whatever. Yeah. Definitely not the best place. Any more questions? Yes. I'm just going to throw that in there. You can't, right? Thanks. Very nice talk. Thank you. Just a question. What do you think about hybrid architectures where Kubernetes will be served as a long term, you know, like main application controller? And the functions will be used only for heavy stuff, like not to rent lots of big machines, so it could be probably more efficient. So I've got the question right. It's like this hybrid setup where you assume, but let's put it that way. If you do have a Kubernetes cluster already, if you're subscribed to that, then it's perfectly possible and you probably should be using things like OpenFast, there's OpenWiz, there are many, many Q-blasts, there are many, many options that you can run as frameworks on top of Kubernetes. If you have already subscribed to the idea of Kubernetes, right? Again, the main point of Kubernetes being that portability, so you're not more or less not locked into a certain vendor's API. If portability is not that big of an issue, so that's where you have to somehow draw the line or see what works for you best. But definitely what you described as this bang bang or whatever you used, yes, I subscribed to that idea that if you are already committed to Kubernetes, if you have Kubernetes as the base platform, using serverless platforms on top of that, anything from Kennedy up to OpenWiz or whatever, definitely a great way to go. Not saying that everything is already very mature there, definitely not compared to Lambda, but it's getting there. Any more questions? Yes. For the serverless, how about the testing? How do you, what are your approaches on that? So that was probably the biggest pain point. So I initially was like, oh, cool. Sam allows me to do that locally, right? So I figured out actually all that works is the HTTP API gateway and the Lambda itself. So any kind of state, I had to go online, which means I ended up doing everything online. So essentially change something, and that's what the make actually does, right? Uploads it to a three bucket, kicks it off, deploys it, and it's there. In average, maybe once it's up, the initial CloudFormation deployment takes a few minutes, but once it's up, a matter of 10, 15 seconds until you have the new version there. It's not that bad, unless you have huge dependencies and you're pumping up, I don't know, 500 megabytes every time. But you end up, that's why I said it's very limited. I'm not saying that this might not change. Sam might become more powerful. Sam is essentially just using locally Docker to emulate that API that is has there. But again, it only gives you the HTTP API gateway and the Lambda function. Anything else you need to go online. Yes? What about serverless containers? So like Fargate, which is kind of like a managed environment for containers, deploying containers. Is it like trying to achieve the same abstraction layer that Kubernetes is trying to do, but in a more, in a, providing more of like a more managed environment? That's the question. And I wouldn't have expected anything else from Jana, obviously. So for the people who don't know what Fargate is, essentially, you think of it as, you already called it serverless container, whatever. You don't need to manage a Kubernetes cluster, whatever. You just say, here is my container image, whatever, and here, you know, run that task, long running or whatever. I find it great in the sense that, you know, all that management overhead goes away. I think we still have to see, and then you get up and running extremely quick. The challenge that I see is twofold. On the one hand, mentioned already the main point of Kubernetes being this portable system, but you can move between different environments. Can you do Fargate, I don't know, you know, in your on-premise environment, then move to the cloud. And the other thing, as I said, in terms of extending it, if you have the need, Kubernetes provides you with a wonderful extension mechanism called custom resources that allow you to essentially do any kind of workload, extend Kubernetes in a sense that it understands your workload. You might not have the same, yeah, possibilities there with Fargate. These would be the kind of limitations, otherwise I would say absolutely limitations. These are the current things that I don't really have a good answer to, but otherwise, yeah, absolutely, no doubt. Any more questions? We have two minutes. Okay. What's your opinion about versioning of serverless Lambda functions? So they are that because when I have APIs and I have versions, then I become trouble and if I have even smaller functions like serverless Lambda functions, the trouble gets even bigger, I guess, if I introduce versioning. That's kind of like implicitly done. So every time you deploy a new function, you get essentially a new zip file or whatever in there that's automatically done for you. I'm not entirely sure if you can actually go back that easily. I've never done that. But yeah, it's automatically done. So we don't really have to care about that in case of Lambda. I'm not sure. I've never tried that. Sorry. The question was, can you use two different versions of a function at the same time? And I said, I haven't tried it out. Might be the case. I'm not sure. All right. Cool. Thank you. Thank you.
popular ones, containerized microservices on the up the storage and bringing up the app. deployments of Lambda functions and so on. You of the containers and serverless, solutions Kubernetes will be served as a long term, you and you probably should be using things like essentially, you think of it as, you already task, long running or whatever. I find it great And the other thing, as I said, in terms of