A Series of Fortunate CloudEvents - Ian Coffey, Salesforce¶

Playlists: KubeCon + CloudNativeCon North America 2019 (San Diego)

Live demo showing how CloudEvents and Knative Eventing interact.

Topics: cloudevents, knative eventing, serverless, live demo

Transcript¶

▶ 0:00 hello everybody how's it going how's coupe conde to make I want to hear more because it sounds good job awesome great i'm priyanka sharma and i'm your track host today i am director of technical evangelism at gitlab and also a member of the governing board of the cloud native computing Foundation which is the CN CF who put together all of this event I'm also a member of the program committee and CIC D track was one of was the one that I was evaluating proposals for and something that on the committee we all feel is that serverless is just

▶ 0:42 growing like crazy in my conversations with end-users I've definitely seen large enterprises that you know some would consider very traditional are already saying for a serval s first engineering org which is super cool I think it's the cloud providers have so much cost savings with serverless that they pass them on and incentivize the end-users to go that route as a you know as the first first step first thought step that you think of so that's really interesting because of all this momentum there's a lot of open source projects coming around and key native and cloud events are two such two such initiatives so this particular talk is very interesting for me because there'll be a

▶ 1:25 live demo and we'll see how cloud events and cloud near key native eventing interacts which I think will clarify a lot of confusions I have and hopefully will be illuminating for you as well and this talk is by Ian Coffey who is in the engineering org in Salesforce so Ian please take it away oh sorry one quick thing don't forget to rate this session on scat after we're done it's really helpful for the program committee as we plan the next year it's if we really before it would love it if you could do that so now Ian please take it away can you hear me I think my mic there we go hello everybody I am Ian I'm super excited to talk to you about this topic super excited that so many people

▶ 2:09 are excited to listen and participate in this I'm also excited that this room has magical properties you can see that there is a maximum occupancy over like 330 but above this door if we're dancing it goes to 650 so that's pretty dope so if we get in trouble we got a back-up plan just a little bit about myself my name is Ian as was mentioned I live in upstate New York and I cook in a town called Troy I work at Salesforce and I hack on a platform called Heroku which I think in this crowd we're probably three pretty well-known twelve factor and the like started my journey as a Linux systems administrator and I think that's relevant we'll come back to that in a little bit but I'm sure there's more than a few people here that followed the

▶ 2:51 same path I think we're getting a little bit of feedback but we'll press on and lately a lot of my time in the open source world has been sent concentrating on Tecton and Tecton triggers and things like that that's kind of how I got interested into cloud events was introduced to these concepts is like trying to make all that work like how do you shuttle events from here to here to get into detective pipeline so and also just thanks thanks for checking this out I wanted to take a second to have like a little bit of a meta discussion about like why this format why are we sitting here why are we spending opportunity cost together in this way and I think I've just noticed in my career year-over-year I just tend to spend more

▶ 3:34 time I guess developing what you'd consider learning materials maybe other people feel the same way that you know they can take many forms maybe like getting started guides lightning talks brown-bag demos all those sorts of things informal learning materials one-on-one mentoring sort of situations and it comes up to me a lot like how do you how do you best spend that time how how can we best make use of the time whether it's synchronous like this or learning materials that are for like the open source community that you consume on your own time it's still the same like how do we spend the 30 minutes 45 minutes or whatever is invested in it the best way and how to remove technical barriers for people to actually learn to you this some of the tools that we have available

▶ 4:18 to us now because they're not super useful if nobody's using them interesting story I think that kind of ties into this is I noticed for a long time the K native eventing project had a a really cool readme called writing your own event source and it was two parts the first part you would set up a CRT you would like bootstrap your environment you would bring up a cluster you would do a whole bunch of stuff and then part two didn't exist so I mean it's cool to have this technology but it's cooler when we can all use it I tend to think that like slide based demos are very difficult for relaying highly tactical information like fostering aha moments or like lightning bolt moments or like you know you just

