All right. Three out to the hour. Let's get the funds started. 14 people. All right. Let's see. AI skip. Okay. Anything from the community. Anybody want to bring up. All right. STK stuff. We did not have a phone call last week. So I don't think anything to talk about. However. We do have a phone call scheduled for today. I don't know if we have any topics to bring up, but we do have one scheduled if you guys want to join that. Incubator next week. I believe Tuesday. We'll be doing the presentation for incubator status for the project. Still looking for more end users. If you guys want to add anything to the list, otherwise I believe we're ready to go. If you haven't looked at it yet, proposal is here. Have any edits? Just let me know. And I'll try to make them. A coupon. We have the two sessions. We did two big sessions. One for cloud events. One for serverless. One for serverless. And I have the outline of what we're going to talk about there. Feel free to make any edits you want. Ask to your name somewhere around there. If you want to join in. The presentation side of things. I don't believe anybody's done so yet. But we still have time. So be thinking about that. Also. Chris was on last week. We didn't really say anything, but he added this to the agenda. And that's. It looks like you will have a serverless. We'll have a serverless. We'll have a serverless. We'll have a serverless. We'll have a serverless. We'll have a serverless. We'll have a serverless. We'll have a serverless. We'll have a serverless. We'll have a serverless. We'll have a serverless. We'll have a serverless. We'll have a serverless. We'll have a serverless. It looks like you will have a serverless practitioner summit. The same way we did in Barcelona, I believe. Earlier this year. It is planning on being a one day event all day co-located. As you can see on Monday, November 18. The CFP for that is supposed to go out some point this week. I don't know for sure when, but that's the rumor. About this week. I believe they're planning on making it just one long track. So they're not going to have breakouts. So now we'll have a little break out for this CFP. You guys want to submit something. All right. Any other topics you want to bring up before we jump into PRs. All right. Let's get right to it then. Extensions here are the first. Let's talk about this one. Okay, this one I thought might be easy. Klaus is not on. So basically in this one, bit because that implies um yeah this implies a multi-level extension and he thought that was misleading because we don't allow maps or anything like that anymore so we just basically removed this sentence it seemed like a very safe change to me anybody have any questions or concerns about that okay any objections to approving okay excellent thank you all right fix up jason mapping is next um trying to remember evan it's still not on all right let's see what changed in last time since this one is anybody remember what changed i think there might have been i think i think the last set of changes he made in here related to data content and coding being removed i think that was the biggest stuff so here we have this section here and i think the rest of it are just minor little nets like adding boolean i think that's it so i think the biggest bulk of the change is this stuff right in here i'll give you guys a second just to reread that in case you haven't just to read it all right any questions or comments or anybody want to say anything about that scott is there anything you want to mention on here since this was evans good to me okay anybody else want to okay anybody else want to comment question all right any objection to approving it here's my mouse any objection easy peasy cool all right avro um let's see let's get some really good stuff in here all right so someone else want to talk to this one maybe scott or clemens since i know zero about this other than see a lot of changes go flying by so so the um um this is doing effectively the same updates and the reason why we had a discussion about this is that um evan went and made data um binary only um so this this schema that we have here this this this original schema was effectively just driving the avro serializer so it can go and take an arbitrary nested set of records and um and serialize them so it wasn't really meant to represent the the cloud event schema but really just drive the serializer and so um and so uh evan updated that to include the new types that we have um and then the discussion was whether data should be binary only um or should still be be able to contain structured data and um so meanwhile he's made that amendment that data can now just like with jason contain structured information and um so with that we're now even so this is good i i mean i haven't tested so since this is this is quasi code that um the avro serializer needs to work with um i i will trust that that has been tested um but this this looks in in from a theoretical perspective this looks right okay that that's the biggest thing i want to make sure that because i know you have some concerns about the previous version of this and i want to make sure that those your concerns were addressed okay um let me just see i think most of this stuff is minor is this an example no okay yeah so here's the actual schema i think this is a duplicate of what he had in this spec and just to be clear this text in here looks right to everybody yeah okay anybody else have any questions comments concerns oh gem your hands up yeah just a quick one maybe clements um in the jason binding you you'd sort of it or transport you'd extended that to cover explicit you know base 64 versus data um do you think we need to follow the same model here you could embed you could embed either in this structure as well yeah so the special problem with jason is that it can natively represent binary well avro can oh okay all right so so that's true for that's true for mkp um where so in aim so we have this split in mkp as well that's similar to jason but we have that because of the the typical usage usage pattern in mkp typically in mkp you transport pure binary data in in data and then if you have structured information you put that into value so mkp kind of distinguishes between the two for jason we have that split because jason has no way of representing binary data at all so you have to go and put that into some string encoding so we're signaling that here and if you look at that text that we have here that basically says um if it's binary represented as binary and otherwise you know construct a um construct a union which effectively use use the the native data types the way how this turns out is that specifically for avro is that whatever you have in your hands as as data well if that is is binary or if that's structured you basically assign to the to the data property and then have to serialize or deal with it okay so go that um so can the data be another avro object or does it have to be serialized avro object it can be no no it can be so with with the change that we have here it can be um any effectively you you can you can stick any object graph that the that your avro serializer understands you can put that in here and that will be just serialized out as as a data structure that's what that recursive schema does okay cool all right so this would be you know uh and i guess i had some offline chats with scott last week around proto this would be the a model we could replicate into proto structures as well then when we redo proto buff yeah correct that's that's what that's what the protobuf schema should do i don't know how flexible for protobuf is for these sort of recursive quasi-tagged encodings but that's that's what the goal that's what the goal ought to be cool we can use i think there's smoke and mirrors we can use there scott can put me right but yeah okay all right cool thank you dem and thank you comments for answering that any other questions comments okay any objection to approving that cool easy all right next um i wasn't quite sure which one to tackle next since this one may take a while um let's first at least bring up evans pr maybe scott you can talk to this one explain why he's suggesting that we remove it at least temporarily yeah we've changed the how data works and i think the current the current proto only understands extensions as they were and we've changed a couple of those formats and nobody on our side has bandwidth to fix up the proto definition so rather than rather than lock in a v1 version of proto that we would have to support grudgingly for the rest of time we're we're opting to just delete this and then add it when it's uh when somebody has bandwidth okay um anybody have any questions about that if we can if we don't have bandwidth to fix it that's the right way to do it yeah okay and since and since we since we have a modular structure and effectively all the we can add bindings to both transports and encodings practically at any time i don't think that's that's too terrible we can basically we can add a protobuf and a seabor and whatever encoding as a 1.0 version um basically at any point in the future yep okay anybody else have any oh sorry mark your hands up and we feel that this will not get to 1.0 by not having this anybody want to come on on that does anybody I agree with clients that you know we can we can always add it later as an addendum of you know this is a 1.0 spec for protobuf but I just want to make sure that we're all clear that we can go out with without a protobuf format right does anybody view this view protobuf as a requirement for 1.0 okay not hearing it ship it okay so technically hey oh don't you're right yes yes ship it to don't yeah so technically he opened this up yesterday so for our rules we can't technically approve it however what I'd like to do is suggest this because this is a very easy change it may be controversial to somebody but in relative to approval it's either a very binary yes or no to kind of decision what I'd like to do is this is suggest that we conditionally approve the concept of removing it I'll work with Evan to get the PR fixed up because it's not actually right the way it is correct I'm sorry it's not correct the way it is now for example we didn't update the TOC and stuff for them the main read me and stuff like that but obviously those are minor typographical things what I'd like to do is conditionally approve it now and give people offline until the end of tomorrow to raise an objection and if no one objects by the end of tomorrow that would have been enough of the grace period to then say okay we can go ahead and make it make it happen offline does anybody have any objection to doing that that way we don't have to wait a whole another week just to remove it okay so approve conditionally wait until end of Friday oops okay any objection to that all right cool thank you guys um okay quick question here this issue was opened up by Alan um I don't necessarily want to discuss it right now let's see how time later I just have a question for you guys who actually have looked at this one is this a 1.0 issue is my only question we removed the data content encoding thing correct and then he goes down to here and raises some concerns in particular his stuff about the compression is the one that really got me interested so I took a guess at an answer yeah we we we chose to effectively chose to care about basics the basics before problem in the first place and we have and we have basically punted on the the so we didn't really have we didn't really have a good good source for source of reference for you know compression and all extra features um so we I think we punted on that in in in the discussion we can we can certainly it's it's arguable you can go and put that into the content type effectively you can go and make a parameter on the content type that says this is jason but this is this is compressed or um so so what ellen what ellen is I think really menting is the fact that we don't have that we now gave away a place where you can add arbitrary hints for what further encoding has been done on the data we carry including compression yep but I think that's something that I would punt certainly for 1.0 because I don't think it's strictly necessary because most of the transports do have that feature and that and because we also support binary formats now like avro which actually inherently support compression so it's not clear to me that we that that's a higher order bit and that's something that we can also effectively add as a extension if we wanted to or if that becomes a pressure pressing issue we can go in and I think we can add that fairly easily so okay so just make sure I understand your assertion is that if we decide to add some other property that implied compression or any other kind of encoding we could easily support that because we have a clear path right now for supporting binary data yeah exactly so it ultimately becomes a question of how do you there's a buy so there's binary data that we can clearly support and now the question is how do you describe that binary data and what you know what that binary data is and I think with the content type we already have a weapon to go and very clearly declare what's in there without having to resort to an extra encoding flag okay what other people think does anybody disagree with what Clemens said does anybody else think we this actually is a 1.0 issue we need to resolve nothing okay I'm going to assume silent is is consent um so what I'll do is I'll tag this as I'll tag this as nice to have if we can get it done in 1.0 but it doesn't sound like it's a requirement does that sound fair yes okay any other comments or questions on that one okay um again before we get back to Evans because that might be kind of big this one I just opened yesterday so we can't necessarily merge it I might ask for this one to be merged or put into the other category way until tomorrow but this is strictly syntactyl fixes so it's not actually major I just noticed that when we got rid of structures we had a couple examples that still use structures so I just converted those to beaches straight out integers and per Vlad suggestion instead of making an extension to I made it other value just to make it clear that you can put other basically words in there without dashes or anything like that and then the other thing I did is for a completely unrelated reason I was looking for the text that we had around naming in particular the valid characters so I was looking for this section right here and it was really odd to me that it appeared sort of in the term next to the terminology section so all I did was move it down into the into the content attribute section so I put it in there right before the type system it just seemed like that is a more appropriate spot since we're actually describing the names of the context attributes so I've seen like a good spot to play it the other changes in here was oh there's one of the chains Evan noticed that we had more than one data header so the hashtag data was not clear which one I was going to resolve to so what I ended up doing was make the definition of the word data to be event data and there was another thing I did oh because here's that chain right there event data I then in the in that section itself though I got rid of the nested data tag or data header it seemed like it was kind of pointless having it there because all we had was a small little section afterwards and in terms of what it was actually called we actually have it mentioned right here if someone can come up with a better word than just data for the header there I don't want to put it back in I just couldn't think of one last night so I decided to remove it anyway nothing normative in terms of changes strictly syntactical just moving things around slightly any good okay any thank you Clemens any questions or comments concerns any objections to approving and I'll give people until tomorrow to do a final check before I actually merge it okay thank you cool all right now uh this one okay so refresh everybody's actually Scott I'm gonna force you to talk I'm doing I'm tired of doing all talking you want to refresh everybody's memory about what this issue is about uh booting up hold on okay okay so this is this is talking about how certain certain hops among especially HTTP assume that certain headers are called a certain thing for example tracing and the various types of tracing that you might want to do for just normal HTTP requests the the way the the spec is currently written if a producer adds an extension they have no they don't have the ability for downstream converters to like so like middleware pieces to turn it back into the header that's required for HTTP if it's been translated into a different transport and then back so potentially the worst case you drop them and best case they become CE dash prefixed which doesn't work so yes we have one we have a an extension that's supposed to be followed by all receivers of cloud events but what what do we do in the case of just some random extension like or the next version of the tracing header or if the tracing extension adds a new header we would have to change our specification so we think this is a problem okay uh gem your hands up so I think you know I believe it was Clemens that was touched on this last week I think this is unfortunately an edge case for this example isn't it because it's in a pure CE model extensions will flow yeah without any problem because of the way they get prefixed in the transport bindings it's only distributed tracing where we have a problem because it's really trying to say oh well don't treat this the way you do everything else do it a special case so I agree this could crop up with other specs but I'm not quite sure how you can account for it I don't think we can account for every flavor of what might happen in the future if you start with a cloud event you should be okay yeah stuff will always flow across intermediaries it's only this sort of somewhat I don't want to use the word ad hoc but this sort of by the way please do this thing differently that's tripping us up in this situation okay anybody else want to comment okay I'll jump in then I have a comment so I that last bit that what jem said there I think is the key thing for me it's it's the fact that we allow extensions to not follow the normal rules is actually the problem and I'd like to look at it I'd like to tackle that problem itself because I think if we can make extensions follow the rules like everybody else then this problem goes away because it's very clear where the cloud event properties live right they all either in the jason body or there's a chief headers and their prefix with CE and so what I'd like to do is something this is tackling this problem this way and this was actually talked about on an offline phone call that Evan Scott and Clemens that I had earlier in the week trying to hash through this was to basically say all extensions must be serialized with the CE prefix just like any other attribute from that perspective they're no different whatsoever however they can have what I call a secondary serialization so for example in the trace example you could still use the W3C trace headers as as you know however you want that's fine however they now become sort of secondary bits of information meaning when the receiver gets the cloud event he's only responsible for or required to actually look at the prefixed headers the CE ones if he wants to look at the other ones he's free to pick those up and pass them along as sort of extra other attributes I'm sorry or she they sorry they they're free to pick up those other attributes but they're not quote cloud event attributes they're just extra bits of metadata that happen to pass along and the reason I say that is because technically that other bit of metadata could have been changed somewhere along the process we have no control over that whatsoever and in particular in the tracing stuff as as I've been explained as it's been explained to me the tracing header actually supposed to get modified to actually grow over time to add more tracing IDs in there I believe so you actually can very well in the tracing case get different values there so you actually might actually want the two different bits of information one being what the original sender meant to include as quote cloud event data versus transport level data that might get more munged along the way right and so this allows basically for both cases to happen but in particular for a receiver who has no clue about this extension whatsoever they still have a very clear rule to follow they pick up the CE prefixed ones and that's all they need to worry about anything else can technically be dropped from a cloud event perspective anyway that's my proposal here obviously since I just pasted this last night we couldn't approve it but I'm curious to know what people think about that general direction and gems your hand up is that new yeah so I would I would be behind that statement I guess does this mean that there's guidance for SDK writers in that they should be providing up to the application not just the cloud event itself but also any transport context um that then gives I think Scott a pathway to if he brings in something over HTTP that has w3c tracing attached but is not in the cloud event it's not also tagged with a cloud event prefix that you still have some mechanism to present that information out to the application code I think that'd be really good and because I I do think in general SDK should sort of try to present as much data as they can to receive the application even if it's not part of the cloud event stuff obviously they're usually discretion that the you know the to pick and choose what data they say maybe want to exclude but in general I do think that'd be good guidance yes that's just me Scott your hands up yeah I already exposed a uh transport context because it became very clear that you need this data yeah I think but the so the issue is that when you transition between HTTP to another transport and then back to HTTP you need a lot of smarts in that receive adapter to turn it back into the intended request yeah and for like for the C sharp the the pending C sharp revision for 1.0 I think also it's fairly easy to take the the the context from where you from where the cloud event came and link that into the cloud event object so you can basically you need to have a property that's called context and then that has you know either an HTTP request in it or it has an mqp message in it where you can basically then poke around and get at transport errors so that's probably what it's going to be yeah but Scott I think if I understood what you're saying before you wanted you're hoping for a mechanism that said uh some piece of middleware that maybe isn't the way of cloud events can still know about this unknown extension that doesn't have a CE prefix and still know to sort of carry that along in some way right as as a pseudo cloud event thing and right I'm not sure it's a trace idea if you have HTTP to AMQP and back to HTTP the that second HTTP hop is not going to have that trace header because the unless you explicitly have custom code to hydrate it back out of the AMQP message right but with this proposal that I have here I think he would get serialized back out what would be different though is you'd have the original value as opposed to a potentially modified value because of the previous hops right the value comes but you'd have to understand how to pop that out right like CE dash trace header is meaningless oh I see what you mean yes you are correct so then the yeah this is kind of a situation where cloud events is making a bunch of choices that will be incompatible with all existing systems that use HTTP well but it's so I guess there's two ways to look at that one is if it's an unknown extension unless we try to do some really complicated thing and encode the serialization rules into the message itself that says oh if the next hop is HTTP do this for this header if it's AMQP do this for this header which sounds like it's a really bad idea trying to encode that into the message I don't I don't see how you can solve this for unknown headers by receiver but if this middle where wants to act as almost like a proxy kind of a thing it seems to me it's going to have to know how to deal with these headers of this information irrespective of cloud events right I mean to take this trace header as an example right even if cloud events wasn't in the picture it's trace headers either going to get propagated properly or it's going to get dropped regardless of what we do in our spec so it sounds like it's not necessarily our problem to solve but but that's the case of HTTP to HTTP proxies and we're talking about AMQP to some sort of converter to HTTP and that piece has to be custom right but how would you solve that without cloud events in the picture well it would be custom right that's my point if without cloud events you have the right custom code so with cloud events you still have to write custom code but my custom code is not going to work with your custom code and that's the interrupt problem so so but but if we're talking about the since the tracing problem is one that is important in this context that's something that's really up to the trace context specs to solve and not necessarily for us to solve and then I think one of the where it gets clearer and that's something we also had on that we discussed briefly towards the end of the call that we had is as I think I think when you think about event delivery as push and where the message the event travels along a HTTP route through proxies forward then you clearly have this parallelism between you know the the trace context as it originated in the in the in the sent in the publisher and then how it travels along that route and then shows up in the receiver for the HTTP endpoint that there it's pretty clear but as soon as you have a push pull translation where you push into a queue or you push into effectively a PubSub intermediary where you then go and solicit the message out then the context become completely different because the if you pull the message out which means you do either an HTTP get or delete or you do an aim to P receive the receive gesture then that receive gesture is motivated by something else that you start with a different trace context because your your motivation is that you want to have a message and you trace that and the delivery of that message then is part of that trace context because that's what it was motivated by but the message itself the trace context that it contains is the one from when that message was published so those are completely orthogonal to each other that's not true in Knative we use different transports for persistence so wait so when I when I pull a message out of somewhere no matter what no matter where it's stored so I have an event I store that event in a queue or sort of event somewhere on disk and then now sometime later go and and pick that event up the thing that's being the trace the trace context origin for that operation for the HTTP request is not that of the of the event the trace context for that is me picking up some event but I don't even know which event that will be no no we want to know we want to be able to link the producer to the consumer and all the hops yeah but you can't because at that point because at that point when you are soliciting a request you have a soliciting event you don't know which event you're going to get I can look at the metadata of the event yeah but but but you you also need to have a trace path for before you even got that event right you start the operation of the what starts that context is you saying I'm going to I'm going to issue an HTTP get now or I'm going to issue an HTTP delete now or I'm going to go and issue an HTTP receive operation that's where your context starts for that operation you want to be able to trace that through and see how the delivery how the solicitation of that event and the delivery went but that is orthogonal to the trace context that in the event itself that's the publisher sent you because you can't know that at that point you don't know which message you'll get so different systems it's got the massive question I feel fairly confident that this proposal addresses well no let me try to figure out our way of words to say here I think future proofs us well well I think it makes it clear that for these non-special cases where someone wants their own serialization I think requiring everybody to do CE dash that I think works because you know exactly what header it's going to appear or how it's going to appear and there's no place else to look but not to worry about anything I think it says as Jim said it's these edge cases where there's a bit of data that wants to sort of live someplace else because there's an existing spec that we're trying to adhere to right I guess I don't see how how we can possibly solve that without doing all that encoding rules that I just mentioned to you in every single message for every single transport that may exist out there that a sender may or may not even know about and so for example right if I'm sending a cloud event to race GP and I don't know or care about the amqv transport I think you would require me to put some encoding in there anyway that tells you how to encode this over or amqv but I can't because I don't even know about it Scott yes no maybe I think even in amqv I think there's cases where you want to be able to filter on a key that doesn't have a CE prefix because it's existing infrastructure that knows that things that are labeled as prod go to the prod queue or whatever right but I think with this proposal you can still do that as long as the sender who knows about this attribute knows about the special encoding and he could then serialize it in that secondary form right so now you can't use any of the existing middleware that you have that works just with vanilla amqp why is that so I think the question is whether if that middleware updates the attribute if that update should be carried it should be applied to the cloud event or not that's an excellent question yes yes this this proposal is biasing towards if you have middleware that would update the attributes it does not update the cloud event itself correct well actually be clear I don't say that the middleware can't update the attribute all I say is if they're different when they get at their at their receiving end here's how you deal with it because I'm sorry if you have middleware that only knows about the transport and doesn't know about cloud events then any updates that it does will get discarded on receipt correct and well relative to cloud event processing that is definitely true and the reason I was okay with that I was thinking about this last night is because technically any cloud event attribute that we have whether it's source or any other field right if that data is created based upon other data in the message someplace like so for example let's say source was extracted from the body of the message or some other htp header or something like that right but they put it as cdash so they get that interrupt that we're looking for right if some piece of middleware modifies that other metadata there's no requirement on them to modify the cloud event attribute in fact as you said they may not even know about the cloud event attribute to modify it so it's technically possible that the receiver will have a source attribute that doesn't match that other bit of metadata that it was used to originally create or created from and that's fine because that's what at the way every other cloud event attribute is behaves and now we're making extensions work the exact same way you may say it's a problem but at least it's a consistent problem across everything does that make any sense Evan I think that's a accurate statement of the problem I I think there's a second way to solve it which is to say that any of these encodings are transport specific concerns and you use a transport specific mechanism so you say you know hey when you're encoding htp you need to know how to undo htp and if you don't link in the amqp stuff you don't need to know how amqp gets mapped to to and from cloud events but even in that model if there was some way in the htp message to convert the trace header into a cloud event bit of metadata right if the next hop is amqp but amqp if that middle error doesn't know about the extension it's not going to serialize the trace header as anything but a c e dash so in 498 I suggested adding a header something like cloud events mapping for htp that would tell you what mappings the sender did on attributes that would be something specific to the htp transport right the thing that is bridging between htp and amqp is going to be a cloud events bridge I think I don't think there's a general purpose htp to amqp bridging so given that that bridge needs to know about cloud events anyway it can read that header do the transformation and then it you know has a cloud event and then it does a transformation to whatever amqp's rules are so we so objection there is a generic mechanism for this oh there is okay so we have a there's a spec there's a spec that's in flight to become a standard committee standard which is htp over amqp and that actually has that mode so it has a it has a effectively bridges it allows you to take htp semantics and bridge them over amqp I was unaware of that cool however but even if that's the case I still don't think what you described there Evan works because what if the w3c spec says for htp the trace header is serialized as it is in our document but for amqp it's serialized with the z in front I don't know right some other civilization that information is is not available to anybody unless that middleware happens to understand the tracing from the tracing extension right no I'm suggesting that there would be so on the first htp message there would be a header that said cloud events mapped you know trace trace id to whatever the you know w3c header is the recipient would look at that cloud events mapped and say oh did was there a header named you know wc3 tracing or whatever oh I should trans translate that into a cloud events trace id so for the first hop all of those you know all of those traces line up then when it goes to send with amqp it either knows about the amqp tracing extension at which point it puts it in the right place for amqp or if it doesn't it sends it as a regular cloud events header with you know whatever prefixes there are and you don't get traces for that path along the way but you get the tracing information from the first part okay so you're comfortable with losing the w3c-ness on the second hop well if the middleware doesn't know about the w3c extension I don't see how you would get the tracing this got it like I just don't see if you don't know about that extension how you would apply that right and if the second hop was acap would you expect the the middleware to use that that that special header that you added to to the serialization back out again into the special form not necessarily okay so it's strictly on a read it's on a hop by hop basis so that the recipient can understand what the sender put in there okay so it's just for the reading side not necessarily the writing side got it yeah and the writing side has to tell the next person what they did oh if he had if he does know about some other special serialization yes if he knows some other extension that has a special serialization and as a matter of fact for htp we would probably always send a header that says you know data content type got mapped to the content type header got it okay I'm gonna let someone else speak for a minute anybody else want to comment on this I better understand the problem now so thank you Adam just one thing I when the tracing stuff was originally added was the intention that maybe this is what Clemens was alluding to is this meant to trace the context of the event or all the infrastructure that it flows through in between because it sounds like if somebody publishes an event and it bounces through lots of infrastructure along the way I could end up with a received trace context which has loads of stuff in it that I absolutely no interest in is that true I think it depends on what you're trying to get out of that trace if you're wondering why did it take two minutes to get from point a to point b um what it did in the intervening infrastructure is probably really interesting to you but I may not but I may not own that infrastructure yeah I may not have access to that um that all that yeah that that context under the covers yeah if it flows through AWS infrastructure maybe I almost took it my neck out yeah uh before it leaps into our infrastructure um I may not have access to all the gory details of what's gone on under the covers in AWS well I think that you could either send the trace to your you know if you're seeing SLO violation you could send the trace to AWS as part of your proof um or AWS could choose to cut all the traces that are um in AWS infrastructure so it looks like you go into AWS you wormhole and you come out the other side yeah so if we if if we look at tracing specifically as tracing as forming um effectively graphs rather than thinking of traces as a straight line then um in fact what trace context does is a base it basically gives you an indicator of what was the cause for this activity and then what we're doing right now what we're doing with the trace spec if we if we adhere to the the the change that um uh doc just proposed is we're effectively copying the information so um the the the reason for where we're where we're publishing the event is captured effectively in the in the trace context and now we're doing two things we're putting it into CE attributes which is an end-to-end flow which gives visibility to the reason as the publisher had it to the consumer without the intermediate infrastructure in play and then by propagating it into the W3C context header that now lets the um the the HDP infrastructure flow makes that visible and even if that now gets propagated over by W3C context rules without cloud events being involved at all if that now does a transport change going to MQP that will get propagated so you see the entire journey and as the cloud as the event shows up in in a receiver it will be receiving that over some transport you now have two parts of two two pieces of information in the cloud event itself you're going to have the end-to-end application level of view which is simply the publisher did this because of and here's where I will now in just for my app do continue to do that trace and then you have a second view effectively which gives you the journey that that took and that is the information I would then I would expect as as Azure or you would expect as AWS if something didn't work that's the context information that you will want to give the customer to give you to do a root cost analysis while at the same time the customer's own span of control is really what the what happens what happens with the publisher and the the consumer so you would not expect in that scenario that the transport would take the richer context and then drop that into the cloud event I think I think you can choose to do that ads and when you receive the events because trace context is something so as I said I think of I think of the trace context as graphs and if or trees where you can split the context and and and cause multiple things to happen based on on where you currently are and what I'm doing is I'm as I'm setting an event I'm I'm capturing the way I'm formulating an event and then packaging it that's action number one and then I am and I'm publishing it and then I'm also sending it over the transport which is action two and I think of those as distinct activities and the send operation gets traced and then effectively me having sent that event or and then causing things with it at the application level is a second thing okay so you can shoot so so but to finalize finally answer that so at the receiving end you can now choose whether you want to override the the original context and and take the entire context with you or whether you only want to do the end-to-end thing with ignoring the transport journey okay I don't think we're going to get this resolved in the next six minutes so obviously we have to have more discussions around this offline in the issue and probably next week so let me ask this question because this doesn't impact all extensions it's just as jem said those edge case extensions that are have their own specialization which hopefully would minimal but we at least have one we know that do people think this is a requirement to solve before we approve release candidate one for 1.0 or can we go release candidate one without this being resolved I I think well and currently if I'm wrong I mean does it is the subtlety here is that we need to change the spec for that extension to make it clear that it should be doing both yeah well I think no matter assuming we just don't close the issue I assume we want to do something with the issue I think any PR is going to not only require changes to the spec but also to that extension spec yes I think that's true so the question is I'm not saying do we need it for 1.0 I think we do need it for 1.0 I'm asking whether we need it for 1.0 release candidate one I guess my question is we want a solution that also works for data content type you're breaking up there a little Evan can you say that again we want a solution that also works for data content type you mean because because the information is duplicated well because data content type is mapped to a special header and at least HTTP yeah with my proposal they would now get a CE header as well yeah yeah but my question was is handling is making data content type work the same way in scope it sounds like the answer is yes I would think so because I personally like consistency but that's just me I am fine with that oh I guess your point is it's not just a weird extension thing it's a weird extension thing that's also in our core yeah okay so what do people think is this a requirement for release candidate one or not I have an opinion but I want to hear someone else go first yes it is okay anybody disagree with making a requirement for release candidate one okay yeah Evan to answer your question I agree it is a little bit odd well not odd but I was hoping it would be sort of an outlier thing that wouldn't affect the core but you're bringing up content type is a good example of maybe it isn't just this outlier thing okay so is there any objection then to tagging this is a required for release candidate one which means we oops I'm looking at the screen which means our current plan here is a pushed out at least another week that's the implications of that decision any disagreement with that okay um in that case three minutes left oh I closed this issue consider removing the web hook spec because I couldn't think of any place else to put it Clemens I haven't Clemens and I have not any chance to talk about it and Clemens I think you've done some thinking about this and couldn't think of a good home either so I think for right now I just it's okay to close the issue we can always reopen it later if we really want to I don't think there's anything preventing us from moving the spec later and deprecating it but I want to bring it up here make sure and no one had any objection with with me closing that okay okay so anything else people want to bring up before I go back and do the final attendance we have two minutes left okay um glad or someone ping me I'm fine who was it okay glad I'm here I got you uh Javier are you there I'm sorry what was that oh I just said thanks oh yeah okay Javier are you there yes yes okay yep and Doug are you there Doug M you have a company Doug okay we're waiting um okay anything else people want to bring up on today's call okay in that case technically this call is over if you want to stick around for the SDK call I suspect it'll be very short


