Good morning. Good morning. Good afternoon. Good evening, folks. Welcome to this webinar. So just a quick introduction to myself. I'm the VP of engineering here at Harness, and I sort of helped them build many parts of the software delivery platform. Prior to this, I spent most of my career building infrastructure, both at VMware and Nutanix. So I was part of the team that actually built virtualization at VMware, and we sort of took that a notch above at Nutanix. But today, we are going to talk about engineering efficiency at scale, which is what do you need to look at when you really want to achieve your business objectives as an engineering organization? And how do you do it at scale? How does Dora metrics fit into this? What else do you need to look into this? So one thing I want to straight away put out is this. I want to make this interactive. So please feel free to ask questions at any point in time by posting in the Q&A box. And after every couple of slides, I'll sort of take a look and see if I can live answer those questions. Okay. Great. So let's get started. So straight away, what are the Dora metrics? And why do we care about it and what are the caveats you really need to think about? So the Dora metrics really just tell you what is your ability to ship change or set of changes to your customer and how do you do it without breaking things? That's what they really try to help you measure. And if you do it to sort of help you highlight what are the problems.  And so that's something we will touch upon and everywhere. The one other thing a lot of people miss the Dora metrics is that this just does not apply to your services that you're hosting. This actually applies to your tool stack as well, specifically your DevOps tool stack. Because if you do not have the ability to make changes quickly and in a reliable manner, you pretty much are it's as bad as your services not meeting the Dora metrics as well. The other thing I'll also point out is excellent tooling is very important to again do very well with respect to Dora metrics. But culture is also really important. And what you need to do is you need to use your tooling to sort of embed the culture into it. And in fact, I'll show you guys a few examples of how we do it at harness. So that gives you more insights into this process. So I think most of you should be familiar with Dora metrics. If not, I will just go over this fairly quickly here on the slide. So there's four key Dora metrics. The first is deployment frequency. This sort of informs someone what is basically their ability to sort of ship code on and what frequency can they do that. Okay. So as you can see, the top organization sort of can do it on demand any number of times a day. And for other organizations, it varies between like once per day to like, maybe once every few months, right? Now, just because you can doesn't mean you keep doing multiple deployments every day. Particularly for this metric, it really should be driven by your business needs. What are your customers asking for? What is the right thing for your business? That's what determines this. Okay. Just doing multiple deployments a day and sort of pushing changes that your customers don't need is not necessarily the right thing for a lot of people. Then there is the question of lead time for changes. How long does it take for you to basically go from committing code to putting it in production? What's the amount of time it takes for that? And this is exactly where tooling is extremely important. Are you efficient in your tooling? Are they available? And if that part is not working, I think this particular metric will start lagging. Then there is the time to restore service. If something were to go wrong, how long would it take for you to restore the service? As you know, in the modern SaaS world especially, we're all striving to be at least three to four nights. In the least, the good organizations are at six nights. And the only way you can achieve that is your downtime is fairly low. You have to pretty much be in the elite section of how we measure this in order for you to actually meet anything above four nights. And finally, there's change failure rate. How often do your deployments pay? This is not, in my opinion, of course, it should be reasonable. Again, there's no need to really aim for the top elite status here. The reason being, look, catching failures early is a good thing versus basically putting it in production and then realizing it's something as long. So I think what needs to be more encouraged is the ability to catch them rather than basically slowing down to a point where there's no failures, but then you're impacting your business goals. So the balance is really important. So let's keep moving on. Okay. So let's talk a little bit about how you bake this whole process into your tooling. How do you make this part of your DNA? And I think this is an exercise we went through ourselves at Harness. We really wanted to make sure that quality, security, and the ability to verify that our deployments are working, be baked into our pipelines. Not only did we want to bake them into our pipelines, we wanted to mandate that there be no pipelines without these steps. So first, let's look at where they fit in. For example, if you look at the left-hand side of the slide, where we describe the continuous integration process, of course, you have the build-in test, and then you generate artifacts as a result of it. But really important is basically the quality and security scanning, especially static scan. We incorporated the steps to make sure that every PR that is coming through, we effectively have to pass a quality and security. Otherwise, we don't basically generate artifacts. Let's assume it passes and then an artifact is generated. As part of the deployment stage, now we want to make sure the artifact generated is actually secure, followed by some sort of provisioning and release strategy. Now, there's many types of release strategies you can follow, the classic being rolling or canary or blueberry, but there's now a new way also of deploying a code, which is important to, of course, you need the artifacts to go to your production environment or your test environment or pre-prod, but it also is there's another way to roll out your feature, which is to a feature flag. So now once you put your artifacts there, you can decide how you're going to roll out your feature to your customers. You could roll it out to a smaller segment based on geography or you can roll it out to a predetermined percentage of users.  So the only way you can really test something is in production. So what you do before going to production is that you make sure that you do the basic sanity testing, but then the feature itself gets tested in production. Finally, you will do a task security scan, again, most likely a staging or a pre-prod environment before heading to production. And the last thing, and this is really important, is what we call deployment verification. Okay, this is something we use internally, which is we monitor some key metrics. Let me give you an example, page like pledge your time for some of our apps. And what we do is that the minute you start doing the deployment, let's say you rolled out your artifacts to 20% of your deployment infrastructure. And we start measuring these metrics before and after the deployment and specifically to the 20% that actually changed. And let's say if your page load times are higher than they were before, clearly that's a right fly. That means we initiate an automatic rollback based on that. If things look great, we automatically roll forward and the percentage of deployment keeps increasing until it's deployed to every node in your infrastructure. That makes sense. Did any questions folks at this point before I head further? Because we're going to get a little deeper in this. All right, let's keep going. Now, all this is great, right? And I think, I would say a lot of companies actually figure out how to do this at a smaller scale. Like when you're like, you know, 30 people company or 50 people company is fairly easy. And that's the same journey we went through at Harness. We basically in the last two years, three years, we went from like basically 50 people to 500 people. And but the key thing is how do you do all this at scale? What do you need to care about at scale? And by the way, this is the important part of all the software engineering organizations I've been part of, almost nobody does this. So it's really important that, you know, we again look at it, understand what the modern practices are and also think about what matters when you're doing a software delivery at scale, right? One is the number one thing for any software organization is velocity, right? How do you make sure you keep your velocity and without even at a very large scale, right? And as probably anybody in a reasonably sized organization knows that organizations load up significantly as they grow, right? So how do you keep that? Second is quality, okay? You as you're onboarding new people into the company, not everybody might be aware of what breaks things, right? What breaks things, okay? And so we really need to look at it and make sure that everybody knows how things work. And also you sort of use that's where governance comes in, which is you need to make sure that these, the quality gates or whatever other things you care about are part of your pipelines and hard coded in there so that nobody can override them, right? So you need this guardrails for people to not fall off and sort of do something that affects your quality or availability, right? Finally, you need to do all this extremely efficient. So it's great that now you have, you know, now you've sort of figured out how to do your pipelines, but what if it costs so much that the businesses, you know, it's impacting how much what your profit margins are, right? You really need to make sure that you're optimal in how you're doing this and how do you measure that? That's also very important, okay? So there's a question on Q&A from Shafali. Let me take a look. When you're implementing at scale, what are the key metrics you start with versus enabling and showing everything at once? Okay. So I think, I'm not sure I completely understood the question, but really what it comes down to is the metrics are all, they're always going to be there, right? But the key ones you really want to start with is exactly the Dora metrics. That's the basic ones you want to really start with, right? And that's why those are the top ones you need to look at. The other ones I would start adding are like, for example, the efficiency metrics. That's very extremely important as well. So it's great that you have all the availability and whatever else you need, but what if it's costing you a lot? What if it's, it makes your business unviable, right? It's extremely important you look at those as well. If that answers the question, if there's a follow up, please put it in the Q&A box, right? So let's talk of value stream management a little bit here. So what does this mean? And how does this differ from the Dora metrics you just saw? Okay, what Dora metrics really helps you with is understand whether you have the ability to ship code quickly. And can you do it with a reasonable quality, right? What it does not help you understand is whether you are achieving your business objectives. Business objectives are typically defined by OKRs, right? I think some people use KPIs, but I think OKRs is a new gold standard, in my opinion, right? And really, there's different types of OKRs, right? There's product related OKRs, which is, you know, for example, you might be wanting to ship a new product, or you won't be wanting to provide a new service, right? That's usually defined by one or more OKRs. Then there's people related OKRs. There's something like a lot of organizations ignore, but at scale, it's extremely important.  Is your team happy with the work they're doing? Are they growing in their careers? How do you measure all of this? Extremely important, right? Then there is quality. How are your customers perceiving the quality of your product or service, right? What's your uptime mean like? What's your availability being like, right? How long do you take for things to get restored if something breaks? Okay, then there is cost OKRs, which is, you know, the budget for your engineering org and the associated infrastructure and whatever else is sort of fixed, right? It's a percentage of what your company can afford, right? Or how much money it has or is willing to spend reinvesting in the business. So you need to know whether you're fitting into that budget or how you would fit into it. Finally, there's the compliance, which is, depending on the industry, there's a lot of things you need to take care of. For example, if you're selling to the feds, you need to be fed when I'm compliant. If you're in the medicine business, you need to be HIPAA compliant. If you're operating in Europe, you need to be GDPR compliant. How do you make sure you're not falling, you know, you're not breaking from that norm and sort of not being able to achieve this? Okay, so these are all different OKRs that get defined. Okay, the most important thing for people to achieve these OKRs is that you need to reduce friction for your engineering team in order to help them deliver value to customers. This is absolutely the number one thing that you need to take care of. Okay, and how do you do that? And I have some key takeaways here and I'll actually dive into each one. Number one, your tooling should always work. This is a top problem I've noticed even in my previous companies, engineers get extremely frustrated and tooling does not work, right? It affects their efficiency, it sort of undermines what the mission of the organization is. And more importantly, it really starts taking a toll on their morale in terms of their ability to effectively deliver, right? Second is removing efficiencies. There are some obvious ones. There are not some not so obvious ones. I'll actually walk through a couple of examples in the next few slides, right? Third, measure and look for bottlenecks. Okay, if you measure, you will always find the bottlenecks. If you don't, you won't know what is wrong, right? It's very important you do that. And finally, I already talked about this people-related metrics. Always watch out to make sure that people in your organization are happy. All right, let's talk a little bit about tooling should always work, right? So so there's a couple of examples here, by the way. We will talk about which is this is the journey we went through at Harness, right? Number one was we were using Jenkins for Harness CI. And I'll actually, in a second, talk about the issues we had with Jenkins and why had we had to move to another solution, right? The second was also the custom feature flag solution we were using, which was pretty rudimentary to we had to actually use, you know, again, a production grade, really enterprise class feature flag solution and how that impacted us as well. These are both big decisions.  And as you will see in some of the metrics, I showcase later. First, what was broken with Jenkins? Okay, there were quite a few things. Let me highlight the top things. Number one thing was difficulties in troubleshooting. When something went wrong with Jenkins, we needed that special team we had to jump in and really figure it out. It's not like any developer could jump in there and figure out what was going on. That was very, so that doesn't scale. That means that you have to grow this organization that specifically takes care of your Jenkins as your team grows, right? And that's basically means you're sort of linearly adding resources to it, which is not very efficient. Okay, the maintenance warhead was high. The team size dealing with this was fairly reasonable, right? It was a significant percentage of our engineering. But that I mean, it's still in single digits, but it's significant in the sense that it's not directly adding value to our customers. Okay, that was that. And finally, there's, you know, the best cycles were really long. The test cycles were long. There were no real obvious ways of optimizing in it, right? And really importantly, also was that governance was a big deal. We just could not mandate every pipeline had to have all these steps. We could not mandate approval stages properly. And so it just basically sort of, you know, forced us to, you know, basically be looking at it manually every single day versus hoping that the tooling would help us automate some of these best practices. Okay, so by moving to Harness CI, which is the enterprise product we built ourselves, and we actually shipped this to others, we actually sort of figured, you know, overcame many of these issues. Okay, let's talk a little bit about what was broken with our custom feature flag solution. So this is another interesting example. We had our own custom feature flags and actually work pretty well, I would say it'll be about 75 people, right? Because we knew exactly who had access to it. It was just two or three people. So if you needed to know, hey, which if this customer has access to this particular feature, you just send that person an email or a Slack message and that person will say, let me take a look. And if it turns out it's, you know, if they're past their bedtime, maybe just wait for a few hours, and they'll respond in the morning, right? The minute we started growing to five products and 200 people just started breaking, right? Now we were too dependent on one or two people to do this. And then we overreacted to it and give access to a lot more people to do this. But then we didn't have proper, you know, our back controlling who could do what. And so we released features that should not have been released or we were struggling with figuring out who had access to what, right? And basically the right people didn't have the right visibility or the right power, right? Finally, we decided that, you know, we have to solve this problem for ourselves and everybody. So we actually sort of built our feature flags product and addressed a lot of these issues. And also as the benefit, side benefit of this was also that, you know, we actually could follow complex workflows for actually releasing a feature, not just basically turn it on or off, right? You could actually do a rollout, gradual rollout, you could figure out exactly the geography, you could roll this out to what a specific user or whatever it be. I'll pause here for any other questions, if there's any. For a second or two, and then we can move. Okay, all right. Let's, there it is. How do we get visibility into all the feature flags that would be excellent question, right? So this is just, you know, I don't want to advertise a specific product or so. But if you look at some of the commercial offerings or feature flags, what they do is they have SDKs, which help you publish the specific feature flags you're using. And also you can go to the GUI and really look at the list of these, the features that are all present and who it has been released, right? And the thing is, the most important thing is you can control who sees this. And you can also sort of control which feature flags, who has the power to change certain feature flags, right? And also who has the power to roll this further or roll this back and things like that. Okay, I hope that answers the question. Yeah, please type any follow on questions and we'll take it in a second there. Right. So let's talk a little bit of removing inefficiency. And here's a couple of examples. Okay. Okay, there's another anonymous identity that has a question, do Kubernetes based system need feature flags? Absolutely. Everybody needs feature flags. In fact, Kubernetes is just infrastructure. Feature flags is what goes into your application, right? For example, let's take something really basic. Let me think of a good example. Let's say you're talking of TurboTax. Okay, let's say they roll out a new feature that sort of helps you, sort of helps you plan your retirement better, right? Kubernetes cannot help with that, right? Well, what you need to think about is your users and how you're going to roll out features to your users, then who has control over them. Okay, that makes sense. Right now, let's see, there's another follow up question. Can you build multiple images from each client and deploy in their tenants? Okay, so I'm not sure what that question actually means. So, if you can elaborate whether you're talking about, if you can give a lot of more context on this, maybe I can help answer this question. Okay. Thank you. We'll take it in a second, right? Let me cover this slide. So, the time to, let's talk a little bit about the migration to Bazel that we had to do, right? So we actually used to use Maven for our test and build systems. And if you really look, this is an actual, you know, graph of all that, how long it actually took for us to run all of our different types of tests. And these are taking data points taken once every month or a four month period, right? And if you really look at the time it took for most of our tests, tests almost doubled or tripled in each of these cases, right? And the reason for that was our team grew a lot during that period. And also, you know, we were adding new services and new tests associated with it. And one of the things with Maven is you can't pick and choose. When you're running like in a Mono repo, you can't pick and choose what builds and tests you were specifically running for each developer, right? And so what we did was by moving to Bazel, we were sort of forced to create a dependency graph. And people could just, when they make code changes, we were only building the necessary parts of it using a global cache for everything else. And also the tests were associated with the specific component that you were building. Okay, that's great. But that's not sufficient. What if you just made like, you know, five line change, which only really affects one test even within the specific service, right? And for each of our services, the tests take anywhere between 10 to 15 minutes, right? How do you do that? And for that, what we did is we used something called test intelligence. And let me sort of walk you guys through how this fits into the whole process. Now, this is how a typical PR process looks like, right? A developer basically goes, creates a local working branch, creates a pull request on it, right? Sorry, that starts coding and then creates a pull request on it finally goes through the review process. When they're going through this review process, what they do is, obviously, they have the changes, they send it for review, they get feedback, they make changes, they go to build again, and then a test cycle again, and then submit the review again. And they might get more feedback, again, code changes, build and test. So what we found out was, for harness, we do about 700 odd PRs per month, pull request per month. And for each PR, we actually do 3.5 PR checks per merge, which is, if you look at the cycle of code changes, build and test, we repeat that about 3.5 times per each PR. And so that resulted in about 2.5,000 PR checks a month, right? And basically, the thing, what we're doing with test intelligence, let me walk through that in a little bit in detail here. So what we do here is we instrument, dynamically instrument our code to figure out what is the exact set of tests that impact the specific change you made to your code. Like, for example, if you change only one line of code and there's only one test that covers that, we will be able to figure that out, right? So if you had like 100 unit tests, we would only run that one instead of the 100. So what we found out was, once we started using this module, what we call test intelligence, we found out that the number of test runs saving with TI, we were saving about 35% time in the amount of tests we had, we could avoid running with test intelligence, right? And if you let's look at the little bit about the math, which means that, if the average test time without test intelligence was 43 minutes, right? And if you save 35% time, what we found out based on 35% saving was that we were saving 3.5% years in a calendar year with test intelligence. Okay, that makes sense. Okay, let me try and answer this question here. There's a question, Kubernetes systems are deployed based on container images and let's say they're deployed in multi-tenancy with their isolated environments. Okay, can you build an image specific to a customer requiring only modules? They're supposed to have instead of a single system with massive feature flags and figuring out what features are deployed for each client. Absolutely. I think what this really comes down to is, yes, if you're doing more of an on-prem solution, this seems like you could make it work. But if you're a SaaS solution and it's sort of shared between tens of customers, which is what a lot of people do, it sort of makes sense to basically use feature flags, right? Thanks for clarifying your previous question. And also, I really think that you should plan for scale. Like what's being described here to use Kubernetes and images to do this isolation, I think works better on a smaller scale. But really, ultimately, you have managing the features is the bigger problem, not how you achieve it, so you could technically use a different mechanism, but how you manage those feature flags on top is the most important part. And if you basically, by doing it at the infrastructure level or the image level, I would say it just becomes really, it actually, I would say at scale becomes extremely complicated. You really have to know what's working. And if you have to debug, it becomes really, really hard versus, yes, your code might look a little more clunky with feature flag SDKs built into it. But if you figure out a good mechanism to do it or a good system to do it, it becomes much more readable. And also, I think the amount of time you'll spend debugging, you know, anything more than 100 users will reduce dramatically. Thanks for the question. That's a great question. So let's talk a little bit about how we actually measure and look for bottlenecks as well. So these are actual real examples of some of the metrics we look at at harness. So just look at our deployment frequency. This is from the past week. This pretty much, I would say the same, even if you go back a few months. On some days, we do over 100 plus deployments. Again, as I said, you really need to look at your business function and decide what is the deployment frequency you need to have. The reason we have so many deployments is we have a number of services, we have a number of products that you know, we ship and they're all deployed independently. And that basically is what highlights, right? But if you look at the ability to also change like some days, it's lower, some days, it's higher. It's just the most important thing is do you have the ability to do this? Okay, that's part one. The second thing here is that if you see October 16, 17, that happened to be the weekend, so nothing much there. If you look at 15th, that's thanks to some of our awesome execs at Harness. We actually have the second Friday off every month. And this is in addition to other holidays, right? And so it's just beautiful that we get the day off. And so our deployment frequency was much lower that day, but it's still surprising that we have 10 plus deployments even on an off day. So this is something I think we're extremely proud of on how smoothly this part works for our organization. Now actually, let's look at something that probably the number is not where you think it should be, the change failure. If you look, we are at 25%. Typically, when you talk of an elite organization, you're talking less than 15%. So it's really important you have dashboards like this to figure out exactly where the problems are. So if somebody told me you have a 25% median failure rate, the first, my first reaction is, but why? And immediately you jump into a report like this and I can see, hey, can I sort by the list of projects that actually have the highest deployment failure rate and immediately you can see where the problem is. In this case, if you see most of the projects with the highest deployment failure rate were actually test projects in our case, which is fine. It was great. And they're actually probably not even deploying to production. Okay. We were quickly able to figure this problem out and say, that's fine. I think this is something we can ignore. And like maybe for a future dashboard, we can just not put this sort of, remove these, filter these projects out so that we only look at the ones that really matter. Finally, how long does it take for you to do the deployment itself? Now this is, you're really looking for anomalies here. Like if you look at this graph, clearly we have this actually, I think two projects here that have this 24 hour thing where we really run the deployment for an extremely long period of time, like it's almost a day and then it fails. So you know that something is wrong with these two projects. But if you look at everything else and if you look at the mean duration, it's really good. It's less than 30 minutes for us to do our deployment. So immediately helps us focus on where, which projects are the problem areas can work with the team leaders and they can just go fix this themselves. Finally, we should, I talked about cost, like a few times here. And this is extremely important that everybody should pay attention to this because this is the runaway train that can derail all your projects. In our case, our logging cost was pretty high. It was increasing significantly. So I don't have this graph for more than the period here, which is for like a quarter. But basically what it was is that this had been all growing slowly over the last year. And so we looked into this. This is our logging cost and GCP. And we looked into this and we said, we have to take care of this. This is disproportionately high for what we are doing. And somewhere in August, we started working on it and you can see a trend downwards from there on and how we're addressing this. So again, to summarize, I think looking at these metrics, extremely important. This is how you know what is wrong. This is how you identify bottlenecks. And just please make sure that you're building systems that actually allow you to measure and identify these bottlenecks. So then you can do the other things I talked about. Like in our case, we moved the base of what we built, test intelligence. These are all efficiencies we gained after realizing what was wrong with our process. That concludes my presentation. I'm here to answer any questions from here on. So I think there's some good question here. Is there a good resource to better understand correlation between different metrics? Yeah, it's an extremely good question. So it depends on, again, which part you're talking about. So let me give you a couple of examples. So one is, if you look at the deployment verification part of our product, which is called continuous verification, what we really try to do is we really try to help map between the specific change that you were doing. For example, a deployment or whether you did an infrastructure related change and point out to specific failure and show you the correlation between them. That might be one way you can correlate the metrics. Typically, these are pretty hard to do exactly what is wrong. I think the key thing here is change related to specific metric not going right is possibly the thing that's the best way to correlate things versus just correlating different metrics together. Because what you're really trying to do at the end of the day is root cause. Why, yes, some metric is not where it should be for you. Hopefully that answered the question. I'll take the next question. What are you currently working on towards in terms of roadmap? Yeah, we're doing, there's a lot of stuff. I can't completely talk about everything. But I think as a company, I would basically say what we are focused on is we want to do everything in the software delivery space, which means everything from the point you write code to putting it in production and making sure it works as you expect in production. So anything in the realm of it is what we do. One of the differences between us and I would say what's out there from a competitor standpoint is that we are a deep company. We don't want to build something because it's supposed to be there. When we pick a project, we really want to make sure we are addressing really strong pain points and our offering is actually differentiated against the best in that segment. For example, if you look at continuous integration, we incorporate a test intelligence into that. If you look at feature flags, we are incorporating the end to end pipeline into that. If you look at cloud cost, we focus on Kubernetes. Nobody was doing that well when we started. So we don't want to do any shallow projects, but if that helps you answer the question. What was the biggest return on investment for harness as you looked at these metrics at scale? Where would you look first in your opinion? I think the ability to look at all the metrics I just showed especially in the end, I think that was huge. Really having those metrics, knowing how your deployment frequency was going, that was a really big deal. The second investment I would say is moving away from Jenkins was a really big deal because it really lifted the spirit of an engineering organization because we had been hearing constant pain over like I would say 18 months on how we were unable to scale and just people being extremely frustrated about that. That would be the second one I would say was a really big deal for us. Harness provides integrations with third-party services like GitLab. Yes, we do. I mean we integrate with pretty much anybody. We are a platform, but yeah, absolutely. We do. At Harness, do you have metrics you track directly against individual engineers or do you stay at the team level? So great question, Sean. So we actually do have metrics even at individual engineers, but we don't use that for day-to-day operations. The reason we don't do that is because I don't think they're that useful. It is in very rare circumstances, very useful. Let me give you examples. If you look, different engineers bring different things to the table. There are some engineers what we call are really good at design. There are some engineers that are really good at collaborating and there are some engineers who are just really good at producing code. We can't measure everybody at the same thing and some of these are not quantitative measures. They are qualitative measures. So I don't think it's really that important. I think measuring at the organization level and looking at the inefficiencies in the system is more important than measuring at the individual level if that answered the question. Okay, I think we have a few more minutes so I'm just going to hang around here if that's okay Marisa for a few more minutes to answer questions. There you go. Okay, great question here again once more. Can you use Harness with GitHub Actions and how do you deal with overlap? We actually connect very well so you can use any CI solution with our continuous delivery or continuous verification or feature flags product that works pretty well. On the other hand, you could just be using GitHub SCM and you can use our CI solution. The way we if you were to use GitHub Actions is we actually have all sorts of trigger events where you can tell us when an artifact has been generated and we can basically take it from there and help you with the rest of the department. But yes, we actually integrate really well into most SCM and other CI solutions out there. There's a question from Taha. How can we make action process and get failure of process? I'm actually not sure I got the question. Apologize for that. If you could clarify that, I would appreciate it. Okay, any other questions here or clarification to the previous question? How do you deal with rollbacks? Excellent question again. So I think the way this two things here. So one is the rollback strategy actually really depends on the app. You need to provide how you would do the rollback. But what we have developed is a system to automatically figure out whether a rollback should be initiated. So for example, I was just giving you the example of page load times. It could be any metric you care about. So we monitor those metrics over a period of time and sort of create a baseline on how your app behaves. So when you go ahead and start rolling out a new artifact or even start rolling out a new feature, we start looking at those metrics in context of when you did it and start seeing whether those metrics deviate from a well-known baseline. If they do, we automatically initiate the rollback. If they don't, we automatically initiate a roll forward. So what we can help with and what we do internally ourselves is basically that level of automation. But how you do the rollback is something like the steps you need to do the rollback is definitely depends on the app and has to be taken care of by the application owner. Yes. Okay. Thanks, Taha, for clarifying your question. Yes, absolutely. So I think you can, there's a lot of actions you can take on the CI CD pipeline at different stages and on different events. And it doesn't even need to be failure. You can just define the event in which you would like to trigger a failure response or a notification response for that matter, or an approval step for that matter. Right. You can do all this and yes, all of these integrate on Slack and you can basically act on either an approval or a failure or even a success case, whatever it be, on Slack or some of the other tools. I mean, we have pretty deep integrations with a number of other tools out there, including Jira. Yeah. So can you give more examples of key engineering metrics you can get transparency. Yeah. So I think there's a lot of metrics, right? So the thing is, there's two sides I would say, there's sort of this line, which is, hey, how's the team doing in terms of productivity? And the second is how well are they doing from the point that code has been produced to how it goes to production? And what is the quality of the code that goes? Okay. So the first case I talked about is the former case is all about the agile metrics, right? We're looking at the agile metrics. We are seeing, hey, how many tickets is the team able to take? What's the size of these tickets? We don't want to measure against different teams. That's not correct because how you size tickets really varies per team. What you can look at is the velocity of the team over time and see how they're doing because they have a certain system and within the team, you compare it to the team itself, like how they have been doing in the past, right? And so those are important metrics to see the productivity of the team, right? And then I also talked about people metrics, extremely important, just basically measure their engagement. For example, we use a survey tool, which really gives us like into these insights every month, right? So those are all really important metrics that we measure to figure out how efficient our team is and also how happy they are. Now, the second part is where we focused on today, which is once the code is generated, what does it take for it to go into production? And how much time is it taking? What are the issues we are running into? Okay, hopefully that answered your question. Okay, just waiting for some more questions. Maybe give it a few minutes. There it is. Okay, John from Jonathan, is it a good practice to assign symbolic values to each metric? For example, each for each job failure or deployment done, company lost certain money. Yeah, this is an excellent question, John. I think, and by the way, this is a pretty debated question as well. So a lot of times, I mean, let's look at it the other way, which is can we assign a dollar value for every commit that our developer does, right? And the answer, what we found to that is it's not simple because typically, if you look at the per commit basis, you cannot really figure out what is the impact because two commits together are probably worth an X more than what each commit would have been worth by themselves. So I think abstracting it a little higher, especially at like a service level or a product level helps a lot more versus going down to each commit or each failure. Okay. Again, I think failure is, in the case of failure, it's a little easier to assign it, but the dollar amount to it. But even then, I would basically say, I would basically say that the right way to do this is look at how much, what was the downtime you had in a given quarter and really associate the money lost from that point of view versus a specific failure because it's really hard. Like maybe you lost a customer just because of one failure or maybe you lost customer because you have a lot more downtime in a quarter, right? I would say the latter is more likely, which is people get frustrated when you have repeated failures versus a single failure. Okay. Another question from Taha, any AI and ML in harness? Yes, we do use AI and ML for our continuous verification product, which is the deployment verification I just talked about in the slides, right? That is how we figure out whether your metrics are sort of not following the pattern that they were following in the past. We learn and build a mathematical model using ML. So sort of compare against that to figure out whether your deployment is going well or not. Okay. Supporting programming languages? Yeah, I think, I mean, CI, we are agnostic to programming languages. So that's just, yes, we do support those. Okay. Okay. Another question, what have you seen to have made the biggest impact on your teams in your journey, building the platform and so forth? I think I just mentioned this, I think the Jenkins thing was a really big deal. I think it made a huge impact. The second thing we are seeing making an impact is also the test intelligence part of it. So even in our very first version, we are saving 35% time for our developers on average. So we are very conservative if we cannot figure out whether we can run only a specific number of tests, we just run everything. Okay. So basically, there's lots of runs where we are running everything, but the runs, we don't run everything. We really save people our team a lot of time. For example, instead of running 100 unit tests, we only run one or two and it happens quite a bit. And that's how they end up saving 35% time. So that has, in my opinion, really encouraged our engineers a lot. They just feel good about how fast they can move and not context switch every time they go through a PR check process. That's one more thing. So I would say even on the feature flags side of things, especially a product management team is extremely happy about it. They really feel that the visibility and the control they have is so much better than what they had before. From the engineering side, I would say, sure, I think that they're happy it's more systematic than what was there before. But I think it's mainly the big impact is on the product side and the customer success side. Okay, guys, let's give it one more round of questions, I guess. Okay, perfect. Looks like we are done. Awesome. Thank you so much, folks, for the awesome questions. There's one more question. Let me take this. Can we integrate multiple clouds like AWS, Azure? Yes, the answer is yes. Okay. All right. Great, guys. Thank you so much for attending the webinar. It was a pleasure to take all the wonderful questions from the team. I look forward to more webinars like this. Okay, thank you so much. Bye. Have a great day. Thank you, Srinivas, for your time today. Thank you, everyone. Just a quick reminder that this recording will be on the Linux Foundation's YouTube page later today. Okay, thanks so much and have a wonderful day, everyone.