▶ 5:01 get it I don't get that a lot from slide based demos conversely workshops great like really great synchronous workshops everybody's working together everybody's helping each other to achieve some goal but they don't scale right you can't do this many people would have synchronous setting and also it's really hard it's hard to prepare for workshops it takes a lot of effort maybe teaching assistants you need a whole bunch of materials prep so it's it's heavy it reminds me of some experiences that I've had throughout my life that also fostered aha moments are like lightning bolt moments and and one of them one of the clearest in my memory was when I was a child my neighbor and best friends his dad was a mechanic and

▶ 5:46 he had bought him a transparent couldn't internal combustion motor and we were super into cars like we wanted to understand everything about them and you know we tried to understand them just from books and diagrams and things like that looking under the hood of the car when his running but it was this moment where having a motor running this little tiny you know completely functional but see-through motor and a mechanic like explaining oh this is what the cams doing this is what the lifters are doing and it was like 10 seconds and I've always to remembered it and that's when I understood what it meant was and it kind of occurs to me like we can do that we don't need to have like really crazy demos available to just foster that kind of learning environment and I mentioned systems administration earlier I did

▶ 6:30 that because I feel like if you ever worked in a data center supporting Linux servers you have lots of things in moments built in right like you might be working at a console and then you go into the data center like you might see xt3 errors at the console but then you might actually see like the failing drive or you might get data from the IPMI module or the Knicks or something like that there's lots of different sources feeding you data about that running system and I think that just is an underappreciated way to understand technology I really really feel like kubernetes in general just gives us an awesome platform to develop those sorts of learning environment and I'm talking about like self-contained environments no configuration necessary you're not going out and making infrastructure creds if you don't want to you don't

▶ 7:14 need to go to set up a bunch of Secrets it's easy to stand them up it takes low processing power you learn what you need to learn and then they are easily deletable and we really have a great opportunity to kind of lean on that and not just build cool features but kind of describe those features and get people inspired and get people interested in those technology and that's kind of what we're doing today we're going to take those ideas and we're going to try and build a cloud event and Kay native based learning environment that's self-contained is very low overhead requires no configuration and you stand it up there's some structured learning material and then you delete it when you're done and I feel like if we can do

▶ 7:59 that for this we can do that for most or all of these projects and provide like a low barrier for folks to get integrated with the projects they're contributing building tools with them stuff like that but why include cloud events at all I will completely admit that this entire demo could have been built exactly the same way without ever using cloud events it would have taken a lot longer but entirely possible and I think the best way to describe why you know the other reason you include cloud events is because the name of the talk but connecting services is art if you can picture a few scenarios scenario one would be like a really easy scenario you have team a and

▶ 8:44 you have team B and team a is going to develop a service that's going to admit an event and team B needs to consume it where do you start what are you gonna do what are you wearing even start having that conversation between the two teams about how you're going to commit the event how you're going to receive the event with the format the transport how are you serializing it you know and that's just if you're dealing with basic HTTP if you're dealing with a whole bunch of other type of transports you can get really complicated and then you can take a step further back from that and like what if it's not two teams working synchronously what if one service already exists and was built three years ago that becomes a much harder proposition and then you can take a step back forever there from that and what if you have some crazy scenario

▶ 9:28 where you have a cluster in an academic research facility and some group has been given license to use that resource so they want to admit an event and they want to have it consumed by that facility like how do you even start that conversation there's no standardization it's completely Wild West it's all about interoperability it's a hard word to say but it's so important to start thinking about now that there was events flying everywhere later we need to have some way to start in many situations describing data in common formats and at the end of the day you get a lot of things out of it but the number one thing from my perspective that you get from this common metadata on events is routing options you can use this

▶ 10:13 completely outside your apps to make intelligent decisions about who wants what event where and we can develop a pattern where services can subscribe themselves to the events that they need to consume to do their job and in general I just I really do see quite a lot of questions given the fact that thought events is a very small little project I think in the grand scheme of things more of a spec just a disproportionate amount of questions about it and I think that's because like in a vacuum it doesn't do anything you know there's no like Oh get started suspect it's kind of like I was thinking of parallels and one would be if you notice there's very helpful people outside this door that have been asking me sign but in a vacuum nothing's gonna

