Tara, you're launching a group coaching program in four weeks or so, six weeks maybe, and it's great that you are planning in advance because now you can schedule the various posts to announce the program or to remind people about the program. So essentially, think about each platform that you're on where you have an audience. So including your email newsletter, you know, your Facebook page or Facebook profile, your Instagram page or YouTube, your podcast, your medium, wherever you have an audience. Those places, those audiences deserve to know about your group coaching program because they get your content on a regular basis, and they deserve to know that you don't just write content for a living. I laugh at that because a lot of people go, Oh, I didn't know you provide that service. What do you tell I think about my service all the time but but our audience never thinks about our service and until it's right in front of them and they think about it for 24 hours. And then they forget about it again, the next until the next time they see it right in front of them they remember for 24 hours again, if we're lucky, maybe only 24 minutes. So, so this is why we need to remind them each platform needs to be reminded multiple times before the program launches. I would say each platform, you know, I think I believe in gentle launches so I don't like most marketers would say 85 times per platform or like 17 times or like, at least 12 times. I just say three times, you know, it's like three times per platform is enough for and it's this three times distributed over the time of the launch, you know, so if you have six weeks. Gosh, that's very, very spacious. And you could, you could each platform you announce it once every two weeks, or let's say once every week slash week and a half. That's very spacious. Okay. Yeah. Do you think, gosh, you've got me in such the content mindset. I like the idea of being out for two weeks, not posting on a content but then just by the way just for those watching the recording. It's going to, you know, she personal reason she has to take two weeks off. But let me just go ahead and pause this for a second here. So, thinking about those three posts per platform and what would be those three posts. I mean, there are so many so many possibilities but essentially let's do a quick quick off the top of the head kind of framing on this so post one could simply be. You know, to announce my new program. I mean straight up. This is who it's for. This is what you can expect in the program.  Here's a link for more information kind of like a straight up post number one on all post number two could be, you know, the either the origin story of why you decided to create this, maybe it's your own story of, you know, for example, when I shared. When I was launching the TLC draw for productivity coaching program. People found it really helpful when I shared my own struggles with it over the years and how applying those skills really changed my business and change my life. And, and it was helpful for them to hear that I was just like them. Like I was it wasn't born with us with a spreadsheet in my hand. But but so maybe origin story relating to the ideal client would be helpful. And then maybe post number three would be a few testimonials powerful testimonials and people now maybe it's a new program. And you don't have testimonials for this new program but it's okay you probably have testimonials for just people who work have worked with you in other ways. And, you know, or if you've launched it as a beta program before maybe a testimonials there but yeah so just just three different posts three different ways of talking about the program would be a, you know, a good idea, keep it some give it some variety. Perfect. Thank you.