Okay, we're back live at Hortonworks Hadoop Summit 2012. This is theCUBE, siliconangle.com's event coverage. We go out to the events, talk to the smallest people you can find, and track the signal from the noise. And this show is about Hadoop. This is about the center of big data. It's a technical, focused engineering geek developer meets business use cases. Not so much a developer conference. I'm John Furrier with siliconangle.com. I'm joined with Jeff Kelly, my co-host for today. And Todd Lipcon from Cloudera is on theCUBE again. Alumni, Benjamin, we've done number of times, five, six times we've had Cloudera folks on and just want to say to the folks out there, Cloudera, really the first company to commercialize and be funded by Venture Capital. Think almost four years ago now, about four years ago. Yeah, a little less than four years. Coming up on four years, really the first pioneers in Hadoop, the leader, clearly the market leader in today. Hortonworks, a number two coming fast up to Cloudera. Little bit different approaches, but Todd, you guys are working well with those guys. The big brouhaha, even a year ago, when Hortonworks kind of spun out of Yahoo, there's a lot of conversations, silly conversations around Cold War, who's contributing the most. But for the most part, it's been a really positive piece, it's kind of a peace treaty because you guys all know each other, right? And so the community's growing, real robust community in Apache. Everyone kind of sees the big picture. There's plenty of beach head for everybody. They all have coconut trees on them, a lot of fruit on the tree. So I want you to share with the audience your view of this conference, because we've been covering Strata, we're covering Hadoop World, that you guys used to run now, O'Reilly's going to pick that up and take that off your shoulders, which is good for your company, because you're not in the vent business, but you've seen the community grow from a kernel to now exploding, where these shows are selling out. Yeah, I think my first summit was, this is my fourth summit this time, so four years ago, we were over in Sunnyvale. I think it was 300 people, that's 320 people, and now today we're 2,100, 2,200 people. Yeah, an amazing amount of tracks, a lot of interest, new entrants into the market, into the ecosystem, and the community, right? The coding community. So what's your vibe? Tell the folks out there, what's happening at this show, why is this show different than the other ones? So I think as the event has gotten bigger, the amount of business stuff that we see in the show has definitely expanded. The first Hadoop summit I went to was basically Hadoop developers talking about their recent projects, they'd added the Hadoop, like new features in Hadoop O.18 or something like that. Now there's a lot more companies talking about what they're actually doing with Hadoop, new higher level frameworks people are building on Hadoop and new stuff where they integrate with Hadoop. That's sort of the major shift in focus I've noticed. Certainly there's still some talks about new features from the core committers, but of the six tracks, it's only one of them is really like that and the other five are morally data science vendors talking about their products. Some segmentation going on, right? Yeah, certainly, yeah.  But HDFS is your new sweet spot, we talked at H-Base conference about this, that's on YouTube. A lot of discussion around the advancements, security, so I'd like to ask you specifically what new features and developments are going on in HDFS specifically that are helping you guys get faster than near real time and all the market demand. Yes, I actually gave a talk about this at H-BaseCon, so if you were out there, look on the H-BaseCon website, there's slides and video from that. The talk was, what has HDFS done for H-Base lately, basically? So H-Base is basically our real time play, it's real time key value access, random access, very low latency. And we've added a lot to HDFS in the last year to four H-Base in particular. So let's say the two key areas that focus on one is performance, just because you need this low latency fast access, we really improve the random read performance of HDFS in particular and just really reduce the CPU overhead for a lot of operations. So that's gotten between like a 2x and 4x measured performance improvement of H-Base over the last couple of years running on HDFS. And then a high availability is the other really big one, it used to be that HDFS had a single point of failure, and this name node master node. If that node crashed, then the whole thing would kind of be down until you restarted it on a different node, perhaps. You didn't lose any data, but if you're running a real time website or something off this system, that's obviously a downtime that you didn't want to take. How about robustness of HDFS? What areas are going on there? Well, we've actually always been very robust in the sense of, we never lost data. There's very, very few documented cases of losing data on HDFS. All the ones I'm aware of have been either long since fixed bugs from like 2006 or like completely abled in the administrator error where they accidentally delete everything on their node and they delete the backup or they never cook a backup, right? So can you talk about security in HDFS? And also we just heard from David from Cloud, who Xdahu, who knows data. He's putting the analytic engines in HDFS versus pulling that out. That's a big concern. So the security policy is just a quick one. But then talk about the analytics side because that's where everyone wants. The HBase is showing great use cases of storing as a store but getting it out of HBase is what everyone wants to do. Yeah, so on the security front, so HDFS since about a year and a half ago has had Kerberos-based security. It integrates with Active Directory and all the enterprise-friendly stuff. Gladire Manager helps you set that up really easily and integrate with the enterprise systems. So that gives you basically access control to the data on HDFS. Security in HBase, since it's another layer on top, is newer. That came in CDH4, which we released just last week in GA. So that allows you to, within a table, specify different columns in that table and allow different users or groups access to those columns. You know, distinct read or write access. So that's sort of the security thing. It's a newer feature now available. In CDH4? In CDH4, it's in the upstream HBase 0.92 release. All of the CDH components, we build off the Apache open source. CDH itself is 100% Apache 2 licensed as well. There's no secret sauce in our HBase. It's the community's work and we contribute it to it quite a lot. Yeah. Analytics engine. On the analytics side, I wouldn't say there's any new major feature on the open source side in HBase for analytics yet. There's a new feature called co-processors, which allows you to essentially build extra code into the HBase servers themselves. You can think of it a little bit like stored procedures in a traditional database. So I don't think your average user is going to go out and write a co-process. That's not an open source. That's modifiable by... So this co-processor framework is open source and then you have to write, it's basically like plug-ins you can write. And once you write one of these plug-ins, it sort of hooks into the core of HBase and can do wildly varying things. It's just Java code, so you can do anything. So I don't think users are going to go out and write their co-processors tomorrow, but we're seeing companies like Webidata, for example, and Continuity, who are building their software on top of HBase. And they want to be able to really hook into the core and do useful analytic things or machine learning stuff inside the database itself. And I think they'll find this new co-processors feature pretty useful for that. We've seen interest from them. Also, I anticipate users will be using it through another vendor or through another library, which is using these lower-level components. It's kind of a distraction, not at that complexity of a way. And it'll be kind of under the covers. So you mentioned the high availability. I wanted to go back to that for a second because we hear a lot about single-point of failure and it's one of the key... We used to hear a lot of it. It's one of the key issues. Right, so can we put that to bed? Is that... Explain a little bit about HA and how that works and how you approach that issue. And again, is it a subject we won't be talking about anymore? I hope we're done with it. I'm tired of talking about it. This is the last time I'll ask you a whole... Great, great. Yeah, so we built a basically active, passive standby system. So there are two name nodes. One of them is the active name node. It takes her all the requests going through the namespace. The reason why we have a single master like that is it really simplifies the system both for operations and for the complexity of the code base rather than trying to distribute it. So it's been very, very robust. There's a few bugs that cause any kind of issues. And then we have the standby master, which is essentially keeping completely up to date with the whole namespace talking to the active master. And if the active master crashes, the standby can promote itself to become active within a matter of seconds. So there's no data unavailability. Any clients who are accessing the cluster will seamlessly fail over to the new active master. And then of course you can repair your node, you can replace the RAM, whatever went wrong on it, replace the power supply, bring it back up and fail back at your leisure, whatever you need to. So yeah, so talk about just overall, I mean, that's a key component of being enterprise-grade or enterprise-ready. Where is Hadoop on that spectrum? Is it safe for the enterprises, as they say? I mean, we have about 50% of the Fortune 50 are using CDH in production or not necessarily production, but in some sort of a serious project. So it definitely is enterprise-happy in essence. Like Fortune 50, how much more enterprise-happy. Right, right, absolutely. So you mentioned security. So I mean, what are some of the other major issues we have to tackle from a community perspective? I think the ease of use is still an issue. Originally, Hadoop was very much for the Java programmers out there who could sit down and write a bunch of Java code or write a MapReduce job and understand for one, how do I take my algorithm and make it MapReduce? Which is like not a trivial thing to do for most people. And then we saw a couple of years after MapReduce we saw Hive and Pig come out. And they made it easier for your average data scientist, sort of Python hacker kind of programmer to put together SQL queries or Pig scripts, much easier to consume, easier to write languages. And that really expanded the boundaries a lot. And I think the next wave that we've seen in the last year and continuing this year is more vendors building and then on top of these layers. So you have like a nice point and click interface. So like Talend or Tableau or Pentaho, all of these different business intelligence vendors and data visualization vendors are now integrating as another layer on top. So that expands even out to the business users. You never wrote a line of code in their life but they can get all the data that's stored in Hadoop. That's the stuff about the application and the analytics side for a minute.  Everyone else on the business side wants the data out. They want analytics. They want real time, near real time. What can you share with the folks out there that you've learned in observations or anecdotes or examples that you can share with them is ways to do that. And let's take HBase in particular. So HBase has become, as I said on Twitter last night, the holy trinity of big data. HBase, HTVS, and MapReduce. Those three things working together. And we talked about this at HBaseCon. This is a really nice configuration. Kind of working together. What advice do you give the people who say, hey, I love this. I'm going to deploy with it. Great batch collection. And we'll roll with the community on innovation. We're good for now. But what I need right now is analytics. What do they do? Is there a roadmap? Is there a playbook? I think one of the mistakes I've seen some companies make is they go tool up instead of use case down. So they say, oh, this HBase thing is really cool. Or I've heard Storm is really great. And I want to use that. And they don't think about what problem are they actually attempting to solve. I think people are much better success with Hadoop if they start with, here's a problem I have. Here's some data I'm collecting. I'd like to do more with it. And then talk to some experts in the community. Talk to Cloudera, do some reading. Take some training courses and understand, OK, well, my problem, even though I think it's real time, actually a five minute batch is good enough to be real time. It actually will be 10 times cheaper for me. And make those sort of distinctions with the right engineering trade-offs once you understand the problem. It takes me through that. They're going to call Cloudera. Say we have a problem, call Cloudera.  And you guys don't answer? I mean, so we're not a consulting shop.  On the other hand, for a new customer, if we think there's a great Hadoop use case, we do have some people who can go inside who are Hadoop experts and they've solved use cases like this before. I think our usual technique as we go in and we talk to the people proposing the use cases and we say, what are your 10 problems you think might be applicable? And we look at all of them and say, well, let's start here. This is one that we've seen be successful before. I'll start with that, get you on the right path, find one really killer use case, and then expand to the 10 or 20 use cases you might have later. We were calling H. We've seen enough of them that we can pick out the good ones. We were calling H.Base the tailored suit. Tailored up for the use case, fits great, you try to do something else where it doesn't fit very well. That being said, what would you say the pros and cons of H.Base right now? I mean, obviously it's booming, it's floating, so there's a lot of validation, but from your perspective, pros and cons right now with H.Base. So I think the pro is also it's con. H.Base is, it's not really a database, it's very, very close to the actual underlying discs and metal of the machine. So the con of that is you have to understand, like when I put data, how is that happening? How does the write ahead log work? How does that actually get recovered if there's a crash? How does it get laid out on disk in the indexing scheme? So that sounds awful, you don't really want to understand how databases work. That's a big time plumbing. Right, but then the huge pro is that when you actually understand all of this stuff, you can write incredibly efficient applications. It's like a symbol of language. Very, very, yeah, I wouldn't go quite to the level of assembly language, but. It's like machine code. It's like machine code or like writing C. And most people don't want to write against C, they want to write against a database or something. Maybe they're using C, but they're using higher level APIs. So that sounds like a big knocking against a space, but it also means that people can write applications on it. These people like WibiData, for example, or Continuity, or shops that have a bigger engineering team, and they say, I need to build a search indexing pipeline. And I've got five engineers working on this, and we can take the month it takes to understand HBase in great detail, and then they get extreme power out of it. And they get extreme, that's the exact point. It's huge investment and skill, but the upside's massive. The upside is huge. So talk about the innovations that are going to end, because obviously that's an opportunity for, when you have massive performance increases with HBase and given how early it is, there's opportunity to abstract away the complexities. So you mentioned co-processors. What else is coming around the corner to make that easy so that I could do it? So I think it's, again, we're waiting to see the next layer of library. So where MapReduce was four years ago, maybe HBase is where MapReduce was three years ago or something. There's some sort of... Early stage. Development, yeah, it's an early stage. We haven't seen a ton of libraries built on top of it yet. There's just maybe three or four I can think of. I mentioned WibiData as one of them. They basically built a higher level API where you can describe your business entities and the kind of schema on top of HBase. It maps it to these lower level constructs and gives you a REST API to put and get data and then a simpler job. And then you use JSON as well. Yeah, it's all JSON. It's all very friendly feeling to your average developer. You probably give up some of the power. Is WibiData open sourcing those libraries? No, it's not open sourcing, unfortunately. So proprietary. Yeah. But I think we'll probably see equivalent things in open source, maybe not equivalent, but the same kind of idea. They'll come out eventually. Don't forget VDP finders out there, too. Another startup, it's got the libraries. That's our startup, by the way. Right. Yeah, there's a couple open source things on GitHub. Like Sam Polara, whom you might know, used to be at Cladera Labs as well. Built a thing called HAvroBase, which stores Avro objects on top of HBase. So they're sort of like fledgling libraries that people throw around. Did Sam open source that? Yeah, that's fun. He's at Twitter now, right? Yeah, yeah. Okay, cool. All right, so next up for you, what's on your agenda for this next Geosy? HTFS is good, but what's on your roadmap? Share with the folks out there what you're working on and any kind of coordinates to get a hold of you to collaborate on code. Yeah, so right now my major project is working on the next update of CDH4. So we finished the HA feature, we did the automatic failover, as I mentioned earlier. Currently we have a dependency on an enterprise filer for that, which most of the enterprise customers we have are completely okay with. I think 95% of enterprise software does HA with a dependence on enterprise hardware like that. Some of our customers, especially startups, who are running on AWS or other cloud services, they don't have filers, they don't want to buy a filer. So the project I'm working on now is essentially a distributed system that takes the place of that filer and can redundantly store the state on multiple machines using a Paxos protocol. So as we discussed that HBaseCon SiliconANGLE spun out a new company called VDP Finder, which we're doing some stuff on HBase and you met our data scientist. It's challenging right now to work on top of HBase, so what we've found is it's great, but we need some more horsepower. So what is HBase going to come around the corner for performance? What do you see HBase going at the next level? If it was where MapReduce was a couple of years ago, what do you see happening with HBase? So in performance, we actually have a new release that was recently released, O.94, which had some pretty big performance improvements over O.92, which is the previous release. So we'll be pulling that into CDH very soon, I think. And then I think it'll never be the same as a relational database where some people think about performance as in I can do a complex query and it'll use indexes and stuff to find the right rows. HBase doesn't have indexes currently, maybe we'll get them eventually, but it's not really our sweet spot. We're more about the raw horsepower, so you do have to code a little closer to the metal to get that. Okay, so what about MongoDB and some of these other databases, where are they kind of shaking out into the ecosystem map in terms of functionality? Are they finding a home? I think basically the contrast between MongoDB and HBase, if you want to make one distinguishing difference, is that MongoDB optimizes for features and is a pretty crappy database, like it's internals are dismal, whereas HBase is a pretty good database but has very few features. So depending on what your scale is, if you have very little scale and you want something you can get going super fast, Mongo is probably way better than HBase. But if you want to run on 100 nodes, there's not a single Mongo cluster in the world that big, right? And there are upwards of 50 clusters I'm aware of that are over 100 nodes on HBase. And I just want to give you a hat tip to Cloudera because like I mentioned, we run VDP Finder, our big data project we've been running for our media businesses now going to be spun out of a separate company. We use Cloudera Manager and literally saved us six months of development time. So thanks a lot for that. And otherwise the free version. I'll pass the thanks to the other team. Yeah, I want the upgrade. Tell Mike Olsen I want the upgrade. But I want to ask you about that being said, that's a real advantage for you guys. And for like the weeby days of the world to have these libraries to accelerate the development process. So what has been the reaction of CDH4 with your customer base? You guys are talking to federal clients, financial, all the top verticals. What's been the feedback of CDH4? So we definitely had people trying out the early betas. Performance wise it's been great. We've had good feedback that it's significantly faster than the CDH3 versions they were using. We've been competitive with other distributions out there that claim to be way faster but we're actually neck and neck now, which is good. In terms of the feature set, HAA has been widely anticipated so people are very happy about that. And the name node stuff. Yeah, the HAA name node. So those are the two big and MapReduce2 was the big one? Yeah, MapReduce2 is still early at it. I consider that kind of alpha beta quality at this point. So we made the decision a few months back that we would ship MapReduce2 and give people the option of running that. But we were also continuing to ship the prior version of MapReduce, the stable version, MapReduce1. Because many people wanted to upgrade to take advantage of the new name node and the performance improvements but they didn't want a chance moving entirely to the new MapReduce framework. So I think that is the way forward. MapReduce2 is the future. But it's the future and not the now and the yesterday. So some of our customers are more conservative there. Taaz, the LeBron James of HTFS. He's a tech athlete. Thanks for coming on theCUBE again. I don't know if you're Durand or LeBron or certainly not Kevin Garnett. He's going to be leaving the Celtics. He'll be mugs-y-bugs on that kind of story. Final question. Share with the audience how they get involved. I want to, for the developers out there who want to code, who want to get involved, who want to be your contributor in the community. How they get involved. Some most developers are kind of shy. Share with them how to get involved and what to do. I think the best way to get involved is to find an itch to scratch. So essentially if you're using Kadoop already and you've seen an error message is that you don't think it's clear or you think the documentation is vague in some area.  Like, yeah. The first thing you do shouldn't be trying to add a major new feature. Just learn how the process works, get the mechanics down. And once you've done that then you can go from there really quickly to fixing big bugs or adding new features, et cetera. It's all in the open source. We do all of our development, co-develop with the community. All the design discussions are out in the open, et cetera. Todd Lipcon here inside theCUBE, sharing his knowledge. He's great. Head on theCUBE. Brown alum. Yep. So put a plug in for Brown. Computer science program. Great to have you on theCUBE. We'll be right back with Arun Murthy, the co-founder of OrtonWorks. Next, another tech athlete. We'll be right back after this short break. Thanks.