▶ 10:57 happen there you need an actor to walk up and ask a question we need to utilize it so we can just take a minute here and talk about what a cloud event actually is there's a 90 minute session tomorrow I believe that's gonna do a really deep dive on cloud events current Future past and a whole bunch of other things so this that's not really the goal of this we're gonna try and actually focus on just the parts that we need for this demo to keep our focus on that and in that capacity cloud events are just a spec that adds metadata to has a common format of metadata so that we have things that we can rely on to make intelligent decisions for events and once we have that metadata established sane routing can be having you know we can make good

▶ 11:42 decisions and we can remove a lot of a pelagic code at the same time because one pattern I see in developing and which I will completely be honest drives me crazy is services that ingest events and then have more or less a huge case which statement that says like you know if this event has this little hint like maybe it has a header here or it's in this little data format you try and guess like what the event is and then you cast you marshal it based off of that and it's all in this big case which statement it's ugly and we don't have to do that none of that stuff needs to exist we can get rid of that in its entirety and we'll show that in a minute and I think another thing that we should mention is that cloud events like a

▶ 12:27 really cool name it sounds like a really massive thing but at the end of the day the framework isn't really going to touch your logic or your business logic or how you're consuming these these events and what you're doing with them it's gonna serialize them you know you're gonna transport them somewhere but it's not going to make you rewrite all over your services if you chose to go this path you'd have to modify the front-end a little bit but the business logic no not so much the first for bold items here of the spec are required and the rest are not for cloud events the spec version 1.0 was released recently I think about a month ago which is really awesome the

▶ 13:09 event type is a very important field cloud events are a very low-level concept so you can kind of adapt these how you need to but I tend to think of the cloud events type as a namespace at least that's how it plays out when I write a system using cloud events and it feels like the right solution it generally ends up that case the source is pretty self-explanatory it's good to know in a standard way where the event came from and every event gets a unique ID there's some other things here as the right you can see there's an extensions which is very very useful your app probably has like necessary fields and things that you need to route on that are very specific to your event types

▶ 13:54 and having extensions available to define that is really clutch and then subject is a newer addition to the spec I believe but it's also something that is really really useful in our demo we're gonna use subject to kind of denote where the events going and who should be consuming it but again these can all be adapted to the workload that you have going to try and breeze through the transports funny story was like my first idea for this demo was to build a demo that made use of all the event sources and if you can picture how crazy that would be really happy that didn't happen for this demo we're gonna stick with HTTP but there is just a world of advantage that there are people thinking

▶ 14:37 about additional transports and that you can make use of these out-of-the-box just in the name of interoperability you know how it's serialized what the wire protocol is these are really important things if you want things to be there are some difficult parts and I don't know if these are really classifies difficult parts again the speck is low level it doesn't really seem to make an attempt at solving these problems but event ordering is something that comes up a lot when I talk about this like how do I get things in a specific order you're going to have to figure that out yourself unfortunately replaying events like you need events from a 20 to 100 that's a really common thing to do right but that's not something that you're going to get out of the box you're going to have to write some code there and by getting new sources that's not really a negative

▶ 15:22 it's just kind of reality is its reality if you have this service that omits events and you want to consume it in your cluster in this fashion it's probably not going to be emitted as a cloud event from where it's coming from you're probably going to have to do some adapting and that's reality that's just life but it is something that you have to think about when you're doing this how are they avenging up in a cloud event format in the first place and there are many SDKs available and they're wonderful wonderful to work with and a wonderful advantage to be able to say like we said earlier you have a team a team B okay but what if team a's go and team b's java having like that commonality to say we're speaking on the same terms we're using the same verbs