Live from San Jose, California, in the heart of Silicon Valley, it's theCUBE, covering QuickBooks Connect 2016. Now, here are your hosts, Jeff Frick and John Wall. Well, welcome back here on theCUBE, the flagship broadcast outlet for SiliconANGLE TV, where we extract the signal from the noise. Here in San Jose, live, along with Jeff Frick, my colleague here, I'm John Walls and we are at QuickBooks Connect 2016. We need a cup of coffee, not just any cup of coffee, you need a serious cup of coffee, and that's what Deathwish Coffee is all about. We've got Mike Brown with us, who's the owner of Deathwish Coffee. Mike, glad to have you with us here. And Andrew Berg, who's the managing partner of Berg Partners, an accounting firm, and why the two of you are together we'll get to in just a moment. First though, let's tell the Deathwish Coffee story. You were the winner of the small business big game competition here last year that QuickBooks put on, and because you were the winner of that, you received a Super Bowl commercial for Deathwish Coffee. So pick it up from there. You went through this long criteria, you checked all the boxes, they announced that Deathwish Coffee is the winner of a Super Bowl ad. How'd you feel? I cried, it was a dream come true, it was something that I couldn't even imagine happening, and then it just all hit me out at once, and it was something that my team and I, we worked really hard for during the whole competition. Actually, last year, one year ago, I think today they announced the top three businesses on stage here at QuickBooks Connect, and just making the top three was such an honor, because America came and they voted for who they wanted to represent small business in the Super Bowl. So how big of an operation were you at the time, and where are you? So at that time, we had 11 employees, and since then, in just a year, we've hired six more, and we're looking to hire another three more before the end of the year, so from the just personnel standpoint, we've pretty much doubled in size. And how much coffee were you selling before? A lot. A lot. So you did, I mean, but here you are, you're an 11 employee company in upstate New York, we're Saratoga Springs. And a Super Bowl ad, come on, Mike. We're 11 people. It doesn't happen. It's a lot of orders coming in all of a sudden. It is a lot of orders. February 4th or whatever the day was afterwards. Yeah, I believe we had about almost a quarter million dollars in sales that day. I shouldn't even say that day, that evening, because the Super Bowl didn't go off until, I think, kind of, east coast time, so, yeah. At what point of the game did you're at it? The third quarter. Third quarter? Right. All right, so all of a sudden, now you're front page news, and you're getting all these orders in. You guys freak out at all, or how well-prepared were you to handle the onslaught? Yeah, we were actually very well-prepared. We found out that we won about a month before, about a month, I'm sorry, about two months before the actual Super Bowl, so we couldn't tell anyone. It was kind of all under wraps. We had to, if we had to tell, like when we talked to our suppliers, we had to have them sign NDAs, so they didn't like spill the beans to everyone. So does he. But, yeah, we mapped out the worst-case scenario, best-case scenario, probable scenarios for every part of my business that I thought would be affected, and I set different people on my team to take control of those tasks. So we had to plan A, plan B, plan C. Luckily, it went off real smooth, smoother than we could ever expected. So you won, and then this guy walks up to you on the stage. He says, hi, I'm Andrew Burke, and I'm at a camp. And you won. So Andrew, you take it up from there. What prompted you to go up to say hi to Mike and introduce yourself and start the conversation? We didn't know we wanted Super Bowl commercial. We were here for QuickBooks Connect. I was here to get some education and learn more about what's going on in the accounting and small business world. We were watching the event where it was narrowed down to the top three, and I was with my partner, and we both looked and said, wow, that has got to be the brand that's got to win. It seems to be such a natural fit for a Super Bowl commercial to go big time. People love coffee. And so we're just always open and friendly type people. We just went up to him at the concert that was being provided by QuickBooks, by Intuit, across the street, and just said, hi, why was having a beer? And I asked a couple of key questions, and I think it was clear that he was overwhelmed, and he kind of knew, wow, something big's about to happen. And it was clear to us pretty early on that he was being underserved.  He said, but by the way, you got to sign this NDA before you're on a video call. I'm like, sign this NDA for what? And then that's what he kind of told me after I signed it, of course, what was going on. And I kind of went back to my team and said, oh my God, this is go time for us too, because he needs to be ready to be able to manage his business for what's about to occur. And it was our job to take away a lot of responsibilities off his plate and kind of leave his brain fresh to take care of what he needed to do. This was going to be a huge change for his business. So it was pretty amazing. I never would have expected it to be as amazing a trip as it's been so far for the last 12 months.  Usually for big companies, like a Pepsi commercial or promo or Coca-Cola, what were some of the things that you put in place in anticipation of this event? Thinking proactively.  And then what turned out in the way that you had no idea? There must have been a couple of things that just like, whoa, we didn't see that one coming. So as far as the website goes, we run on the Shopify network. So we called up Shopify and we're like, listen guys, we can't have any hiccups here. Stand up some servers. Yeah, get these servers going. They actually put together a 12 person team on their end to watch our website as it went off. And it went off without a hitch. It was actually really smooth. They told me they put me on the Kanye plan. And I'm like, what's the Kanye plan? And they're like, oh, Kanye released his last album on our servers and it went off fine. Millions of people. So it was like, all right, I felt a little better about that since it was on the Kanye plan. So yeah, that went well. We had to reach out to third party help for our production. That went kind of smooth. It could have went better. I think the only hiccup, we had one vendor who underperformed and couldn't do what they said they were going to do.  Did you obviously stock up significantly before? Stocked up. We had to hire some customer service reps. We do all of our customer service in-house. So we had to get them ready. We actually brought in some new technology to help with the customer service requests and do some auto replies. Just stuff to handle the extra traffic. We rearranged our website and made it very, very easy for our customers to purchase. It was basically, they got to our website, they could just do a one click, one click buy. They didn't have to search around for the product. And we thought, you know, there was a lot of brainstorming, a lot of team meetings. And I think we handled it well. There was no problems that were above and beyond what we could handle. And how much was Intuit and QuickBooks involved in that process, you know, beyond just giving you the commercial? I mean, they've been great. They've been so supportive throughout the entire process. I've actually been out to into its headquarters a handful of times since the commercial went off. They work with Andrew a lot. Andrew's actually on their accountant's counsel. Accountant's counsel. So if I have any problems, I can go to Andrew and Andrew can go directly to them and put it in accounting terms for them, you know? So they understand. So then what did you do? What was your kind of bunker up? Get ready. You never know what you're going to get involved with when you get a new client. So sometimes the client doesn't know exactly what they need and don't need. So asking the question is doesn't really get to the answers. Look at what I said. Especially it's a Super Bowl ad, right? I said send me your books and I looked at it and it was clear it was completely underserved. I mean, Mike had no access to his own bookkeeping at all. It was being held on his bookkeeper's server and he wasn't allowed to look at it and they would send reports and the reports didn't have any meaning. And I said to Mike, look, we need to make changes immediately. So in December, we immediately moved to QuickBooks Online. So we had visibility of his bookkeeping, started to restructure it so that the records made sense and then we started to remove some administrative responsibilities that Mike was taking once so he could focus on other things. So we went to bill.com immediately, had him go to hire a new person in his office who was going to handle the administration of paperwork, getting where it needed to, take that bill, paying responsibility off of Mike despite the fact that Mike still wanted to have control over authorization so he does have that. That was really very, very early on probably within the first 30 to 60 days we installed all of that knowing we needed to be ready. Mike also, we failed to mention that we talked that you were working with a third party facilitator too who had to be brought up to speed so he third party facilitator had to be notified to provide more rack space and by the way, there's all these orders going to be coming in. So there was a lot that went into it and you should probably mention real quickly what happened with the week before when the commercial was first announced and you were on TV in the morning. We kind of got a preview of what was going to happen because a week before the Super Bowl the commercial actually went out. Yeah, the commercial aired on CBS this morning with Gal King, I believe her name is. And it aired in the morning and it was just from that publicity in the morning we saw a giant spike in sales. So it was kind of like a, I guess a warm up. Shot over the bow, if you will, in the commercial. Curious, this really is not relevant to the discussion but what kind of traffic do you get from a Super Bowl ad? Like website traffic, what kind of numbers you got? Yeah, so I mean I was watching it. I was in my palm of my hand on my cell phone. I'm watching the traffic go up and within the first 10 minutes we had over 150,000 people on our site at one time and it stayed up. I assume that's a bit of an increase from what you usually have. Yeah, usually we'll have. I mean on our email release day where we send out a newsletter we can get up to 1,000 at one time about 150,000, that's almost unheard of. You know, Andrew, some of the things you're talking about here, I mean I know a Super Bowl ad was the motivation here, right, that's what drove it. But I get the feeling that just in general when it comes to accounting some of this hygiene you're talking about should be standard practice. That you should have full transparency. You should have full access. You should have this and that and the other. And there are probably a lot of small businesses that don't know what they're missing or what they don't have because they don't know what they don't know. Absolutely, you know, one of the reasons I've structured my practice the way it is is because I want to help small businesses focus their attention on what they do best. Why did they open that business? They opened the business to do whatever they love to do. They didn't open it so that they can learn bookkeeping. They didn't do it so they can start doing bill pay. They didn't do it because they want to deal with HR issues. So I looked at it and said, you know, I want to design a firm that takes those responsibilities easily away from the business owner so he can go ahead and grow his business. The fact that he had a Super Bowl commercial was going to be a catalyst to be able to kind of proof of concept for us and we've been doing this for a lot of years and it's really a passion of mine to say we really want small businesses to succeed and that's why I think I fit in really well with Intuit's concept and Quick Book's concept of what's going on here at this conference because we are all on board with trying to alleviate the fears that all small business owners seem to have and help them focus their attention on why they went into business and help them be successful. So just a quick tidbit story. So Mike was in San Francisco when the whole Super Bowl thing was going down with Intuit and I actually was lucky enough to be at the Super Bowl in Intuit's box watching at the same time. It's a pretty nice perk by the way. It was unrelated, completely unrelated, believe it or not. It was a completely unrelated reason to be there but I was there and I had my phone and I'm kind of looking at what Mike's looking.  And it was just an unbelievable night. I just, as Mike said, the numbers were astronomical and it was hard to sleep that night. Now that night's gone. We're still only a few miles from Levi's Stadium. Hopefully you went by and touched your wall again. It was a great night. So where are you now? Kind of what was the bump that you got? Obviously you got a huge bump but you hope that the dip is a little higher than the new baseline. So how has it really kind of changed your business? And as you look forward now and also now with the pro behind you, how are you transforming your business? What's next for Death Wish Coffee? Yeah, I mean, of course, with the books, it's totally transformed. Now I have, working with Andrew, I have a clear picture of where my business was a year ago and where it is now and all the months in between, I have like a story, a pattern, I have a budget that I follow. So my books are solid, which is great. It feels good. I can forecast what's going to happen in a couple months and make decisions based on all these numbers I have in front of me. In terms of growth from the Super Bowl, the big challenge coming out of it was, yeah, this customer retention. We didn't want people to try our product once and be done with it. So we worked on some marketing techniques where we can get more repeat customers. We have subscription service we offer. We ask people to join our mailing list, so we're able to capture a lot of those customers' information and with their permission, we've remarketed them monthly. That's been very powerful. But after the peak, yeah, we peaked and we leveled off at a really decent number. Our revenue has quadrupled this year. Quadrupled, nice. Quadrupled in one year. It's been a good year. It's been a good year. So if we can keep that going, which I think we do, fourth quarter is usually our strongest quarter. We do about 40% of our revenue this quarter. So we're watching numbers closely. We have a lot of, I have new staff that have brought on to help me with the demand. We're moving into a new facility. We purchased new equipment so we can start pulling back from our third-party producers that have been helping us out. So we heard from Andrew about, he thought you were being underserved and some things that he could change. If you were looking into the camera here and talking to a small business owner at home who's not here at the show, and you give them some advice in terms of the relationship you want with your accountant, what they should be looking for, and maybe some things they're not seeing, what would that be? I'd say, when we talk, raise the camera here. Yeah, sure. Right ahead of you, what? Small business owners at home. If you're only talking to your accountant at tax time or when you have a problem, that's a problem. You should be talking to your accountant on regular time intervals. I talk with Andrew once a week. We have a video call. If your accountant's not up with technology and what's going to make your job easier, maybe you should have a talk with them about that, what tools are out there that they can use. And get those budgets together. I'm a forecast with you. You could probably chime in too, Andrew. Yeah, I'll tell you what. It's not just about what I do. It's about the owner being willing to listen as well. Mike has been so great at saying, kind of tell me what we can do to be more efficient. And I say, I have this great idea and he's like, all right, let's test it and see what how it works out. And we've been able to install new technologies. One of the things that I had mentioned to Mike way early on when I first went up there, so we drove, I'm outside Philadelphia, and they're outside of Albany, New York, so that's a five hour, six hour drive. We drove up there and the first day I met up there with him, I kind of drew out a flow chart on a loose leaf piece of paper and said, this is what I think's going on in your business. Let's sit down and talk and tell me whether I'm right or wrong. Here's where our goods come in, raw materials, here's how it's manufactured, here's how you get paid. And we literally tried to use that to install a system, not only for him to use from a production perspective, but I can use to kind of develop the books. And one of the things early on we talked about was margins. And we said, Mike, how much does it cost to make a pound of coffee? He knows how much he sells it for, but I said, how much does it cost? You know, it's easy to know the cost when you pay a third party producer because they send an invoice. But what does it cost if you do it inside? That's hard. And small business owners don't normally spend the time because it's so hard to calculate those hours and those minutes that a person spends to produce something and all those materials. So we actually spent the time and realized, wow, there's a huge savings here. So Mike, over the last pretty much 12 months, maybe eight months, has said, we got to start to think about moving to a new facility, bringing production. And because that number is such a huge number in pennies per bag, but multiplied by lots of bags is a lot of money, you can say. Well, I would say if there's one more piece of advice that I could throw in, sit down with your accountant over a cup of coffee. That would be death wish coffee, right? Mike Andrew, thanks for joining us. We appreciate the time. Congratulations. Thank you very much. Good to see the partnerships working out so well. Thank you very much. Back with more from San Jose here. TheCube continues our coverage live in just a moment.