Imi, tina kia koutou. Ka tāi mai, anonga topi to te ao, kia koutou o ku whānau no te ropū kawa kawa o koutou no piri piri me koutou ngā whānau hou no kopa kopa kopa kaiti mihi atu kia koutou. Anon. Wau jar koutyu j하기 i profesionis ni m′ки i di iaart. Ano mhera. Josj al grei nenau bee kia i sainu, rangat pa biazikt kpie blokchainuotto anulim pili panpo to blokchainu harma Elizabeth הכiboto kai i aunga a burning aur, te huñ啊 kab sta Shadow raha i ā dotia ndat aunga tri如 te aaakamsa biazer cakro betis o dim le wapol ata valwitchya chapa gapada kannstu pilipson I think one of the key things to talk about is a bit about the journey which was this time last year I got up in front of our whānau and said I want to create an indigenous cryptocurrency called Indigicoin. I have to mihi to Aaron McDonald because I always say it was the trip between Waikū back to Auckland city where I said to the brother, hey look I really want us as Māori to start to reclaim our money situation, our economic system and also be part of this blockchain journey in a way where we're not far, far behind. So if you can imagine blockchain and what it seems to be or says nothing, I went on a big, big journey and going down a whole bunch of rabbit holes. Which is interesting because a couple of weeks ago we then won the BlockHack hackathon and I say it's interesting because despite the journey that we went on and I started off with Indigicoin we actually landed where we should and that is Whakapapa. Whakapapa is important because that is our genealogy and I have this beautiful marae Waiwhetu up because these are the repositories of our knowledge. These are the places where our people share our information which is primarily orally based inside of our carvings and our artwork but also I met a beautiful sister called Mikayla Jade from Australia who said actually indigenous people have been doing decentralized information sharing since way back and this is a picture of Tasmania and if you see these little squares, these little blocks, these are pieces of information that each tribe, tribal person held and every year they would come back together and have their singing festivals and in those processes they would bring together as a collective their knowledge and their information. So I want to say actually we can lay claim to the fact that we were the OG inventors of blockchain. But in saying that what is the problem that we're facing, there are three things. One, traditional knowledge is at risk of being lost and forgotten. Our knowledge of Whakapapa is so sacred and therefore people are feeling comfortable about digitizing that information. It's something that we're still needing to work through and also the importance to say that even if you digitize Whakapapa, the whole process of learning and understanding our culture must be earned. So you can't just get it online and that's it. What is your contribution back to your people as well? So that's a really big call that's come from our validation so far. So who is this for? This is my whanau. My whanau are a perfect example of being disconnected from our tribal homelands and also a result of post-World War I coming into the cities and not knowing our Whakapapa. But the other key uses of this potential technology would be tribes. So they need to know who are the people that are putting forth their whakapapa. Are they who they say they are? Can they easily and accurately identify who you are? Is this a way that we can stay connected to our culture? And also can we utilize blockchain as a way to communicate with our whanau and our whanau can actually customize the kinds of communications that come from the tribe as well? So we've gone around, we've spoke to a whole group of people who say yes, blockchain or most importantly the way that we can utilize technology to better communicate and connect with one another is a good idea. And so I want to introduce Aho. Aho means I am. And the beautiful element of Aho is really this is our pataka or a storehouse of knowledge. It's built with Māori values and the whole purpose is to help our people connect with who you are and what you do. And I'm saying we because it's not just for Māori. In fact if you want to stay connected to your genealogy in a way that is safe and secure this particular product will be for you as well. So ultimately we want you to take control and ownership of your data and we want you to be able to share it with who you want, how you want in a way that suits you. And so we've already started this week on Monday. I just want my brothers here are Ben, if you can stand up, Ben, Tairia and Sam. We just give them a big clap. These are our two coders who are actually building this beautiful thing inside the centrality incubator. So I'm going to be sending all of you kodi people to my other kodi people over here to have that conversation because they're going to be building Aho with the support of centrality and we're really, really grateful. And so just focusing in on the benefit of this relationship. I'm really grateful to centrality for supporting us and building this particular concept. Auckland and Edinburgh universities who are very interested in supporting us. The team from Inspiral Dev Academy because as Josh said we're way behind. Well if we're way behind as New Zealanders where does that put Māori, Pacifica and migrant people. So we want to make sure that we can actually get the training out to our region so our whānau aren't just users of a service but we're actually engineering, managing and controlling the service as well. So we've got a pretty amazing team. Again Kaupapa Māori values. But of course we've got to keep ourselves safe culturally. So I'm really grateful that I've been able to ask for the support of the likes of Riki Rangi Gage on Te Whānau Apanui, Richard Jones who's from Rangitāne and also Te Arawa but also the head of Poutama. Theresa Tepinea Ashton who's in the whānau kopa kopa.  Mike Taitoko who's a data genius. And also Dr Manuka Henare from Auckland University to ensure that we are doing what we need to keep our people and our sacred knowledge safe. So again Māori owned, designed and delivered and also in alignment with Te Kanga Māori. So impact again this is about us controlling our information, ensuring that we have secure storage. There are some possibilities around governance and communications but in the future this is just the starting point. And so just briefly because I've got 15 seconds left, we'll be building on the plug blockchain. We'll be utilising the single source which is still under development to build this particular data. But in future this particular interface will then be able to provide the platform for how we manage our land, the way that we manage our health data, voting, education. And of course I get to my indigicoan at the end so I'm really happy about that. So finally I just want to say the importance of engaging our rangatahi as well. So we have the Māori Collective which is a group of rangatahi to support us on our journey. And finally my ask to you is how can you help us? We're interested in forging strong relationships with you and we're interested in you bringing your knowledge to our communities through training. Of course I'd love investment so this is a great ask and an opportunity but wait until it's built we'll come back out to you then.  And Ben said well actually you don't ask that question upfront you do that on the quiet but with that in mind if we do have people that would support us in trying to break it because if we're going to be going hand over heart to our people to talk about this platform and how awesome it is it needs to be safe and secure. So I want the best brains in the world you to help us with what we're doing. Ngorere Hoama, thank you very much. If you want more information aho.io which is as the Māori's in the room will understand the relevance of that but aho.io So if you want to know more information and get in contact with us, wai amai.