▶ 16:07 and words here to describe our event format across these different languages can be just a really big time-saver who wants to reinvent things over and over again i mean when we start new businesses do we start writing new kernels from scratch that we just use linux because what value is there to reinventing this stuff I don't know if there's a lot of value in reinventing a lot of the things in cloud events in some circumstances so it's nice that we can just say okay for most of the languages that we have we have a baseline of support that we know that we can use so we can sum up and at the end of the day cloud eventing just gives you some base metadata that you attach to events that you can use to do some intelligent

▶ 16:50 things with that message with that event based on what it is based on when it declares itself to be not what you guessed it is not what you inferred by like checking certain parts of the data envelope the languages SDE sdk is just really really nice to have when most companies are not just writing in one language you know it's great to have that just out of the way that here are the languages that we can support and here's the libraries and let's get going let's start writing code from there Kay native eventing we're gonna talk about it's going to pick up the ball because like I said cloud events in isolation don't really do anything so we need something to use them with and we're gonna use it with Kay native eventing and we're gonna use it to route services based on the data in the event

▶ 17:34 and then at the last we're gonna rip all that awful out routing code out of the apps all those case switch statements and all of that you know event detection and all detecting different fields we don't need to do it we don't have to in fact we can just slim down apps a lot and I this is probably the number one reason why I'm standing here and why I use code offenses that standing-up services just in this particular capacity is pretty quick and easy what kind of use cases do fit this pattern we just talked about I think we've talked about the ICD this cube con more than I could have ever dreamed it's just like seems to be like white-hot but like what about a simpler process what about Khurana based like let's say you you

▶ 18:17 have a kubernetes cron every day at noon to make you a sandwich like you're hungry at noon you need a sandwich so you need to emit an event to your sandwich robot and you know to be able to do that the sandwich robot doesn't need to care about all these other things it just needs to care like I just got an event I know what I need to do and maybe maybe it's a turkey sandwich so you can set your subject to turkey so the turkey sandwich robot is always going to get your message and it doesn't need to care about everything that came before it it just needs to know I need to make a turkey sandwich and bring a tikki in and eventing is the other half of this project here going to really try and drill down on these three concepts it's a big concept it's a big project but

▶ 19:02 broker's triggers and container sources are what we're going to experiment with when I try and breeze through this because going pretty slow but brokers are a newish project I think oh five was really established maybe within the last six months but brokers are really cool because they ask to act as a black box as an event mesh between where your events are being ingested and where they end up and we'll see that a little bit later at the end of the day it really just feels like cheap and easy multiplexing so you receive an event here and n number of things care about it and the first half doesn't have to know about the second half you know you subscribe to the things you're interested in you're not just trying to say I know this thing needs it the apps ending it shouldn't care it's just a

▶ 19:42 minute event just to give a quick detail on the broker details what brokers consisted of mainly there's two pods and two channels these are actually should be reversed the ingress logically would come first and the ingress pod is just going to actually accept events place it on the ingress Channel after doing some inspection the filter pod is going to check that or pick those up it's going to say okay I have all of these K native triggers defined and these ones match this filter so they're all getting a message at that point it's going to be put on the triggered Channel and all of those services are listening on that channel and they're going to receive a copy of the message K native triggers as

▶ 20:25 I just mentioned is the other part of this process that's very important and triggers acts as the way that we define the subscriptions in other word that's a way for an app to say I'm interested in this this this is these are events that I need to get and when you define it a trigger you can either just define a trigger which ingest all events from a broker or more likely you're going to filter you're going to filter based on what's necessary for that service to be interested in it like it has to be a sandwhich event and it has to be of type turkey here's an event or soothe me an example trigger filter and you can see in this one there's no broker defined so this will end up on the broker that's the default and under the filter in the spec

▶ 21:09 we're looking for all events that have a subject of Dave defined and now this extension has value and if it matches that the filter pod that we just mentioned before is going to put it on the trigger Channel it's going to end up at radical service 2000 and from there you're off and running your event can then be processed so we're going to jump into demos and this demo is I didn't want to do something that represented a system that existed in real life I felt like you would give a better cross-section to what's happening to just dream up something entirely different and more fun so we're gonna build a tiny distributed system and it has little AI actors these actors are