We're back at AWS re-invent 2021. You're watching theCUBE. We're here live, one of the first live events, very few live events this year. It's the biggest hybrid event really of the year, of the season. Hopefully it portends a great future. We don't know, it's a lot of uncertainty, but AWS said they're going to go for it close to 30,000 people here. Chris Weiburg is here. He's the product VP of product marketing at Cohesity. Chris, great to see you face-to-face, man. It's great to see you live again, Dave. You're saying, yeah. Over the last couple of years, we've had a lot of virtual meet-up hang-out. We talk every other quarter. So it's great to see you. Wow, we were talking before the show. Well, we didn't really know what it was going to be like. I don't think AWS knew. It's like everything these days. You know, we did our own virtual event back in October because that was the time, and this is the first thing we've been back to live. And I was wondering what's going to be like when I show up, but it's great to see all the folks that are here. Yeah, so I could see the booth. You guys have had some good traffic. We have. A lot of customers here, obviously huge ecosystem. This, you know, the quote-unquote flywheel keeps going. Yeah. You and I had a conversation recently about data management. It's something that you guys have put a stake in the ground. Absolutely. Saying, you know, we're not just backup. We're data management. It's fuzzy to a lot of people. We've had that conversation, but you're really starting to, through customer feedback, hone that message and the product portfolio. So let's start from the beginning. What is data management to Cohesity? Well, so for us, it's about the data lifecycle, right? And you heard a little bit about this actually during the keynote today, right? When you think about the various services you need to apply to data along the way, to do basic things like protect it, be able to make sure you can recover from disasters, obviously deal with security today, given the prevalence of ransomware out there. All the way down to at the end, how do you get more value out of it? And we do that in some cases with our friends from AWS using some of their AI ML services. So yeah. Right, so your view of data, I mean, it doesn't, it kind of stops at the database, right? Underneath, there's an adjacency to security that we've talked about. Yeah, very much. Data protection is now becoming an increasingly important component of a security strategy. It is. It's not a direct security play, but it's just the same way that it's not just the SecOps team has to worry about security anymore. It's kind of other parts of the organization. Talk about that a little bit. Yeah, well, we actually had a customer advisory board about two months or so ago now. We talked to many of our customers there.  We asked them, you know, where do we stand in your spend these days? And he said, well, I'll tell you a while back, about a year ago, having new backup and recovery as a starting point was kind of on the wish list. And he said, today it's number two. And I said, well, why? He said, well, because of ransomware, right? You'll be able to come back from that. And I asked, well, great, what's number one? He said, well, endpoint security. So there you are, number one and number two, right? Top of mind for customers these days in dealing with really the scourge that's affecting so many organizations out there. And I think exactly to, I think where you're going, you're starting to see these teams work together in a way that perhaps they hadn't before, right? You've got the SecOps team, you've got the IT operations team. And while exactly your point, we don't position ourselves as just a data security company. That's part of what we do. We are part of that strategy now, where if you have to think about the various stages in dealing with that, defending your backups, because that's often the first point of attack now for the bad guys, being able to detect what's going on through AI and anomaly detection and such. And then being able to rapidly recover, right? In the recover phase, that's not something that security guys spend time on necessarily, but it's important for the business to be able to bring themselves back when they're subject to an attack. And that's where we come in in spades, right? Yeah, so the security guys are busy trying to figure out, okay, what happened? How do we stop it from happening again? There's another business angle which is, okay, how do we get back up and running? How much data did we lose? Ideally none. How fast can we get it back up? That's another vector that's now becoming part of that broader security stack. That's right, I mean, I think if you look at the traditional NIST cybersecurity framework, right? Stage five has always been the recover piece. And so this is where we're working with some of the players in the security space. You may have seen an announcement we did with Cisco around Secure X recently, where we're working together, not only to unite two tribes within large organizations, right, the SecOps and ITOps guys, but then bringing vendors together because it's through that that really, we think we're going to solve that problem best. Before we get into the portfolio and I want to talk about how you've evolved that, let's talk a little about ransomware. It's in the news. I just wrote a piece recently and just covered some of the payments that have made. I mean, I think the biggest is 40 million, but many tens of millions in here. And it was one case, I think it was the Irish Health Service, did not pay, they just thus far hasn't paid, but it's costing them $600 million to recover as the estimate. So this is serious threat. And as I've said many times on theCUBE, I think that anybody can be a ransomwareist. I go on the dark web. I say. Ransomware is a service, right? Right, ransomware is a service. Hey, can you set up a help desk for me to help me negotiate? And I got a, I'm going to put a stick into a server. And, you know, I hope that individual gets arrested, but you never know. Okay, so now it's top of mind. What are you guys doing? First of all, what are you seeing from customers? How are they responding? What are you guys doing to help? Yeah, well, I think you're right. First of all, it's just a huge problem. And I think that the latest stat I saw is something like every 11 seconds, there's a new attack because I can go into your point with a credit card, sign up as a service, and then, you know, launch an attack. And the average payment is around 4.2 million or such, but there's some that are obviously lots bigger. And I think what's challenging is beyond the costs of recovering and of itself is there's also the issue around brand and reputation and customer service and all these downstream effects that I think, you know, the IT guys don't think about necessarily. We talked to one customer, a regional hospital, where the gentleman there told me that what he's starting to see after the fact is now you've actually got class action suits from patients coming after them saying like, hey, you let my data get stolen, right? Can you imagine? No, IT guys thinking about that. So the cost is huge. And so it's not just an issue, I think, that was once upon a time just for IT ops or sec ops or the CIO even. It's even past the board level now, if you can imagine. It's something that general public worries about and we actually did a survey recently where we asked people on the consumer side, are you more or less likely to do business with companies if you know they've been subject to ransomware attacks? And they said, no, we're concerned about that. We're more reticent to do business with people as consumers if they're not doing the right things to defend their business against ransomware. Fascinating, right? It's a long path to tipping point where this is an IT only issue. So high level strategy. So we talk about things like air gaps. When I talk about your service to ensure immutability. Yeah. So at a 50,000 foot level, what's the strategy that I want to get into specifics of? Sure, well, let's talk a little bit about sort of the evolution of the nature of attacks, right? So once upon a time, this is in the distant past now, the bad guys used to come after your production data, right? And so that was pretty easy to fix with companies like us just restore from backup. They got a little smarter. Let's call that ransomware 2.0, right? Or now they say, let's go after the backup first and encrypt to destroy that. And so there, to your point, you need immutability down to the file system level.  You got to defend the backup data itself. And increasingly we're seeing people take in isolation in a different way than they used to. So you probably recall the sort of standard 321 rule, right? Yeah, sure. Where the one traditionally met, take that data off-site on magnetic tape, send it to Iron Mountain, for example, and then get the data back when I need it. Well, you know, if your business is at risk, trying to recover from tape, it just takes too long. Like, there's just no reason. It can be weeks. It can be weeks. And you got to locate the tapes, you got to ship them, then you got to do the restore and just because of the physical media and nature, it takes a while. So what we're starting to see now is people figuring out how to use the cloud as a way to do that and be able to have effectively that one copy stored off-site, right? In a different media and use the cloud for that. And so one of the things we announced actually back in our show in October was a new service that allows you to do just that. We're calling it, for now, Project Fort Knox. We're not sure if that name's going to work globally, right? But the idea is a bunker, an isolated copy of the data in the cloud that's there that can restore quickly. Now, is it as fast as having a local replica? Copy of course not, right? But it's way better than tape. And this is a way to really give you that sort of extra layer of insurance on top of what you're already doing probably to protect your data. And I think that's the way to think of it. It's an extra layer. It's not like, hey, do this instead of tape.  Just in cases. And there's some that'll still do that. For all sorts of reasons, including compliance and governance and regulatory ones, right? Yeah, and even disaster recovery scenarios of the worst case, I hope I never have to go to it. Yeah, you could go to the cloud. That's right. So local copy is the best. If that's not there, you've got your air gap copy in the cloud. If that's not there, for some crazy reason. We have a whole matrix we've been sharing with our customers recently with the different options, right? And it's actually really interesting, the conversation that occurs between the IT operations folks and the SecOps folks back to that. So some SecOps folks, if they could, they just unplug everything from the network. It's safe, right? But we can't really do business that way. So it's always a balance of what's the return that you need, and by return I mean coming back from an attack or disaster, versus a security. And so again, think of this as an extra layer that gives you that ability to sleep better at night knowing that you've got a third, a tertiary copy stored somewhere off-site in a different media, but you can bring it back at the same time. How have you evolved your portfolio to deal with both the data management trends that we talked about and the cyber threats? Yeah, well, a number of things. So amongst the other announcements that we made back in October is DR, right? So DR is not a security thing per se. You know, who gets paged when something goes wrong. It's not the InfoSec guys for DR, it's the ITOps guys. And so we've always had that capability, but one of the things we announced is be able to do that to the cloud now in AWS. So instead of site to site, being able to do it site to cloud, and for some organizations, that is all about being able to maybe eliminate a secondary site, you know, smaller organizations. Others that are larger enterprises, they probably have a hybrid strategy where that's a part of their strategy now. And the value there is it's an OPEX cost, right? It's not CAPEX anymore. And so again, you lower your cost of operations. So that's one thing in the data management side. On the security side, another thing we announced was yet another service that runs in AWS that we call Cohesity Data Govern. And this is a way to take a look at your data before something ever occurs. One of the key things in dealing with ransomware is hygiene, is prevention, right? And so you sort of have classically security folks that are trying to protect your data. And then another set of folks, certainly large enterprise, that are more on the compliance regulatory front, wanting to know where your PII is, your private sensitive data. And we believe those things need to come together. So this data govern product actually does that. It takes a look at first classifying your data and then being able to detect anomalies in terms of who's coming in from where to get to it to help you proactively understand what's at threat. And first of all, where your crown jewels really are and make sure you're protecting those appropriately and maybe modifying access policies you have set up in your existing native applications, right? So it's a little bit of awareness, a little bit of prevention. And then when things start to go wrong, another layer that helps you know what's going on. I love that. The other side of the coin I made, I can get privacy as a service along with my data protection as a service. Now that's a better model. Tight on time. So the last question, the ecosystem. So you mentioned endpoint security. I know identity access is cloud security and since the remote work has really escalated. Talk about the ecosystem and some of the partnerships that you're enabling, API integrations. Yeah, totally. So you know, we have this, this is what we call our threat defense model. It's got four layers to it. One is the core is all about resiliency. You need to assume failure.  It has to be immutable to keep the bad guys out. You have to have encryption, basic things like that. The next layer, particularly in this world of zero trust, right, is you have to have various layers, access control, obvious things like multi-factor authentication, role-based access control, as well as things like quorum features. It's the two keys in the safety deposit box to unlock it. But that's not enough. The third layer is this AI powered anomaly detection and being able to do data classification and such. But then the fourth layer, and this is beyond just us, is the ability to easily integrate in that ecosystem, right? So I'll go back to the Cisco example I gave you before. We know that despite having our own admin console, there's no sec-opt person that's going to be looking at that, right? They're going to look at something like a secure X or maybe a Palo Alto XOR. And be able to, you know, pull signals from different places, including endpoints, including firewalls. You're going to feed that. Exactly, so we'll send signals over to that. They can get a better view. And then because we're all API based, they can actually invoke the remedy on their side and initiate the workflow that then triggers out to do the right thing from a data protection standpoint and recovery standpoint. Well, it's great to have you here. Thanks so much for coming on and see you in the evolution of, yes, absolutely. Hopefully we'd do this a lot in 2022, Chris. Absolutely, looking forward to it. All right, me too. All right, thank you for watching. This is theCUBE's coverage, AWS re-invent. We are the leader in high tech coverage. We're right back.


