Cloud Native Computing Foundation KubeCon + CloudNativeCon North America 2020 - Virtual, 4 Dec 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Serverless or Servicefull - Sebastien Goasguen, Triggermesh

Description

Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2021 Virtual from May 4–7, 2021. Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.

Serverless or Servicefull - Sebastien Goasguen, Triggermesh

While containers and container orchestration has taken the world by storm over the last five years, serverless offering that hides the complexity of the underlying infrastructure and the application management mechanisms are becoming the norm within the main Cloud providers. In this talk we will discuss whether or not serverless should in fact be called "servicefull". Indeed serverless computing architecture is all about using events and functions to integrate cloud services together. The world is not so much without servers, they are definitely still there somewhere, but the world is now full of services. The cloud has become our kernel, it is made of a myriad of API exposing cloud services, our world has become servicefull and not serverless. With this difference exposed we will discuss how k8s extensions can help us integrate services and move towards servicefull applications.

https://sched.co/ekEh

A

Hello, everyone, my name is sebastian glasgen, I'm the co-founder of trigger mesh, and thanks for coming to my virtual kubecon north america 2020 uh talk, the title is serverless or service full, and uh here I am recording- and I hope, uh you're going to have a good time. Listening to this. uh To this talk, so let's go and let's have uh let's get the party started.

A

um We've come a long way. We've gone a long way since uh kubernetes was uh started. You know june july 2014 it's been six years, a little bit a little bit about six years. So it's been, it's been a it's been a while and uh and yes, we've come. We've come a long way, so kubernetes was created and was donated to the cloud native computing foundation cncf right at the beginning, there was only one it was great and, uh and now you know, the ecosystem has exploded.

A

uh There are lots of lots of things, lots of software lots of companies that are part of cncf and I'm not showing the landscape to to criticize it. I'm actually extremely happy to see this because in six years an entire community has been has been created. Additional software have been created and it's been really really. uh You know really interesting and enjoyable and over those six years you know, I think, there's been three main narratives that have fueled this. uh This development of this ecosystem, uh one big narrative, has been containers versus vms right.

A

We were busy doing vm orchestration, we were busy doing openstack cloud stack deployment and there's been this switch from openstack to kubernetes. We started dealing with containers as application package and definitely that's been a huge narrative.

A

The other narrative has been uh you know, saying hey you know we, we shouldn't focus on under undifferentiating code right, so we should only work on code that brings value to the business and we should delegate boring things. You know boring quotes right, uh but if it's not bringing direct value, it doesn't have direct, almost ip intellectual property. We shouldn't, you know, really focus on it and the third narrative has been hey. You know what, if we don't focus on undifferentiated code, we shouldn't focus on undifferentiated infrastructure as well right.

A

So you know what I'm not here to manage a community's cluster, I'm not here to manage a kafka cluster. Somebody somebody else should do it for me right, so we've had those three narratives that have helped uh craft this, this new ecosystem right. So what has happened? You know because of those narratives. Now we live in this multi-cloud environment uh and I'm not saying multi-cloud for marketing reasons and so on. It's just yeah. It's just multi, it's very heterogeneous.

A

So we have on-premises stuff, we've gone away from openstack from basic vm infrastructure, and now we have container orchestrators based on kubernetes. We have openshift, we have vmware tonzu. We have rancher all of that on-premises, uh even though they can talk to the cloud but anyway, so we have that on-premises.

A

If we don't want to do this on-premises stuff, then we use a generic cloud like aws, google, you know azure a more regional cloud, like my buddies in switzerland exoscale right and we can manage our communities clusters on those generic clouds, but we also have very specialized dedicated clouds. You want to you want somebody to manage your elastic search cluster. You go to elastic. You want somebody to manage your kafka cluster go to conference.

A

You want to store your metrics somewhere datadog salesforce customers right, so we have very dedicated clouds, sas offerings that have emerged, and all of this makes it a very multi-cloud environment right, and there are very good reasons for this uh again back to the indifference and differentiating uh quotes. uh You know bits right. uh We want to run, you know critical pieces on premises. We want to keep that close to ourselves, but the undifferentiating uh components. We want to delegate that right, so we run on-premises stuff. uh You know that are critical.

A