From New York, it's theCUBE. Covering Big Data New York City 2016. Brought to you by headline sponsors, Cisco, IBM, NVIDIA, and our ecosystem sponsors. Now, here are your hosts, Dave Vellante and Peter Burris. We're back, this is theCUBE, the worldwide leader in live tech coverage. Really excited to have your own Javier here. He is the founder and CTO of Iguazio, a company you may not know. We know, because we've been talking a lot on social, some of the smartest people on the planet, participated in our crowd chat. A lot of great perspectives. You're on, welcome to theCUBE. Thank you so much for coming up. Thanks Dave, thanks for having me. Yeah, you're welcome. So we're excited for you guys announced, basically announced the coming out party yesterday, right here. Yes, we've been here in theCUBE before, but more sort of doing architecture launch, describing a little sort of our concept. It was pretty revolutionary. So we said we'll do it in two phases, but yeah. And we got the car, this is you showing this at your booth. So tell us the story. What's going on this week? You announced your products and you've got the... So what is Iguazio? We have a bunch of great guys, founders of Xtreme IO, guys from XIV, guys from sort of different units that understand the entire stack. And everywhere from sort of the lowest layer of how flash works and disks and networks, all the way up to applications. And we basically decided that the existing stack doesn't work for new workloads, for analytics, for big data, and for the transitions that we're going to talk about in a minute. And we sort of re-architect the entire stack. And this re-architecture that allowed us to basically produce 100x better performance and things that most customers think are unbelievable. You know, our database level performance are like few million ops per second on a given server. When traditionally if you look at like Amazon or even Cassandra and some of the open source, it will be in the tens of thousands. So it does sound imaginary. And at the same time, we did build it extremely dense in a way that it allows us to actually lower the cost. So our solution is 100 times faster and 10x slower than most of traditional solutions because we basically broke the entire stack and meshed it up together. That's generally. And you've written, you write some great blogs and I guess that's the kind of thing you gotta do when you're starting the company, right? Help get the word out. But one of them really talked about the challenges that customers have with Amazon, with all the different components and the services and the variety of APIs that they have to deal with. You're trying to solve that problem, are you not? Yeah, so basically we have three major innovations. One is sort of this extreme efficiency and performance. The other one is we have what we call a multi-model database model. That means that we can basically build any type of data on top of our platform, whether it's files or streams or objects. You can actually ingest the data as a streaming element and read it as a table or scan it using an analytics primitives. And that requires a complete rearchitecture of how the engine works. It is leveraging the modern architectures because many of the existing databases were basically foreign around hard drive limitations which are very sequential by nature. So you wanna avoid in directions and things like that. And by having more flash, more memory, that means you can do more in directions, especially if you have all the things that we have in our stack for prediction and all that of IO. And then you could actually create those multi-model elements. Now having a database and running a file system on top of it buys you additional things. Like for example, you can run SQL statements to look for files. Give me all the files belonging to Joe from the last week. And we think that with this enormous growth of data in the different disciplines, IoT, big data, analytics and software as a service, you need those capabilities to handle data. So basically we have one platform that stores all kinds of data at much faster speeds than anyone else. And that also allows you to create different pipelines because instead of thinking data, streaming it in and then taking another package that basically migrates it into another form and then thinking that thing and turning it into analytics, we actually took some Amazon blog post of saying this is how you would build the stuff. And we showed that instead of six different elements that you paid, the most expensive element in Amazon actually is the TPS, not the capacity. So you actually pay six times for every transaction in the Amazon case. So beyond the 100X is actually even cheaper because you have one platform. It also simplifies the application perspective because instead of just producing sort of low level APIs, we went the Amazon way and introduced all the sort of restful APIs which we love them. That's why we sort of have those cars and all that in the show. We showed that an Android client or an Angular app can just talk to our system. It doesn't need any mediation. One of the things we did, we basically have a layer seven firewall within the data pipeline, an extremely fast one. So every transaction that goes into the system is classified. So now I can say things that come from cars are not allowed to touch this data. Things that come from Android apps are not allowed to update this data. And this is a totally new paradigm. I don't need API services. I don't need all this glue logic to ingest data. And the minute I generate an event, immediately I see that in an analytic dashboard. Another great thing we did is we took this notion of platform as a service. I think more and more people don't want to manage servers. They don't want to manage disks. They want to manage apps and data. And this is sort of what we've innovated around. There is basically focusing on data management and not on infrastructure management. So you've done some very, very interesting things with technology that allows you to do that. So by compacting, reducing the size of the data, you're able to reduce the amount of data that has to be moved, but at the same time, you can actually process it. You can act on it. You can do things with it. So talk a little bit about some of the special sauce that you've developed that makes it possible to do all these things. Yeah, so first, Dave knows that from our chats in Twitter. I'm sort of not a fan of traditional storage, like block storage, because think what they do, they take a 4k size block, and then they compress, and they do put and do all those things. And if I need to search the data, I have to decompress this 4k byte and then start figuring out where things are at. And instead, I rather do that at the database level. I rather encode the data instead of just compressing it. If I see a string saying username, I basically compact it to a number saying seven. And then I search, look for seven. I don't need to look for an entire string. I basically, I put a lot less data into the memory. I waste a lot less bandwidth on IO and all that, and I do more efficient things. You also tear the data, and not sort of basically throw everything into the block. You need to treat indexes differently. You need to treat metadata differently and blobs differently. And that means that your data is scattered across different technologies to maximize the value. Now, if you're using traditional disk technology and you have all this burgeoning and snapshots and all that, it doesn't hold water because your data is actually scattered across five different types of storage for the same transaction. You cannot gain consistency. And some of those ideas sort of, we haven't invented them. We took ideas that, you know, sort of my work with hyperscale customers, and we just evolved them because I think us coming from low level infrastructure understanding, we took the same concept that Google and Amazon have and just deployed them on a much higher performance architecture on the software. So what, when somebody buys a Guasio, what are they buying? What are they getting? So basically we're a platform as a service. It's not an individual software component. It deployed in two forms.  And another one is we'll sell you the software on a reference architecture. Our reference architecture is very sort of high end configuration. Every one of our appliances is about 400 gig ports and 24 NVMe devices. And each one of those can displace about 60 servers on Cassandra or something like that. So we basically, what we did is a very high density approach. Every server connects about 300 disks compared to a dupe approach of 12 drives per server. That is really the secret sauce that allows us to, on one end, increase the performance, but on the same time, lower the cost to serve the archiving storage kind of cost levels. So the idea is if you're, for example, we're only working right now with tier one customers versus where it's still beta level. So we like the more lucrative customers. So these are banks, cloud service providers, even Amazon, large Amazon customers, software as a service companies. One of them is sort of an Uber-like use case. And they took our stuff and they used Amazon Redshift. They took our stuff with Spark, and they got about 10x better performance at way lower cost. And that's how. Role to Amazon Redshift. Compared to Amazon Redshift. Amazon Redshift is about $1 per gig per month versus S3, which is only $0.03. So everyone likes to quote the $0.03, but they forget that when you buy Dynamo or Redshift or the more sophisticated services, it's way more expensive. So we sort of give them a price model of something which is way cheaper. We've produced 10x better performance on the application level, and they can now also own the storage. One of the challenges many organizations have, they're afraid of moving their data into the cloud, whether it's because governance issues, whether it's because they just want to have the freedom to move between one provider and another. And we have very close partnership with Equinix. They were also quoted in our press and some joint customers. Basically, we put those racks in Equinix in sort of a hub connected directly to Amazon and other service providers. And you can actually do burst computing. You can actually run VMs in Amazon and analytics on our platform. And we have a sort of dark fiver into those places. So now it cuts the cost even further because the cheapest thing in Amazon is spot instances. Just VMs without any disks. And especially if you have people that need to run VMs, one of the things we see in R&D, if I keep the VMs, sometimes I ask for my VMs because I'm also sort of a geek and like to code. And they tell me 100 bucks a day because I have to keep the VM. But I'm not really using it. I need to write blogs and do other things. Build cars. Yeah, build cars. So really what you want to do is when you turn off the VM, you want it to sort of disappear. You only want to pay a dollar for the time you were using it. So you want to decouple the storage from the computation and just launch. And the essential thing is basically having the separation that the VM doesn't hold any state, which is this sort of cloud native architecture. So your licensing model is a subscription? It's an annual subscription sort of model and determined by two sort of main factor, performance and capacity. Whether that's the same if I buy an appliance? Yes, basically when you buy an appliance, we give you the hardware at cost plus sort of movement fees and that sort of thing. But what we want to make it very transparent to users, we're not after being sort of an EMC model, 60, 70 points margins across hardware. We're basically a software company. But what we see is that customers like this notion of an integrated turnkey solution. So we say, okay, we'll give you this integrated turnkey, but we'll charge you for the software. In part, we're working with all the old regular suspects on sort of the OEM side and potentially have others resale a configuration with our software as well. And they would buy perhaps the software of the reference architecture, an SDK or? Yes, and so we have a lot of experience with it in the past, both in Voltaire and Manux where I was, we were always in sort of an OEM model with most of the, you know, San, Oracle, IBM, HP, et cetera, where we were doing the sort of the customer sales, but the fulfillment was is OEM model. So we're quite accustomed to this kind of model. We're still early stage, so we're working directly with customers. But long run, it's sort of a partnership game. So what's your take on, I mean, you saw our server sand report, you see the sum of the work that we do. What's your take on hyper-converged infrastructure? You said you mentioned Nutanix before as a model. Yeah, I think they're a great company. So I don't have any reason to bash them as a company. I think in general, the HCI model is not a long-term sustainable model because what the cloud guys, you know, basically what you see in the enterprise side, and I don't, it's not just Nutanix. It's all this sort of HCI movement, et cetera. They're basically trying to create an Amazon EC2. That's something Amazon did five years ago, okay?  Where is Google investing their money? Is definitely not there.  They're sort of joking, joking in one of the tweets. It's sort of the wide generation, you know, they want things to work. They don't really want to do what we used to do, you know, bring up VMs. They want the cake, not the bake. Yes, and if you're looking at segmentation of the market, you're going to have companies with like hundred folks, okay? They don't need any infrastructure. They need Office 365. They need the RP in the cloud. They need apps. They don't need any infrastructure. And if you're looking into bigger organizations where you're going to see the big movement and it's not going to change overnight, you know, people are still using mainframes, is basically the move to data in the center, I call it. Basically, the organization will try and centralize more and more data, create governance around it, and the compute is going to be the floating point, whether it's going to be mobile devices of the workers, whether it's, you know, the website that may be even hosted somewhere. So it's going to change the paradigm. And in this environment, HCI is not the right play. So HCI is the right play for the existing architecture of people that don't like sands and don't like fiber channel and all that stuff and still play with LUNs and VMware and Oracles. But if someone is building a cloud native architecture or a data-centric architecture, they're either going to go to a cloud or they're going to create an a cloud-like experience for the enterprise. So again, it's not going to go away, but what I had my comments on your report, it was sort of so biased towards the entire world is going to be sort of HCI. And I see that from our discussions with CSOs and CIOs and all that, that's not where they want to take the company. They want to move to pass. And I think there is sort of, if you look at sort of the CIO and IT folks, there is some tension right now because sort of IT, what they know is VMware and SAN and Word by names and all that stuff, okay? And they're sort of having a hard time evolving into this sort of service model. Some of them are evolving and they actually own the relation with Amazon, for example. So they're no longer the guys that making the thing work. They're also the brokers for the service. But what you would see is that if they want to evolve fast enough, the business units, the guys that serve are the shadow IT that are basically taking up the wallop and doing the development in Amazon because it's sort of too difficult to do it on-prem. They'll either go to Amazon or say we want the Amazon-like experience on-prem. So I think this movement will be faster than what you guys are anticipating. And that's a reasonable look. We've had a fair amount of debates inside about what's going to be the local, the focal point or the low side of where the value proposition is. Is it going to be IAAS? Is it going to be PASS? Is one going to supersede? I have my way of thinking, but these are good. This is great feedback. One question before we go, if I can? Yeah, we're out of time, but go ahead. Oh, okay. Okay. It was quick. Next time you're on theCUBE, let's talk about whether or not developers, how much developers need to know about the platform and how better performance makes you a developer. Yeah, we're trying to make it totally transparent. And we actually have, I have in a couple of hours a meetup in Docker in New York and we're going to talk about serverless and API-driven computing, complete cloud native. We're actually going to show some demos. But basically we're going after the big megatrends of IoT, which is very data-driven. Cloud native apps and SaaS providers. Also a lot of very developer-driven, stateless and all that. And the third one is sort of the big data camp with sort of next generation kind of data warehousing and analytics. So these are the three things that we, as a company, go after. I think those are sort of the biggest megatrends. That's why it's a lot of fun. So last point, tell us about the name and of course the logo. Tell people where that came from. So the name is, there is Iguazu Falls in Brazilian Argentina junction, which is sort of, I think, the prettiest waterfalls in the world and also very massive. So what we wanted to convey is the message that storage used to be really static and now it's sort of huge volumes that sort of flow immensely, coming from many different sources. If you know that, they have about 100 different rapids. And so that's sort of the source of the name. Excellent. All right, we got the content flowing wall-to-wall coverage here. They did it. That was furrier like. Furrier like, thank you, I think. Keep it right there, everybody, we'll be back. This is theCUBE, we're live from New York City. Thanks. Thank you.