Hi everyone, my name is Steph. This is Little Bookish Teacher and welcome or welcome back to my channel. Today I am here to share with you the six books that have been shortlisted for the Readings Kids Prize for 2023. So there are six books on the shortlist. I think this is the 10th year of the Readings Kids Prize and what it celebrates is, hang on, I'll read the wording, the Readings Children's Prize is presented to the best contribution to Australian children's literature from an emerging author. So every year for the last 10 years they have selected six middle grade titles for their shortlist and then they always choose a winner and the winner should be announced sometime this month. It has been my goal to read these six books before then and I think I have done it. I'm going to laugh so hard if this video grows out and the winner has gone out but at this stage the winner has not been announced as I'm filming this on the 8th of October. So this is a combination of contemporary mystery, fantasy, historical middle grade fiction and I'm going to talk to you about all of the books and then at the end I'm going to share my favorites with you and why they're my favorites. Again, I'm not the intended audience for middle grade books. Middle grade books are written for children who are aged between eight and 12 years of age. Sometimes you can go a little bit either side of those age categories. They're written for a very specific audience that is not me. I'm coming at them from the perspective of an adult who really enjoys kids fiction, who really enjoys children's middle fiction but I have specific genres that I tend to read more in so that will always impact my thoughts on books and also I'm always wearing my teacher hat and thinking about okay do I know kids in this age category who would really love this type of story as well. So I come at this from multiple perspectives. These reviews are always just to share some thoughts that I had while reading them that might impact or help out parents who are selecting books or teachers who are selecting books for kids that read within this age category. We might go in the order that I read them. So the first one that I read was Evian Rhino by Nara Dermak-Mullen. This one is illustrated by Astrid Hicks and I actually read this one. You'll remember when I was talking about the CBCA Younger Readers category books. So this was shortlisted both for the CBCA as well as for readings. This is a historical story set in Victoria. We have a young girl who lives on a remote estate and she ends up finding a rhino that has been shipwrecked on the coastline and this rhino and a host of other animals were on their way to the Melbourne Zoo. So this was in 1891 and Evie has never seen a rhino. She has no idea what it is and she ends up taking it back to her family's property, popping it into a safe place and giving it food and shelter and then eventually admits to her grandfather that she has this monster or this creature on their grounds and he used to be part of the Zoological Society and he recognises the rhino straight away. This one does have discussions in it around how we care for animals, how we treat them. Evie and her grandfather are very concerned about what the Zoological Society will do to this animal, putting it into a very small enclosure that's full of concrete that doesn't have any natural elements to it. So you can have that environmental conversation with students as well. It's beautifully written. I loved that it was historical and it is based on a true story of animals on a cargo ship being stranded on their way to Melbourne Zoo in the past. So that is a really cool element as well. And for those who like these inclusions in book, there is also a recipe in here for a apple pie that is constantly referenced through the story. Then I read Seaglass by Rebecca Fraser. This is a much shorter middle grade fiction book and this one is about a young girl and her mother who end up moving in with her father's father, her grandfather who she hasn't really had much contact with over the summer because her mother has struggled to find a job and the place where she gets a job happens to be closer to where the grandfather lives. Kalen's father passed away when she was quite young. So she never really got a chance to know her grandfather and over the summer they get to know each other as they comb the beach behind his property for Seaglass. And she learns about how Seaglass forms and develops this relationship with her grandfather which is at war with sort of the life that she knows from when she was living in the city. And so despite the fact that Kalen thinks this is going to be the worst summer ever because she's not with her friend, she's in a place she doesn't know with a strange person, she doesn't know, she does begin to connect and then of course in the way of kids everywhere when things aren't quite going the way she expects, she says things she doesn't mean and also comes to realize that her grandfather is her grandfather. He's not young and he does have a heart attack in this story so be aware of that if you are talking about this or reading this with students because they might have experienced loved ones going through that. So obviously for Kalen this is quite a confronting thing to know that her grandfather is quite unwell and the timing of it in the story as well impacts her. But it is about connection, it is about cross-generational connection as well which is so important. This is a really beautiful little book and I loved all of the elements that it wove together. It was quite powerful for the for how short it was. People who can write a short narrative in I think less than a hundred pages and still pack that emotional punch. It's incredible because this is really powerful. Then I read the book Sellers Apprentice by Amelia Mellor. This is actually I think the second book in the series. I think it follows the grandest bookshop in the world. I actually listened to this on audio and it was a really interesting story. This is a more historical fantasy set in Melbourne and we have Billy Pike who is 12 years old, the oldest of his siblings, and he's constantly trying to sort things out for his very chaotic family and he ends up getting a job working for a bookseller at Paddy's Market and he's so excited to work there but he's then also approached by this very strange kind of sinister guy who is a magician and he wants to trade Billy for something and Billy realizes straight away that this isn't quite right. Billy himself has some magic and he doesn't feel right around the Obscura Smith. What he comes to realize is the Obscura Smith has done deals with people all over Paddy's Market and it impacts the way that they interact and the Obscura Smith doesn't like that Billy once says no to him but also has magic and their magic clashes and this sort of sets them on a course to a confrontation that impacts on many, many people. This is very action packed. It does have a bit of a race against time countdown sort of feel to it. There's a lot of magic and it was a really interesting read. I'm not much of a historical middle grade reader but it was interesting and the audiobook was great so if you're interested in listening to that I can highly recommend it. I think I got it off Libby from my local library so well worth checking that out if you're interested. Then I read No Words by Marianne Master. This is a contemporary fiction story. It is about Hiro who is a young girl, I think they're in Year 7 maybe? I think Hiro is in Year 7 or Year 8 and she is grappling with the fact that she feels like she never really lives up to her name. She finds it really hard to stand up to people even when she knows that they're doing something wrong and she and her best friend Jazz have befriended Arya who is a boy at school who is 12 years old who doesn't speak and he is constantly bullied by another student at the school and Hiro wishes that she could just step up and stop it but she like she doesn't know how and then one day she finds out that Arya has won a poetry contest and that he is an incredible poet and she never knew this about him. Obviously he doesn't speak at school but what we find out is that he has selective mutism, he doesn't speak at school but he does speak at home. We also find out that he is a refugee from Iran, he and his family fled Iran to get away from the conflict there and that while that was happening they lost, he lost his mother. So that is, that's quite a profound part of the story so do be aware of that because that may be triggering for some students but Arya has this incredible ability to use language and poetry to convey what he's feeling. Hiro and Jazz eventually convince him to take part in a slam poetry competition which would be really far outside his comfort zone so they work with him and as he begins to warm up with them and trust them he begins to talk to them and they begin to explore this new creative outlet. This book is told in two perspectives so we get Hiro's perspective and we also get Arya's perspective and it deals with some heavy topics but it was just a really incredible powerful book. I really enjoyed this one. Again it's not overly long, you can tell I've got my tabs because there were just so many phrases and passages in here that I just loved reading and I really like Mary and Master's writing style. I also read The Eerie Excavation by Ash Harrier. This is the second book in the Alice England mystery series. I did read the first one so that I could read this one. It felt like I needed to read that one before I read this book just to get the setup for the characters. We have Alice England and her friends Violet and Cal and they are hoping to go on a K-pop summer camp but when they can't get into that Alice ends up signing them up for an excavation or archaeological dig camp where the excavation team are hosting young teens to come and help them over the summer. They end up staying at this very old mansion that is reported to be haunted and as they're helping out on the dig site they begin to uncover a mystery that may or may not have occurred on the property in the past. Alice is a character who loves a good mystery. She can't help but get involved.  We have Violet who has a severe sunlight allergy so she can't be outside indirect ultraviolet rays and we have Cal who is a character that they met through the course of the first book. That seems like a strange addition to their little trio but fits in perfectly. This is the perfect book for those kids who love a mystery.  There is plenty of things going on and plenty of mysteries to solve throughout the entire book. And then there is The Winterish Girl by Melanie LeBroy. This is the first book in the Talismans of Fate series. It is quite a chunky fantasy story so if you have a child or a student who loves middle grade fantasy books this is probably one that's going to interest them. It is set in the fantasy world of Aurelia. We have Pen who is our main protagonist. She is an outcast from this society. She is actually Winterish which is a different group of people that have been locked out of Aurelia and she was taken from her family at only three days old because she was born on the same day as the future ruler of Aurelia and he's said to be Seraphine's not sister so it's kind of this close tie and part of Aurelian lore is that the rulers need to have their not sibling with them and so Pen has been treated quite horribly by the court. Seraphine is an orphan and hasn't yet taken the throne so there is a regent in place and the regent is doing some fairly dodgy things as you would expect but as they approach a really special day for kids in Aurelia which is the talisman day where they get to choose a talisman that has special properties or magic that allows them to do incredible things. Things start to go wrong. Dark evil malevolent force suddenly rises again and everyone blames Pen for it because she's the outcast. She's the person she's from one of their sort of you know rival towns and then it is up to Pen and her friend Juniper. They meet Arthur along the way and Seraphine and Seraphine gets involved as well. They need to uncover who exactly is behind it and how they can use their talismans to try and beat this evil force that is rising. The first half of this book is quite heavy world building. Obviously being the first book in a series has been quite a different world with a very different magic system. It needs that. I found that I was probably most interested in the last third of the book in the third act once we start getting some of the reveals and once we start diving a bit more into the history of why this evil force is rising as opposed to just the the history of the magical system but it was a really intriguing read and a really interesting fantasy world. I was quite intrigued by all the characters and the relationships that they have and also the complicated nature of Pen and Seraphine's relationship being not siblings because they just they don't get along. They know that there is a difference in a class difference between them that has been encouraged by the Regent which has caused a lot of issues but yeah it was a really interesting read and I'm glad that I read it. So those are the six books of those my top three. I actually I can actually rank these into the top three. So what I will say is that the booksellers apprentice, the eerie excavation, and the winterish girl all full sort of outside of my preferred genre in children's middle grade fiction get great books but for me personally they just didn't fit within my particular reading tastes. So my top three were these and in this order. So my third favourite was Evie and Rhino. I found this to be a really intriguing concept even though historical fiction is not necessarily my forte I thought this one was really interestingly done and I liked that it explored a part of Australian history that I'd never even considered. It was not even floating around in my head about how the Melbourne Zoo was first set up. I know I probably should have thought of that before now but I just haven't and I thought this was a really interesting take on real historical events being made into a story and also the language and the way that Naredo McMullen wrote it was just beautiful. Sea Glass was at one point my favourite book of the shortlist so far. As I said I just I enjoy any book that can be this short and have pack a really powerful emotional punch. I also like that this one is contemporary, it's easily relatable, the writing and it was great and I also like that it explores a hobby that I haven't seen featured in a book collecting Sea Glass. I thought that was great but hands down my absolute favourite from this shortlist was No Words by Merriam Master and look in part part of that is my personal connection coming through. My brother-in-law is originally from Iran and he and his family left Iran because of the conflict over there when he was quite young as well and so there is that sort of connection to the story that I bring to it. I'm always interested in learning a little bit more about the history of Iran and the conflicts that are going on over there but also the fact that this is set in a school. We have these characters who are dealing with real-life friendship issues and they're using poetry to express themselves. If I choose to write anything I tend to write poetry so I have that connection in terms of I find it really interesting when it's included in books as a way of characters being able to communicate or process their feelings and their emotions so to me this probably had the strongest connection which is probably why I enjoyed it the most but also Merriam Master's writing as I said when I was talking in my review is just really really wonderful. Some of her terms of phrase and the way that she writes was just lovely. So those are my top three and I'm really interested in seeing which of these six end up coming out with the readings prize this year so hopefully that will be soon and I will probably share that over on my Instagram page. Thank you very much for watching. If you got through this entire video well done. In the comments I'd love to know if you've read any of these books or if you're planning on picking them up or if you have any recommendations for books that sound similar to these books feel free to let me know down below. If you want to let me know that you're here but you don't want to leave a comment feel free to leave a trophy emoji down below. Otherwise I hope that we're in the world you're staying safe and healthy and I will see you in my next video. Thanks so much for watching. Bye everyone.