▶ 21:53 just pods and they're gonna have a conversation it's ridiculous and I have no idea what they're going to say but that's the point and but the interesting or the most important thing to pay attention to is that these actors are not outputting what they say like I am they're outputting what they hear so they're not it would be very easy for a pod to just boot up and say like okay format dot print line say something and we could see those lines no this is only saying we're speaking in cloud events and when I receive something I'm going to make a note of the messages I received so that everything we're seeing here are successful round trips of events there's many parallels between and the

▶ 22:37 reason I use the conversation is because I feel like there's a lot of like direct correlation between the system we're building events and conversations and here's something like cloud events are indicative of the messages we're sending or like the sentences or paragraphs or ideas the broker is going to represent the conversation or maybe you could say the room like this room triggers yeah we don't really have a concept for this in conversations but it's it signifies interest in a topic and pods are actors and the container source is the act of speaking it's open your mouth and letting words come out is what the container source is going to represent so we're gonna start the

▶ 23:17 system now and it's tiny and what we're doing right now is we're just running an up script and that the up script is doing I mentioned earlier self-contained environments things that are very simple to get involved in to get started with that's what we're doing right here from then up we're gonna create an entire kubernetes cluster with kind which is awesome development tool that I would strongly recommend if you do a lot of local development kind is just awesome to use and we're gonna create an entire kubernetes cluster with that following that we're gonna use glue which is another really awesome project to initialize Kay native on our cluster and then finally we're going to install three resources that are just gonna set the stage for our conversation so let's

▶ 24:01 check out one of those which I obviously cannot remember the name of and this is a broker that's all we're defining here and in this broker we're saying the name is conversation broker which is not a great name for a broker because brokers prepend brokers so this is conversation broker broker and what we're saying is this is an in memory channel and it's living in the name space work conversation where everything will live and when you're done with it just delete the name space and you're done quickly we should probably check out what's going on kale is another great tool kale will just aggregate all the pods from your namespace so if you're like troubleshooting something you don't want

▶ 24:45 to like waste time especially if it's urgent figuring out what's going on as you can see there's nothing going on our namespace right now traffic is very low but we can fix that we're gonna add some actors and we should add an actor named Tracy we'll add an actor named Fred I think Jane wants to join the conversation and how about Peter and so this is gonna take a few minutes internal DNS is gonna take like a minute or two to settle so let's take a minute and we'll check out a diagram about what's happening right now and what's happening right now if you start at the top left and go counterclockwise we

▶ 25:27 created the pod named Tracy and Tracy booted up and she's sent two containers she said an event or a cloud event via Kay need of a container source you can see in the bottom left this event is of type message comm and coffee conversation message is the event type and in the bottom left we can also see that the subject is to all this message is meant for everyone in the conversation and the source was Tracy Tracy spoke this message and on the right you can see Fred exists and Fred is subscribed to all messages Fred cares to get all these messages we didn't have any other config we can create as many actors if you want we can name of anything they want they're just gonna discuss amongst themselves and there's no configuration file anywhere we're

▶ 26:10 just signifying the relationship between the sender and the recipients via their interest in that particular message type so let's take a minute here and jump back over to our demo and check out what it looks like first let's see how that traffic's looking now that looks much more like a distributed system right what's going on here but let's drill into the conversation itself and you can see they're having this really strange conversation amongst themselves and it's ridiculous they they say things in response to each other and you might notice that there's duplicates but there's not actually duplicates because if you think about it they're outputting what they're hearing and right now if we had the same

▶ 26:53 here I'm speaking to everyone here and if you all were putting what you were hearing to standard out there'd be a whole lot of duplication and that's all you're seeing here is these are messages to everyone and when is to everyone everyone notes that that's what Jane said but we can drill even further I mentioned earlier one really pivotal moment for me with learning how internal combustion motors work was seeing inside like seeing how it worked and we can do the same thing here this is the wire protocol of what's going on lots and lots of cloud events flowing around the system and this is what's happening this is all that's happening we're just sending sending cloud events around between these actors in this little tiny distributed system so that they can have