Hi everyone, welcome to this talk. I'm very excited to be here to talk about how we change oil for fast running sidecar quickly and safely at Pinterest. So I'm today's mechanic. My name is Fuyuan and I'm part of the traffic team at Pinterest Infrastructure Engineering. So today we are going to start with looking at envoy at Pinterest briefly and follow that or look at the configuration rolling out story at Pinterest, the challenges we faced and the solutions we used. And at the end we'll share some best practice we applied and lessons we have learned during this journey. So at Pinterest we have been using envoy started around four years ago and we use it very widely and deeply. When user traffic come into Pinterest it firstly hit envoy, edge envoy. From there traffic get routed to our mesh, mesh envoy. And starting from there the traffic get routed to different services and it did not stop there. We also use envoy at storage layer. For example we use envoy, we use the envoy on MySQL so that we can get mutual TRS between services and MySQL. And at edge envoy we deal, we are processing millions RPS per seconds. And this is the architecture for our mesh. At the very top is a tower. Tower is the central laser control plane of service mesh. When a user land a company into the gate report Jenkins will upload the config into the central laser control plane and it will be persisted into a keeper. And behind the central laser control plane we install a agent on every host it's called beacon. Beacon and tower, between beacon and tower is a simple but very robust GRPC streaming protocol. And it's a generic config distribution protocol between them. And we leave the versioning and other complexities to the last mile. So the beacon will be the agent dealing with XCS services and they will distribute the config through XCS to envoy and to build. Sitting side by side with envoy, we have SDS sidecar and OPA agent to help envoy to do authentication and authorization. We have envoy deployed on both EC2VM and Kubernetes. It's cross-platform. We have one centralized control plane for both platforms. Compared to binary changes, config changes are more complicated. Why? Because we have thousands of clusters, some are small, some are huge. Pinterest was created 10 years ago and since then service was added gradually. So we got more and more services and every service has one or more clusters. And to make it more complicated, we give every developer an EC2 instance as a dialog box. We treat every dialog box a cluster. That is how we get thousands of clusters. And some of the clusters are small. Only one listener, one or two, maybe three upstreams. Some are huge. I just look at the largest cluster we have. It has about 300,000 lines of config. And the config dump was more than seven megabytes. On average, we roll out tens of changes every day. And we need to deploy them fast. And then it comes to the question, if a problem happened to config, how do you would cause the problem quickly?  Should we support Ruby or should we mind it forward fix? So think about this scenario.  And it's perfect. But deep in your heart, you know you are doing an oil change. And you don't want your customer to be unhappy. How do you do that? How do you do that? Oil change. So here are the pinches. We basically tackle this problem from three perspectives. The first one is configuration as code. So for configurations, we make sure they are typed, they are tested, they are versioned, and they are deployed. The second one is we emphasize strong infrastructure governance. And the third one is we use a stator config rolling out. It's safeguarded by a near real-time feedback group and a holistic health check. So configuration as code typed. How do we make the configuration typed? We use a JINDA template. All the configurations are based on a set of JINDA templates that we provide. And when the user writes their configuration, they need to compile. And configurations are materialized at compile time. And it's also versionized. When the ground truth is in Git, it keeps the version in the centralized. When Jenkins copies the configuration into the centralized control plan, it adds version there. So the configuration stored in centralized control plan is also versionized. And it's tested. We run a comprehensive set of unit tests before and after landing. So the tests are comprehensive. If we test listeners, every listener must have a valid route. Every route needs to have a valid upstream. If an upstream requires TLS, the downstream must give the correct configuration. They must match also like a port conflict. These kind of things are detected during build time. And also it is deployable. If you have a pipeline, deploy changes after APR landed. And to do that for every PR, every conflict change. So infrastructure governance from a mesh perspective is basically two questions. First one, where should the mesh configurations go? Should it be in a centralized repo? This of course has a pro and cons. Pros of a centralized repo is consistency. You get consistency. You have a quick turnaround for horizontal changes. By horizontal to horizontal changes, I mean you will make a change which applies to multiple clusters. And of course it also has counts. User experience may not be ideal. If you are a service owner, you most likely would like to have your configurations in your own repo instead of make a change to another centralized repo. Or it should see next to each service. Pros. User have better control of their config. They just need to modify that config in their repo instead of go to your repo. However, there is another big fragmentation. When your configuration, when some mesh configuration is scattered in multiple places, the build cost, think about the build cost. How do you build? How do you make sure that every company needs to be built is built? And another question is, actually more severe question is, if a critical problem is spotted, like a security bug that needs to change the config immediately, what will you do? You have hundreds of maybe hundreds of repo. What will you do? How do you fix the problem? How do you make sure that you cover everything and you are not missing anything? So, based on that, the choice we made is we use a centralized repo. Everyone checking their configuration into that centralized repo. Another whole question I will with regard to info governance is, who owns what? Mesh is big. No matter how many mesh you have, you probably have one or how many. Do you always have this problem? Who owns what? At Pinterest, we have three personas, infrastructure engine, security engine, and service owner. Each of them owns different things of the mesh, as listed here. So, how do we fit those personas into the service mesh world? Let's start with simple. There is A and there is B. And service A, talk to service B. In this case, we call service A downstream, service B upstream, and instead of treat each service A monolithic, we cut them into three pieces. While ingress, egress, and the service itself. Then, we fit each persona's responsibilities into each piece. Infrastructure engineering. This is that this persona owns the mesh infrastructure. Here example, the infrastructure engineer define well-known ports, like ingress, HGTPS port, must be on port 8443. Then, security engineering. Security engineering own TRS, own authorization, and they control both ingress and egress. Now, last service owner. Service owner, of course, owns the business logic in their service, and make routing from the egress side. However, this is the most important part. Think about yourself as the owner of service B. Another service owner wants to call your service, and you want to re-limit that service. That re-limit config is part of service A, but given by service B's owner. This scenario, in this case, makes it complicated. Like, one service owner contributes to downstream configuration. Think about that. It's the right thing to do. It's beyond those traditional definitions of service owner A and service owner B owns things of their service totally. That's not right. That's different. This is how mesh configuration should look like. With that, if you look at service as the owner of service B, from egress side, he barely has something to config. Probably just some declaration of upstreams he need to talk to. That stays rolling out. I think we must have a config that gets landed. We started pushing that config into a through a pipeline. Jinkers job keep kicking in. Started running unit tests. Although unit tests were run before PR land, however, after PR land, we still ran it because you could have a merge problem caused configuration failure. Once that is finished, the Jinkers job will literally, the pipeline will upload the configuration into tower that centralized control pool. Then it will deploy the configuration into latest stage immediately. Every config change will start a pipeline run. Every pipeline run will deploy the configuration into latest stage automatically. It takes about three minutes after config is landed, till it get activated in latest stage. After that finish, we'll see there a sender notification to the on-call engineer and a meeting for approval. If the on-call engineer will there approve this, click approve button, it will go to the next stage, which is the canary and the dev app. Those stages still activate the new configuration in those stages and listen for several minutes and keep pulling the service status. If there is no problem, it will consider the canary stage got passed and it will send another notification for approval. Once that is approved, it will go to next, it will go to the first stage. In the first stage, we do regions in parallel. So, however, we see in each region, we do availability zone after availability zone. So, every time we just deploy one availability zone. And if there is something not happened, we will stop there, investigate before it is continue rolling out. So, when there was a rollout configuration, how do we know there is a problem? So, we have a detailed problem through a near real-time feedback loop. And this is the definition of negative feedback loop from Wikipedia. I don't want to repeat, but it's basically like you take the output of your amplifier, apply some algorithm and convert the part of the output and feed it into the input. And through that, you keep tuning your system to get your ideal output. How do we apply that to our mesh? And the feedback part is basically used to detect the problem. And what problem do we detect? We detect unwanted reject conflicts. Basically, this is through XES protocol. And also, we have house check failures, like data plan for data failures in both data plan and control plan. For a data plan side, service may be unhealthy. Or control plan side, maybe no config available for that specific cluster. Or maybe mesh infrastructure is not ready. Or maybe listener is not up. Or another case is when you send out a configuration and it triggers some bug and envoy just disappeared. Then we lose clients. And the last of our check we do is version mismatch. You send out a configuration to our SA, pay envoy on this cluster, please use version 100. And then you observe some of them or all of them are actually running on an old build, which is like 99. And then you know, oh, there's a problem because it's not on the right version. So the first thing, the first failure that we did have is the XDS resource acceptance or rejection. So within XDS protocol, it's about require discover request and response. From this flow, I got the config pipeline, send a new configuration of a new version of the configuration to the tower. And the tower is sending this new version to beacon, which is the host agent. And then that host agent convert this new version to XDS response and send it to our envoy, give it to our envoy.  Hmm, I am okay with this config and I accept it. Then it will use the discovery request to act. So the new version. And then this will be aggregated in beacon. And beacon will aggregate the report back to the tower. So the pipeline will keep current tower to see, oh, is there any failure? Is there any failure? So another case is, for example, the new version contains or require a new secret. The secret, however, wasn't granted to the process of envoy. So envoy will gather the new configuration and see, oh, I need a new secret. They will ask XDS for the new secret and XDS reject the request. And envoy will report an error to beacon. And beacon will eventually send this aggregated result to tower. Tower will say, oh, okay, here, mark the cluster. See, this cluster had this problem. And it will send the error to ELO key. And at the same time, the configure pipeline will see this error and fill the deployment. And we do this cluster by cluster. So any cluster has a configuration problem will be detected and will be reflected on configuration pipeline. So another part is the holistic house check. We house check listener and we house check the configuration of the child check control plan. And for like the host agent, SDS or part agent, and also check listeners as both L7 and L4. And we implement that as a script so that each platform can invoke it easily as it does not depend on any platform. So real-time feedback. The last thing is the confidence. How does the pipeline build the confidence? It's built on top of confidence. So envoy reported to beacon every 30 seconds. Beacon reported to centralized control plan, which is the tower every 30 seconds. So in total, after one minute, you should be able to see the last result after you send out the new configuration. So starting from T plus one minute, it started building confidence. And after another minute, which is T plus two minutes, they will start, they will look at the confidence and say, oh, if I get high confidence, they will say, oh, I hope for, if this configuration will not touch 1000 clusters, and all of them has more than 90% acceptance rate, then we got enough confidence and then let's exit early. We don't have to wait. Just go, let's go just move to our next stage. Or if it did not get enough confidence, it just keep waiting, keep looking, keep looking, keep looking. And after five minutes, it will come out and it will fail. And it will contact an uncle engineer to take a look what's going on. So with regard to the visibility, since everyone uses Slack, we each send a Slack message on every deployment activity to our channel. From the right side, you can see that the mesh configuration was rolled out and there's notification got sent out. And after it finished the latest stage, it sent another notification, see, oh, please approve this change to develop and canary. And as you can see, someone clicked up Excel and it moved to prod. And it has been, once though, it takes several minutes before it's actually finished about actually 10 minutes maybe to finish prod and it sent a congratulation, see, everything was good. And on the left side, you can see that the configuration actually had a problem. And the problem detected that problem as a notification. See, there is an arrow, please investigate. And it has that ELK link so that the uncle engineer can click that link and see what's detailed, see the detailed arrow. So in summary, we have 1000 clusters and which so, so millions of RPS at the edge side. And from the change landing time to its fully activity in production, if everything goes well, it's less than 30 minutes. And we had, we just finished the V2 to V3 API and configuration migration. We had zero incident, thanks to the configuration pipeline and that for the near real time feedback group. So because we have built the control plan to be a generic resource distribution service, instead of just for XDS, other teams and other organizations are seeing value of this system and they are moving their existing service, their configuration into this mesh control plan. So that they, because they also want this per AC validation, per AC protection. So lost some best practice and lessons we learned. First, infrastructure governance is crucial. This is very important for our success. So let's admit today service mesh is still a quickly evolving world. Therefore, changes are expected most of the time. And two years ago, we have been talking about XDS V2. Last year, we talked about V3, we talked about Universal Data Plane API. And this year, if you look at XDS, your UDP is already everywhere. And because of that, we need to define clear boundary between each role, between each team and who owns what. Otherwise, you will run into fragmentation. That's gonna make your mesh unmanageable someday. And that's, I cannot emphasize this enough. And you will know. And the next one is MTLS. It's your good friend, if it's not the best. Next, we have 99 problem with our control plan, which delayed the EDS update, make sure this made certain endpoints data store. And because of that, if we did not have XDS, did not have MTLS, we would have a self-series, because the requests are routed to incorrect service. However, because we added mutual TRS, so the connections was blocked at layer four. So layer seven did not even get a chance to talk to the wrong endpoints. We did not have had a self-zero because of the bug. The only thing we saw was a slightly increased latency at the API service. Other than that, no problem. So it actually helped us with self-zero. It's not just for authentication. Another one is RTDS. RTDS is very powerful and sometimes very dangerous. So here is a sad story. We added a global layer for our control plan, for our unwind. And we saw that it would be a good idea if we were able to roll out something globally. And someday, one of our developers wanted to change something in the global entry, global layer, and he tapped in a command line. However, he forgot to quote that JSON string in a quote, quote, quote pair. And this sent a more formatted JSON to Envoy within two seconds. Every Envoy of Pinterest got this wrong value within two seconds. And sadly, there is a bug in Envoy which caused a catastrophic failure, catastrophic backtracking bug which caused Envoy out of my memory within one minute. So Envoy crashed because of OOM. And they restarted and they worked for maybe 30 seconds, then crashed again. So it crashed every minute. And it took us a lot of effort and almost 30 minutes to recover every Envoy. So this is a sad story. The lesson learned here is RTDS is powerful, but if you're not necessary, don't use a global layer. Actually, after this incident, we disabled the global layer. And it's that we did.