If we want we delegate infrastructure management to the cloud, we use a managed service uh and then we have those dedicated offerings, because you know what who who best to manage my kafka cluster than conference right? Well, you know nobody so might as well might as well use them right. So they're very good reasons for this multi-cloud environment. It's not you know it's not marketing. It's not it's not nothing right!

A

So multi-cloud! You know almost. Naturally it happened with those narratives. You know pushing us and and now we you know, I like to do a flashback to what's a cloud. What's a cloud you know: if we go back to 2005 2006 definition from nist, uh you know, and they said well, three five, but let's, let's you know just focus on three characteristics: it's on demand measured service. So you know exactly there's metering. You know exactly how much you're using and then elasticity right.

A

You need more, you get more, you need less, you get less all right, so those were the three, maybe three of the five, the other ones. You know network access, which is almost a given resource, pooling you know, kind of multi-tenancy stuff, but on demand metering, elasticity, three big characteristics of the of the cloud right.

A

uh You know, that's what we had that at the beginning and even then people you know were of course arguing about the cloud and you know well, there's no cloud. It's just somebody else's computer, oh yeah, you're, right! It's somebody else, managing those those servers. First time, I'm going to say, servers uh doing a better job at it than than you are right, but it gives you on demand, capability, elasticity and metering right.

A

So that was the the cloud and now when we look at serverless, you know I like to draw this this parallel right. So let's, let's remember the definition of cloud and now, let's look at serverless, everybody is going to argue that the poster child of serverless these days is aws lambda and when you look at the features of aws lambda, you find build custom, backend services. Well, that's where you you build your api server, bring your own code right, bring your bring your own workload fault torrents!

A

You know built in from the cloud completely automated infrastructure right. You know fully automated infrastructure, you don't see where it's running and it's managed for you so manage service, basically automatic scaling right. So you need more, you get more, you need less. You know it runs on less and then only pay for what you use. That's metering right. So what do you see here?

A

Well, you see on demand, you see metering and you see, uh what's the last one elasticity right, so the features of lambda looks a lot like you know the core definition of cloud computing from you know more than 10 years ago right, I I find that fascinating and now, when you try to, you, know, give a definition to several as well. The internet is, you know, coming back to help you same way that they were saying. Well, there's no cloud, it's just somebody else is you know running your computer.

A

Well, there is no serverless, of course, they're servers, but it's just somebody else's. You know fully managed infrastructure and- and you pay for what you use. So it's a cloud right so anyway, and that's what that's what we're seeing right. So we have this. You know new multi-cloud environment right and when you look at the characteristics of this multi-cloud environment, it's from the beginning on demand elastic, you know and then metering, and it turns out that suddenly everything is looking more and more serverless.

A

The cloud providers are saying: well, it's serverless yeah, it's serverless for you, if you're using it, but it's not serverless for them. So I love this picture from a medium post from pablo l'oreal. You know giving reference where it's due and if you look you know lambda is you know serverless for compute, but then there is api gateway, which is a serverless component. S3 suddenly is becoming serverless storage, uh amazon, dynamo, dynamodb or even there is aurora serverless it's becoming serverless cognito is used in serverless applications right.

A

So when you look at all the cloud offerings of the main generic clouds, you realize that more and more they are branding those offerings as serverless right. So traditional cloud is also becoming serverless. Okay,.

A

And, of course it's as it should be, that's the real definition of cloud on demand, elastic and metering. You pay for what you use. So, of course you know the clouds are serverless for you right, they're doing the job for you, the undifferentiated.

A

You know management of the infrastructure that you don't want to do, they're doing it, for you right hope that makes sense hope that makes sense. So, let's, let's keep going and try to have you know fun with it. So now the question comes up. What happens when you don't manage the infrastructure?

A

You delegate the specialized focus you delegate to specialized cloud. Sorry, I'm trying to read the slides, but you delegate to specialized clouds, and you focus on differentiating business logic right. So you delegate to uh to specialize clouds like datadog to store your metrics. You don't want to manage the infra, so you're using gke right and you concentrate just on your business logic. What happens right? Well, you go service full, which is really a better term than serverless all right. You go service full.

A

You have services everywhere right because you just traded managing servers with managing services, and here I like to call patrick debois, who was one of the you know, creators of the the devops uh movement- and he said you know as far back as you know, february 2017 in gent, belgium, config management camp. He said: well, you don't manage servers, you just use services, so we shouldn't say server less, but we're going service full right and that's really good and that's really what we're trying to do from the beginning.