▶ 27:37 this conversation and let's capture one of these here's a good one you notice here the spec versions 0.03 it's actually being sent as 1.0 I opened a below request to fix this but I think that the broker downgrades all cloud offense 2.0 3 right now so just something to note the type of course is conversation message and this message was from Peter to Fred and he said that's just rude and that's pretty much what it looks like on the wire but what is happening in our namespace like what what is really the the resource situation here and as you can see there's a lot going on in here

▶ 28:21 all of these container sources at the bottom here represent one message that someone's saying and after they say if these actors are very nice they clean up after themselves they do automatic garbage collection but they are constantly just sending these container source messages and you can see above here the reason they're being received is that we have these subscriptions and these are all the combinations of subscriptions that we care about so Peter cares about all messages Traci wants messages just to Tracy things like that so we're defining those right here but I think we can take this little bit further what if we wanted to send a new event type it's a really common thing right you have a service now it needs to

▶ 29:06 invent in just a different kind of service type or event type like how would we do that well let's try that with a new event type called distracted we're gonna distract our actors one little secret about them is they're very easily distracted it's just like normal people so we're going to set up the ability for them to ingest this new event type and then we're gonna send them one let's check out what that looks like though in this file you can see a whole new set of triggers this bottom one here is noting that Peter should now become interested in the distracted event type and any messages sent to all that have the type of distracted once we

▶ 29:48 apply this file Peter is going to become interested in those he's going to become he's going to signal to the system hey I want to receive these messages now so let's just apply these real quick and well now when we send this new event type instead of it just going into the broker and hanging out forever and timing out and being dropped now it will end up being delivered and we're going to deliver our new event type with magic wand an all magic wand is a fancy little script which acts as a template for sending yet another container source event type so what we're doing is creating a container source the container stores boots and it's going to send a cloud event wherever we tell it

▶ 30:32 to in this case it's going to set the type that distracted and it's gonna send it to everyone so let's let's try it out and right away we're gonna want to see how this affected them right we said they're easily distracted what does that look like so let's do that so we've sent it it's gonna be sent to all since we didn't specify anyone and you can see the hole they got interested in something so now every single one of those actors has now received this distractive event so you can see that their behavior has changed entirely they don't care about anything else anymore and the only reason they received this event is because of that triggers file we just created if we hadn't none of them were received this we wouldn't have

▶ 31:14 seen any change in their behavior well what else can we do like what what other sorts of things can you do with this sort of setup I mean this is one of the things I usually referred to in the past as the dream but it's a really complex pipeline but it's just very powerful and if you start at the top left just starting from a git push we're gonna create an event it doesn't really matter where it's coming from what gets serviced whatever but as long as it can be make it to our K native cluster it can be received by serving the K native eventing adapter will then create a or modify it to become a cloud event the cloud event will end up in our broker

▶ 31:57 moving up the middle line we can have a Tecton trigger like we mentioned eager earlier when we're going to subscribe the trigger to things that it's interested in so the trigger can be completely done it does not need to know anything about the types or the formats of things that's getting we're handing that all upstream and the trigger is going to receive that message and it's going to create a Tecton pipeline and detective pipeline is going to do it's awesome magic testin is awesome and we're going to get the pipeline started to create all of the things on the right go test without building a docker image pushing all of these sorts of things and we really have that round trip nailed down and if we want to upgrade let's say we have another system but we don't have to like replace or modify the other system

▶ 32:41 we just stand it up and we subscribe it to the different message types that we're interested in and we can kind of keep doing this pattern into infinity and that's pretty much the entirety of the talk here I think we have some time for questions I think we have two minutes but I'm not sure if there are any questions any questions I did a great job thank you so much [Applause]