I am Dr. Vishwanath, consultant nephrologist and HOD in nephrology. I am working at Manipal Hospital, Bangalore. Chronic kidney disease is a staged, what we call as stages of various kidney chronic kidney disease. There are five stages, one starts with early stage and five starts with goes to very low kidney function. Stage one is where you have, though you have relatively good kidney function you may find some protein in the urine, you may find some blood in the urine, you may find some cysts in the urine where we classify them as stage one. This is where something which we can do to prevent further progression. As the stages go beyond 1, 2, 3, 4 and 5, 5 is a stage where more than 90% of kidney is damaged, what we call in medical terms as GFR. When GFR comes to less than 15 ml then it is classified as stage 5 where definitely medical management alone will not be sufficient. We need to consider doing either dialysis or kidney transplantation to replace the kidney.


A bat origin for SARS-CoV-2 has been proposed. Here, by sampling wild Rhinolophus acuminatus bats from Thailand, the authors identified a SARS-CoV-2 related coronavirus, SC2R-CoV, designated as RACCS-203, with 91.5% genome similarity to SARS-CoV-2, and show that serobtane from bats are melene pangolin neutralized SARS-CoV-2. This article was authored by Superporn Watraplucidae, Chi-Wa-Tan, Patra Paul Manin, and others.


Let's take a look at Vérignon's theorem in action. In this case, we have a block that's sitting on some sort of surface. And that block has a weight that's holding it to that surface. And then we're going to apply a force over here on the left. Force that's pushing up a little bit and pushing to the right a little bit. And the question we want to ask is, is the block going to overturn? We're going to assume there's some sort of friction on the surface. And at that moment that the block has begun to lift up, there is a reaction force on that lower right-hand corner, a reaction force in the lower right-hand corner there. But we want to know whether or not the block will overturn. And balancing moments or seeing what kind of moment is around that point, point C, will determine whether or not the block will turn. Actually, we could take the moment about any point, but we're going to keep this simple. We're going to consider the moment around point C, because then we do not have to know what the reaction force at C is, because those will go through that point and will cannot contribute to the moment. So let's begin this by setting a basis. And in this case, the easiest basis is to go ahead and establish a coordinate system where we have vertical and horizontal components. And we're going to go ahead and consider a positive moment to be in the clockwise direction. Now that we've set a basis, let's go ahead and consider the various forces we have in terms of their components in that basis. So if you look over here, let's go ahead and call this force on the right, the force on the right side here, FA, force A. And we'll call this weight here in the middle. We'll just go ahead and call it W. And so our components, FA is going to have two components, FAx and FAy. And we can sort of see that FA is located here in an direction that is described by a 3, 4, 5 triangle. So we see it's a 3, 4 triangle. I'm going to go ahead and I know that if the sides are 3 and 4, then the hypotenuse must have a relative length of 5. And so we can break down FAx to find out that that's the force A times the cosine of an angle. If we define this angle here, we'll call this cosine theta, cosine theta, or 3 fifths of FA. Similarly for FAy, we can recognize that as being the force times the sine of the angle. And that's going to give us 4 fifths of our overall force magnitude FA. And if we wanted to now, we can go ahead and substitute the two Newtons in for FA to figure out the values for each of these. So our component in the x direction is going to be 6 fifths of a Newton. And our component in the y direction is going to be 8 fifths of a Newton. So there are components for our force in that direction. In the case of our weight, we really only have weight in the y direction. And that's going to be the entire five Newtons. And it's pointing down. The arrow is already pointing down. So we're going to define that as being in the direction of the arrow we define. And we notice that the weight in the x direction is going to be 0. It's not going to be existing. So now we want to know what the moments are around point C. So what is the moment around C? Let's do the moments of the weight around point C. That's what I'll use the W and the C for, the moment of the weight around point C. Well, in that particular case, that's going to be equal to the value of the force, which is the weight times the moment arm. Well, what is the moment arm here? In this case, the moment arm is the perpendicular distance. Let's do that with a little dotted line here, shall we? Perpendicular distance to the line of action of that force from point C. And because weights tend to act in the center of gravity or the center of the mass, we'll assume that's halfway across the block. So that's going to be a distance of five centimeters. So our moment around WC is going to be the weight times that change in the X position, or it's going to be five newtons times five centimeters. Now the important thing is we also need to figure out the sign in this particular case to know which direction we're talking about. And if we look, we can see that if we're going around point C here, that the rotation we're going to cause by this weight around point C is going to be in our counterclockwise direction. So we're going to say that that's a negative value. So negative five newtons times five centimeters or negative 25 newton centimeters. That's going to be the moment caused by the weight. Now let's consider the moment caused by the force. We'll say that's moment caused by the force at point A around point C. And that's going to be two pieces. This is where we're going to go ahead and use Varen-Johne's theorem. In this case, we have the Y component. Let me draw it over here on the right. We have the force in the Y direction acting vertically. And we have the force in the X direction acting horizontally. And we're going to consider each of them separately relative to point C. So we need to figure out how much the Y force is displaced in the X direction. So we have the force AY displaced in the X direction. And we have the force FAX displaced in the Y direction. Now the important point here is to figure out which direction each of these is behaving. And you'll notice in the case of FAY around point C, it's pushing it in a clockwise direction. Similarly, FAX acting around point C is also pushing in a clockwise direction. So for both of these, we can define these as being positive moment values. Let's go ahead and substitute in the values that we have. We see that we have 6 fifths of a Newton for FAY times, well, what's delta X? Delta X in this case is the width of the entire block, which is given to us as 10 centimeters. And delta Y is the height of the block, which is 20 centimeters. So did you catch the error here? It's an easy mistake because you're reversing the components. But in this particular case, we've made a mistake of writing down the value for FAY and the place of FAX and the value for FAX and the place of FAY. So in this case, the 6 fifth Newton should be 8 fifths. And the 8 fifth Newton should be 6 fifths. And then when you finish solving the problem, your final answer is actually 40 Newton centimeters and not 44 Newton centimeters. If we do these calculations, we get cancelation here. We get 12 Newton centimeters plus 32 Newton centimeters for a total of 44 Newton centimeters in the positive direction. Well, the sum of the moments around point C is just those two things added together. 44 Newton centimeters and the negative 25 Newton centimeters. Subtracting those two, because the second one is negative, gives us a value of 19 Newton centimeters. And notice we've defined positive as being in a clockwise direction. So this means with this set of forces, the block will begin to rotate clockwise. If the block had a greater weight, let's say, for example, the block instead of having a weight of 5 Newtons had a weight of 10 Newtons, then this value here would have been twice as much or negative 15 Newton centimeters. And notice 44 minus 50 would be negative 6. That means that the block would want to rotate in a counterclockwise direction or it would push itself back down on the table, and then there would be additional normal forces holding it up. That's our example of Vérignon's theorem in action.