Hi everyone, Joe for jazzy's case breaks.com. This is just the randomizer for 2022 tops series one Baseball jumbo edition six-box random team break number one. This is where one spot gets you three teams Teddy. What's going on? All right, so this is for a break one where one spot gets you three, so let's triple your names up There's one already. There's two and there's three and all 30 Baseball teams are in let's roll it randomized names and teams Two and a four six times obviously the if you look at the break schedule the video for this the actual break for this will be later Tonight two and a four six, so you have all that time to trade if you want to two and a four six times For the names one two three four five and Six after six we got Justin at down Jared and Again, the break for this will be later tonight two and a four six times for the teams one two three four five and Six in final time After six we got the red legs Down to the Cleveland Guardians. I think this will be the first set Where we'll see Cleveland Guardians printed on the card All right, Justin with the reds Aaron with the blue jays Charles with the twins Tim with the Mariners Jeremy with the Phillies Darren with the Braves Chad with the Yankees Tim with the Mets Jeremy with the Astros Chad with the Cardinals Jared with the A's Jeremy with the Pirates Michael with the Red Sox and Rays Justin with the Royals Aaron you got my Dodgers Charles with the Angels Aaron with the White Sox Chad with the Diamondbacks Michael with the Tigers Tim with the Padres Darren with the Giants and the Brewers Justin with the Cubs Ryan with the Marlins Jared with the Orioles Charles With the Rockies Ryan with the Nationals and the Rangers and Jared Patterson. You have the Cleveland Guardians So let's sort by column a or column B alphabetically by team and We'll see you a little a little bit later tonight for the break itself Jasky's case breaks calm. Bye. Bye