 Hello everyone, my name is Sebastian Guesgen, I'm the co-founder of TriggerMesh and thanks for coming to my virtual KubeCon North America 2020 talk. The title is Serverless or Service Fool and here I am recording and I hope you're going to have a good time listening to this talk so let's go and let's get the party started. We've come a long way, we've come a long way since Kubernetes was started, you know, June, July 2014. It's been six years, a little bit over six years. So it's been a while and yes, 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 now the ecosystem has exploded, there are lots of things, lots of software, lots of companies that are part of CNCF and I'm not showing the landscape to criticize it. I'm actually extremely happy to see this because in six years an entire community has been created, additional software have been created and it's been really, really interesting and enjoyable. And over those six years, you know, I think there's been three main narratives that have fueled this development of this ecosystem. One big narrative has been containers versus VMs, right? We were busy doing VM orchestration, we were busy doing OpenStack cloud stack deployment and there's been the switch from OpenStack to Kubernetes. We started dealing with containers as an application package and definitely that's been a huge narrative. The other narrative has been, you know, saying, hey, you know, we shouldn't focus on the 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? 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? So you know what, I'm not here to manage a Kubernetes cluster, I'm not here to manage a Kafka cluster, somebody else should do it for me, right? So we've had those three narratives that have helped craft this new ecosystem, right? So what has happened, you know, because of those narratives. Now we live in this multi-cloud environment. 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. 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 Town Zoo, we have Rancher, all of that on-premises. Even though they can talk to the cloud, but anyway. So we have that on-premises. If we don't want to do this on-premises stuff, then we use a generic cloud like AWS, Google, Azure, a more original cloud like my buddies in Switzerland ExoScale, right? And we can manage our Kubernetes clusters on those generic clouds. But we also have very specialized, dedicated clouds. You want somebody to manage your Elasticsearch cluster, you go to Elastic. You want somebody to manage your Kafka cluster, go to Confluent. You want to store your metrics somewhere, Data.org, Salesforce, Customers, right? So we have very dedicated clouds, SaaS offerings that have emerged. And all of this makes it a very multi-cloud environment, right? And there are very good reasons for this. Again, back to the on-differentiating quotes, bits, right? We want to run critical pieces on-premises. We want to keep that close to ourselves. But the on-differentiating components, we want to delegate that, right? So we run on-premises stuff that are critical. If we want, we delegate infrastructure management to the cloud. We use a managed service. And then we have those dedicated offerings because you know what? Who best to manage my Kafka cluster than Confluent, right? Well, nobody. So might as well use them, right? So there are very good reasons for this multi-cloud environment. It's not marketing, it's not nothing, right? So multi-cloud, almost naturally it happened with those narratives pushing us. And now we 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, you know, and they say, well, three, five, but let's just focus on three characteristics. It's on-demand, measured service. So you know exactly, there is metering. You know exactly how much you're using. And then elasticity, right? You need more, you get more. You need less, you get less, right? So those were the three, maybe three of the five, the other ones, you know, network access, which is a given resource pooling, you know, kind of multi-tenancy stuff. But on-demand, metering, elasticity, three big characteristics of the cloud, right? You know, that's what we had at the beginning. And even then people, you know, were of course arguing about the cloud and you know, well, there is no cloud, it's just somebody else's computer. Well, yeah, you're right, it's somebody else managing those servers, first time I'm going to say servers, doing a better job at it than you are, right? But it gives you on-demand capability, elasticity, and metering, right? So that was the cloud. And now when we look at serverless, you know, I like to draw this parallel, right? So 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 built custom backend services. Well, yeah, that's where you build your API server. Bring your own code, right? Bring your own workload, fault tolerance, 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 managed 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? Well, you see on-demand, you see metering, and you see, 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 find that fascinating. And now when you try to, you know, give a definition to serverless, 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. Well, there is no serverless. Well, of course there are servers, but it's just somebody else's, you know, fully managed infrastructure and you pay for what you use. So it's a cloud, right? So anyway, and 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 certainly everything is looking more and more serverless. 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. Amazon DynamoDB or even there is Aurora Serverless, it's becoming serverless. Cognito is used in serverless applications, right? 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? 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, 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 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? You delegate the specialized focus, you delegate to specialized clouds, 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 specialized clouds like DataDoc to store your metrics. You don't want to manage the infrastructure 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, right? You go service full. You have services everywhere, right? Because you just traded managing servers with managing services. And here I like to quote Patrick Desbois, who was one of the, you know, creators of the DevOps movement. And he said, you know, as far back as, you know, February 2017 in Ghent, Belgium, Config Management Camp, he said, well, you don't manage servers. You just use services. So we shouldn't say serverless, but we're going service full, right? And that's really good. And that's really what we are trying to do from the beginning 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, right? So my co-founder, Martin, called, published this post recently on DevOps to Dev Apps. You can find it in the news stack. And really, you know, and I'm also mentioning it because Patrick has created DevOps, but, you know, 10 years ago, almost, you know, we were all facing the traditional old world of monolithic application and siloed organization, the DevOps. And then we try to create best practices, better, you know, engineering practices. And that's where the DevOps movement emerged. 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 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 TriggerMesh is that you move to Dev Apps, right? You're building the app, you're deploying the apps, but you don't really care about the infrastructure, right? So, you know, you're more of a Dev Apps person and it's Dev Apps practice that's really serviceful, okay? So, your multi-cloud environment could be everything on a single generic cloud, could be multiple generic clouds, you know? Could be that 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 Data.org to store your metrics, right? There are different, you know, things that could happen here in your environment as you go serviceful and you delegate. 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, you know, EKS. You need to bridge Salesforce from MKS, right? Manage Kafka on AWS, right? That's the big challenge. You need to bridge those services. So, you know, this is not a pitch talk, but definitely that's what we do at TriggerMesh. That's our vision. You know, that's why I'm here talking to you about this. We're building bridges, right? We're building bridges to link event sources to event targets or event sinks. And in the middle we have those brokers, right? So, that's what we do at TriggerMesh. 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 lot of what we do is gluing stuff together, right? So, you need a bunch of glue. You need some bricks, right? You need services that need to be stitched together. And doing it, you need to avoid making spaghetti, you know? I had a chat maybe a year and a half ago with Joe Bida, one of the founders of TriggerMesh, of 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, you know, even though spaghetti is very good, right? So, how do you do this? How do you build those bridges? Well, you know, you're going to use a lot of events, right? All these systems that are disconnected and sometimes, you know, 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, right? So, you have those events flowing. And then everything needs an API. It's as old as the cloud or even, you know, before that 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, 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 for use characteristic of a cloud service, right? So, that's what you need to, you know, build those serviceful applications. So, the API, right? What's the API? Well, Kubernetes to the rescue CRD custom resource definitions. 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 GitOps mindset, the same GitOps 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 are going serviceful. We can use the cloud, dedicated cloud, generic 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. So, all the cloud providers are agreeing that fronting all their services with a Kubernetes looking API is the right way to go. So, suddenly, they expose an API, your on-prem, you have CRDs. If you could have the same thing for dedicated clouds, you're on to something, right? So, that's what we do at TriggerMation. So, those bridges that I mentioned, those bridges to link all those services, how do you make them happen? Well, 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? So, we have an object called kind bridge and then we have a bunch of objects like Salesforce source. We have Splunk target. 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 get to the real promise, not the premise, the promise of the cloud on demand, elastic, and pay as you go. So, I'm running out of time. I need to be mindful even though I'm recording. I could go on forever here, okay? But in our product, of course, we have an API. We have a nice looking front end. Here's just a quick snapshot that I put in there. You can define those event sources that are flowing through the system from Google Storage, from Azure, 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, 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 all this narrative that we're doing, in 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, 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 Kubernetes 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, you know, our transformation engine, our, 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. 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. It can be a case of, you know, governance with very strong auditing requirements, right? 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 these events and then, you know, send them back to, you know, a special, you know, data lake or storage system and so on so that I can validate later on all my audits, right? So a strong use case we're seeing is DevOps governance, especially in insurance, you know, big financial institution. Other use cases, you know, Salesforce to backend, you know, backend back office, right? Back office infrastructure. 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 your back office in sync and you want to be able to link the two, okay? And why do you want to use TriggerMesh 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 operate all of this, right? 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, you know, very interested in this, lots of services involved in healthcare. So, you know, Google Healthcare API to, you know, manage lots of sensitive patient data potentially Google Healthcare API, but you still want to use AWS. So, you want to be able to send those Google Healthcare API to any 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. They're still servers. What you're really trying to do, you're trying to build event-driven applications that are serviceful. They compose a lot of services, on-premises services, dedicated cloud, data doc, Salesforce, and then, you know, generic cloud like AWS and Google. You're trying to link all those services, you're going serviceful, a much better term, thanks to Patrick. And how you do this, you need a spec for events, thank you CNCF serverless working group for the cloud event spec. And then you need APIs, and that's where, you know, Kubernetes also comes to the rescue, right? So, that's it. Thank you so much. Again, Sebastian here, you can find me on Twitter at Sebgoa. Ping me if you want to, you know, get a deeper dive into TriggerMesh. I'll be on for the Q&A if I manage to upload this talk and join the chat. Thanks for joining and I'll see you online.