A

As people developing and deploying application, you know developing the apps and operating the apps. That's really what we're trying to do we're trying to be service full all right.

A

So my my co-founder marking called published this post recently on devops to dev apps you can you can find it in the in the new stack and really you know, I'm also mentioning it because patrick has has created devops, but you know 10 years ago almost you know we were all facing the the traditional old world of monolithic application and siloed organization, dev the ops, and then we tried to create best practices better. You know engineering practices and that's where the devops movement emerged.

A

The main foundation of all of this was trying to go faster right and, as you try to go faster, you want to delegate you want the undifferentiated bits. What doesn't really bring value to the business? You want somebody else to do it, somebody whose business it is to do it and so that you can concentrate on the stuff that your business really does and offers right. So, ultimately, you know what we're saying at trigger mesh is that you move to dev apps right, you're, building the app you're deploying the apps, but you don't really care.

A

You know about the infrastructure right, so you know you're more of a devops uh person and it's devaps practice. That's uh really service, full okay, so your multi-cloud environment could be as everything on a single generic cloud could be. Multiple generic clouds, you know could be that uh you have on-premises stuff that are very critical. You know for security auditing reasons, and then maybe you still use a dedicated cloud like datadog to store your store, your metrics right. There are different.

A

You know things that could happen here in your environment as you go service full and you delegate hope that makes sense. So what's the challenge, the challenge is that now you need to bridge all those things right. You need to bridge from on-prem to dedicated cloud. You need to bring you need to bridge from dedicated to you know. uh You know, eks, you need to bridge salesforce from mks right manage kafka on uh on aws right. That's the big challenge! You need to bridge those services.

A

So you know this is not a you know a pitch uh talk, but definitely that's what we do at trigger mesh. That's our vision! You know! That's why I'm here talking to you about this: uh we're building bridges, right, we're building bridges, to link event, sources to event, targets or even sinks, and in the middle we have uh those brokers right. So that's what we do uh trigger mesh. We build bridges between services that can exist on-prem in dedicated cloud or generic cloud. So how do we do this? Well, you need some glue right.

A

A lot of what we do is gluing stuff together right, so you need bunch of glue. You need some bricks right. You need services that need to be stitched together uh and doing it. You need to avoid making spaghetti.

A

You know, add a chat, maybe a year and a half ago with joe bidder, one of the founders of trigger mesh offer no kubernetes. Sorry, and he said yeah, that's great sebastian, but you need to make sure you're not making spaghetti yeah. That's right! You want to avoid making spaghetti, even though spaghetti is very good right.

A

So how do you? How do you do this? How do you build those bridges? uh Well, you know you're going to use a lot of events right all these systems that are disconnected- and sometimes you know man- I mean often managed by different people. They have different organizational boundaries. They all emit events right. So the events is really. You know the glue or the substrate between all those services. Right and cncf helps you with the cloud event specification all right, so you have those events flowing and then everything needs an api.

A

It's as old as the cloud or even you know before that uh we need an api so that we can program application, programming interface. We need to program so that we can automate things. So we have events and then all those services, of course they have an api all right and then, of course we need services right. So you have services everywhere and they're elastic. You can use them on demand and you pay per use characteristic of a cloud service right.

A

So that's what you need to you know build those service, full applications, so the api right. What's the the api? Well communities to the rescue crd custom resource definitions?

A

If you need to extend the communities api, you define your crds, you have a declarative api. You write your reconciliation loops in your controllers. Suddenly you can manage all of that with the github's mindset. The same githubs mindset that you have for your other workload right and then everything you do. You fall back on your feet with kubernetes as a foundation right, so we're going service full.

A

We can use the cloud dedicated cloud generate cloud, aws and so on. We can use on-prem. Suddenly we have a common layer. We have this kubernetes built api right, crd, yes, but then the proof is in the pudding. Look. Google has come up with config connector, which is kubernetes api. On top of all the gcp products, amazon has the ack aws controllers for kubernetes and azure as azure service operator.

A

So all the cloud providers are agreeing that uh fronting all their services with a community's uh uh looking api is the way to go so suddenly they expose an api you're on-prem. You have crds.

A