Well, first of all, thank you for the invitation. I hope everybody, then we can have some questions at the end. We're going to do our best to be on time to make sure that you have all the information possible. And then we can, of course, follow up with the questions. So basically, the presentation is going to be myself and Leandro. I'm Gaston Wright, the Chancellor's Director in the Southern Corn, and Leandro is the Chancellor's Director for campaigns in the Southern Corn as well. And we want to talk to you briefly about a project we carried out in Argentina last year. Just to put you in context, last year we have general elections in Argentina at all levels, presidential, municipal, governors, representatives in both the House and the Senate. And the reason why we wanted to carry out this project is because in the past, I would say, in the three previous election processes, we have seen a substantial growth in traffic on the platform between 30% to 35% of growth in terms of traffic. And it was very difficult for us to make sure that we were driving that traffic to content created by users into a specific landing page where we were able to showcase all the petitions that were targeted to candidates for the election process plus the decision makers with the capacity to respond to petitions. So the objective of this project was, as this slide says, give a space for candidates to engage with citizen-led petitions. This is just how the platform looked like. Very simple showing the same sort of layout of petitions that we have on the regular Chanchradorc platform, but now coupled and everything into a single movement called Elections Argentina. And then the responses of decision makers also being very visible, which is something that in Chanchradorc, as the traditional platform, you have to go to the petition to see if the petition has any responses. Here what we wanted is to showcase all the petitions in a single space. And that's we have the tab on the landing page that says responses. And then in the landing page, we're also able to see all the petitions, all the signatures aggregated, and all the traffic and all the interactions happening. We want to give you some metrics, because I think this is important for you in order to put in context why this has been so successful for us in terms of doing something very different. We did this with the support from Luminate. It was a bet because we have never done this in the past, and Luminate decided to take the bet with us. And I think this shows that we can do this in the future, not only for elections, but any other movement with citizen lets campaign that are sort of aggregated in a single space. So Leandro, go ahead and please tell the folks about some of the impact we have had. OK, thanks Gaston. As Gaston said, this is the metrics that we always see to measure the online impact of the platform. Well, first, the number of petitions. This shows us if the people is using the platform for petitioning the authorities, 200, more than 200 petitions were created and specifically asking for public policy, laws, general changing, targeting candidates in the context of the election. To give you an idea, between 150 and 200 petitions are created on the platform weekly. Well, signatures is another metric that we always use. We got almost 8 million signatures in this movement. We have in general and historically in the platform like 1.2 million signatures per month. As you can see in the chart, there are two spikes during the first was during the official launching of the electoral campaign. In August, we have the primary election. So there is another spike there. For example, in June, we got more than 3 million signatures. This is a lot of signatures. The other one is unique visitors. That is almost like 3 million unique visitors in the platform, which means like 8.7% of the official eligible voters in Argentina. This is something that we always show to the politician and media, because signatures also means voters. We got like 800,000 new users. That means people singing a petition for the first time in Argentina. To give you an idea, we get like 250,000 signatures monthly, historically. And as Gaston said, the idea was to have responses and 86 responses of politicians talking directly to citizens in the context of the election. The total of responses in 2019 was 146 responses. So it shows that the politician took advantage of the opportunity to respond in the context of the election. The next one is victories. Victory means that in this context was like 19 citizens that got a positive, responsive, an action from the authorities in the context of the election. Gaston? Can you hear me? You were in mute, Gaston. Oh, OK, perfect. Yeah. So I want to talk to you now about the most signed petition. Can you see the screen, right? Yes, I think you can. This is a very interesting petition, because it is a petition about clean slate. So basically, a super user in Argentina created a petition focusing on one of the specific themes of the campaign in Argentina, which was issues around corruption. The petition got 345,000 signatures. And one of the things that we were extremely surprised is the level of engagement of candidates and decision makers in terms of answering this petition. So the petition was basically asking the Congress to put on the agenda of passing a law similar to a law that exists in Brazil, where citizens in Argentina that have any sort of issues with corruption in the past with the judicial system won't be able to participate on the electoral process. The petition got so much attention in the media that not only we were able to get 16 decision makers answering the petition, basically saying what they were doing in the Congress in order to move forward with the petition, but also the campaign reached the Congress with two petition deliveries. So this is just a petition delivery. And here you can see a lot of people in this photo. These are a combination of journalists, the petition starter, who is there, the bold guy, similar to me. He's a petition starter. Then we have senators. We have judges. We have journalists.  And also the person in the middle of the petition behind the banner is the president at that point of the Commission for Constitutional Issues. The petition reached the point of approval in the commission. The commission approved the passing of the law. And then it was stopped in the house and then put on hold until the next year. So now the law is at the stage where it is still being negotiated among the political parties. Now I want to move a little bit more into how we engage decision makers, which I think there are a couple of very interesting things to tell you. So basically what we develop is a tool that it's called a decision maker profile. So these are, for example, three important candidates in Argentina at three different levels. One is a governor. Another one is a candidate for president for a left-wing party. And then the other one is a counselor for a relatively mid-sized city. So basically the way it works, and then you will see that later on, is that we develop this functionality where this profile, which is a verified profile similar to the Twitter verified profile, allows the decision makers that are targeted to specific petitions on the elections movement to get in touch directly with the signers by a system that allows them to send massive messages to the signers. You will see that later on, but the proposal is very attractive. And the fact that we were launching this at the same time of the electoral process, it was very interesting for them as a way of doing campaigning, but also as a way of creating this new model of digital accountability. So in order to do that and to engage with decision makers, we have a two-fold strategy. The first one was something that we call high-touch engagement with decision makers and their communication teams. So we carry out several activities. One was that before the primaries and during the primaries, we invited to the change of their office consultants and people working in the comms teams for the candidates to better understand how the decision maker profile work vis-à-vis the petitions that we were putting on the elections movement. That helped get a better understanding of the public, also answer a lot of questions, and making sure that we were creating some sort of a connection with them and showing examples. Also, it was critical to travel across Argentina, going to the most important provinces, the most important electoral districts. So the team of Change.org, here, Leandro and two of the campaigners visited the main electoral districts to engage with decision makers at the very local level, and that's the reason why we have a high number of very local decision makers that were responding very local petitions. And also media. Media was a very, very important factor. So not only we coupled these trips with meetings, 101 meetings with comms teams and decision makers and candidates, but also we took the opportunity to show the local media content created by Change.org users in those specific provinces that were targeting candidates that people know at the local level. So that's a very, very successful strategy to the point that we got 189 media hits talking about several petitions on the platform in different media outlets at the local level. Leandro, if you can talk a little bit about the digital outreach strategy. Yes, thank you. So after several meetings, we realized that WhatsApp and Twitter are the most effective channel to get in touch and work with politicians and their comms teams. So trust is also important to work with them. So as you see before, we traveled to the main electoral district to have one-on-one meetings. There is something very important, like before a meeting or a phone call with a politician or an advisor, we researched their profile. So we asked ourselves that what are their particular interests? What projects do they have? What commission do they take part in the Congress? We see their Twitter or Facebook or Instagram to see what do they like to talk about. So another and very important thing is to make some professional presentation for them. I think that data is the key. Sorry. So yes, data is the key. So we show them users of change.org in their district. The percentage of the voters participate in change in their provinces or cities. We show them a lot of charts, like for example, the top five of topics that people like to participate in change. Why voters are participating in change in their district. I think that this is very, very important for them. The last thing is that we show the opportunity to respond. We show them that it is easy that there are trolls in the platform. No haters. It is real people that participate in change. It is safe. One of the most important things is that it is free. It is a free tool because they always ask what is the price of the tool. We give them an easy example to start. A non-controversial petition, something very easy to respond. We give them support with material guides, presentation. We show them that they contact very easily via WhatsApp or phone call that we are very open for questions. Finally, we said that there are many politicians taking advantage of the tool. Why don't you? This is, for example, one of the... Can you hear me guys? Yes. This is one example here. This is a reply of the city of Buenos Aires mayor. This is how it looks like in the platform. Then all the 45,000 people received this response on their inbox. Then people can comment on the responses, which creates a huge engagement with the users. Just to give you an idea, the open rate of these emails sent by decision makers is on average around 34-37%. People are eager to see these emails from decision makers. Then I want to do very quickly some metrics around revenue. This Chanchador is fully funded by individual donors. We were able to use the platform as a way of engaging donors. 962 monthly donors acquired since March on the specific landing page of petitions around the election process. That totals around $50,000 in donations in a period of 12 months. It is more because the lifespan of these donors is longer. This is a significant amount of money considering our annual budget in Argentina. 161 petitions were promoted. 106 petitions generated recurring donors. That is 45% of the petitions were able to engage donors. There are monthly donors, which is a really good number for us. That's pretty much it. I'm sure you will have some questions. We're under the tyranny of time, but I think it's great. We'll follow up later on and you have our emails there. Thank you, guys.