If you could have the same thing for dedicated clouds. You know you're on to something right. uh So that's why we do a trigger match, so those bridges that I mentioned those bridges to link all those services. You know how do you? How do you make them happen? Well, you you build an api. Of course you build a declarative api, that's going to say, hey! I need a bridge between this and that because that's what I'm trying to do right.

A

So we have an object, called kind bridge, and then we have a bunch of objects like salesforce source. We have splunk targets. We have transformation, objects right, so we have all of this represented as crds. We have controllers and with those suddenly you can define those bridges, you can go service full right and you can, you know, get to the real uh promise, not the premise, the promise of the cloud on demand, elastic and pay as you go.

A

So I'm running out of time. I need to be you know mindful, even though I'm recording I could go on forever here. Okay, but you know in our product, of course we have an api. We have a nice looking front end here is just you know, quick snapshot that I put in there. You can define those event, sources that are flowing through the system from google storage from azure.

A

uh You know event hub from aws cognito. You know oracle cloud. If you want oracle database, you know you name it right. All those different services are emitting events, they're, saying hey. I changed right, they're emitting a notification that said hey something changed, and then we take those events.

A

We route them, we transform them and you can go to a destination and once you get to a destination, then suddenly you can go and perform a task right where it gets very interesting in in all this narrative that we're doing and all this ecosystem that has boomed is that even this going service full, which my entire point is that you know what, when you say, serverless, you really mean service full and event driven right. So, as you go towards event, driven application that are multi-cloud, you know.

A

If you go like this and you embrace the you know the landscape, you fall back on your feet because everything can be managed as a currencies. Api object, so that's beautiful. So here's just a snapshot of like a trigger mesh namespace. We have a bunch of controllers running for the different sources, the different destinations.

A

You know our transformation engine or you know, trigger flow controller right. But if you're an operator you're familiar with this, you can manage your event-driven applications that are bridging those services together, and you could also the same way manage gcp offering manage your sqsq manage your dynamodb. You know tables and things like this all the same way.

A

That's the that's the power so in practice. Use cases of course use cases. So what are we seeing out there? Well we're seeing a lot of people that are wanting to go service full right, they're wanting to go service full can be, can be a case of you know: governance with very strong auditing requirements. Right.

A

You know people wanting to say hey. I need to keep track of. What's coming out of my static code analysis. What's coming out of my jenkins? What's coming out of my bitbucket right, I need to get all these events you know, and then I need to act on them. I need to you know, do some processing of of these events and then you know send them back to uh you know a special uh you know: data lake or storage system, and so on, so that I can validate later on all my uh my audits right.

A

So a strong use case we're seeing is devops governance, especially in insurance. You know big financial institution uh other use cases. You know sales force to back end. You know back end back office right back office infrastructure. You need to you need to sync between those two systems, dedicated cloud. You know run by salesforce, where you have all your customers and so on, and then you know keeping keeping your back office in sync and you want to be able to to link link the two okay, and why do you want to use trigger mesh?

A

Because you don't want to manage those undifferentiated code which are you know, salesforce event, source targeting kafka? You don't want to maintain and and.

A

And operate all of this right uh and then the final one, which is you know, just a new one. That's coming up that. You know that we have and not putting much details here, but healthcare is also becoming uh you know very interested in this lots of services involved in healthcare. So you know, google healthcare api to you know manage a lots of uh sensitive patient data, potentially google healthcare api, but you still want to use aws.

A

So you want to be able to send those google healthcare api to any uh aws service right, so the bottom line you know. The conclusion here is that we're talking about serverless and a lot of people are getting hung up. You know where are the servers and so on that they're still servers what you're really trying to do you're trying to build event, driven applications that are service full.

A

They compose a lot of services, on-premises services, dedicated cloud data, dog sales force, and then you know generic uh cloud like aws and google you're trying to link all those services you're going service for a much better term, thanks to patrick and how you do this. You need a spec for events, thank you, cncf uh serverless working group for the cloud event spec, um and then you need apis, and that's where you know kubernetes uh also comes to to the rescue right.

A

So that's it! Thank you so much again sebastian here, you can find me on twitter at sebgoa uh ping me. If you want to you, know, get a deeper dive into trigger mesh uh I'll, be on for the q. A if I manage to upload this talk and uh join the uh the chat thanks for joining and uh see you online.