Hello, thank you for joining us. My name is Travis Newhouse. I'm the chief architect at UpFormix. And I'm joined by my colleague, Harshit Jitalia, who leads the integration of our product with OpenStack and Docker. And UpFormix provides software to control and monitor the resource usage in your infrastructure. And today, what I'm going to talk about is after you've set up your infrastructure and deployed your applications, how as an application owner do you ensure the expected performance of your applications? And as an infrastructure operator, how are you able to maximize the value of your infrastructure? So after you have OpenStack or Docker Engine up and running, you have this ability to easily create with a few mouse clicks, a few keystrokes, an instance, and start an application inside your infrastructure. And this is awesome because it's very simple. You can just spawn things off and you're off and running. And as soon as people find out about this in your organization, they're very happy. They come to you and they say, I need an instance. And so you spawn them one. You give them a virtual machine or a container, and they deploy their application to it. And everyone's very happy to start running applications. And where are these applications running? The applications are running on shared infrastructure. So every time you spawn a new instance, the slice of the pie is shrinking for each of those applications. Now, in some cases, that's OK. And you actually want that.  But there are other cases where it can eventually lead to applications not receiving the amount of resources they expect to achieve the performance they desire. And in the simplest case, what can happen is that the application, there's just too many running on the same host. And so the amount of resources that are available to a particular application are just too small. And the user experience degrades because there aren't enough resources to do what the application wants. The application developer has tested his code. He's implemented it in a scalable fashion. He's made sure that he's done his load testing. But when he gets it into production and it runs on shared infrastructure, all bets are off because he doesn't know how much resources he's going to get to run his application. The second kind of problem that can arise is actually what I would call dynamic demand for resources. On that shared infrastructure, it's not always a constant demand for resources by the applications. Workload comes and go, requests from users come and go. And the amount of resources that a particular application use is going to change over time. And as it changes over time, the availability of resources changes over time to all the virtual machines or the containers running on a particular host. And what that leads to is this unpredictable performance. So in contrast with just not being able to get an absolute amount that you need to run acceptably, you can run into a different problem where the unpredictability is what you'll get complaints about. Sometimes the application is running great. Sometimes now the user experience is poor. And so how do you deal with that unpredictability?  What you can see on this user interface is that this is showing the view of a single host that is hosting six virtual machines. And we're displaying the amount of CPU, the amount of memory, and the network I.O. in and out of the physical server associated with each virtual machine on that box. Now, when the application's not getting the right performance, when the application owner gets a complaint that the performance is not meeting the expectations, he's going to start asking, why is it happening? And the infrastructure operator will typically look at the connectivity. He'll check that the packet and byte counters are going up. He'll see that the application is getting scheduled. He'll see that it's running. And he'll say, from my end, it looks fine. The infrastructure is doing what it's supposed to do, your application is running. But the application owner knows that he's not getting the user experience that he expects. And we need these monitoring tools to help identify where is the bottleneck happening. And in this case, with the right tools, what we can see is that, as the number of instances grew, maybe this application in yellow at the bottom, it keeps shrinking. It gets down to the point where it's either below an acceptable threshold of resources. Or as the demand varies, because the blue application has a varying load, that sometimes the application in yellow is warning, well, and sometimes it's not. And so this leads to the first thing that what we at Performax provide, which is real-time monitoring. And it has a few aspects. First is just to give visibility into what the problem is in real-time. So we want to give you fine-grained resources, or fine-grained view of your resources over small-time scales so that you can see bursts. We also want to give you visibility at all the resources that an application might be using. So the CPU, the memory, the disk, and the network. And that's important, because then using that information, you can correlate problems. Like, if you see spikes in CPU at the same time, you see a spike in network. Maybe that lets you identify what kind of problem your application is experiencing. Maybe the latency is going up as the CPU spikes because of the demand of CPU by a different application running on the same host. And then the third thing that we require in the real-time monitoring is that the ability to see how the resources are used across the different layers of your infrastructure. So you want to know how much resources are being used at the host, the physical host. You also want to know how much resources are being used. When I say the physical, I mean how much total CPU, total network, so that you can kind of see how much capacity there is. You also want to know how much a particular VM or container is using. And that lets you know if this application is getting what it needs to achieve the expectations, the requirements you have for its performance. And then finally, the additional thing we want to provide is application-level metrics. And an example of that is for, if we look at HTTP, so many applications these days are built with a service architecture. And you're using REST APIs to access the application. And so it's very interesting to see what is the request rate, how many gets versus puts versus posts are being made to an application. That request rate is something that's interesting to the application developer to kind of profile their application and know why it might be performing one way or another. The second thing is that the application owner may be curious to know if he doesn't have his own counters in built into the application, that what are the endpoints that those requests are being made to? What are the URLs that those REST calls are being the gets and the puts and the posts? So at FormX, the agent that we put for monitoring can actually provide that level of insight into the application protocol and give you the ability to measure where inside the application-level protocol what's going on. Another interesting metric is the time to first byte. So for a web application, for a web server, you might want to know how long does it take from the time the request arrives at the physical host, makes its way up through the virtualization layers to the application. The application processes the request and sends the first byte of response out. Now that's a very useful metric because there's so many things happening between the physical network all the way up to the application. You have to worry about the scheduler. You have to worry about the packets getting through to the application, the data. You have to wait for the application to actually do its work. And then you need to send the response back out. And all those different pieces can become a bottleneck, and it's important to be able to identify. So having that metric of time to first byte lets you correlate things like compare the RTT, the round trip time, with the time to first byte, and identify is the bottleneck happening in the network because the round trip time to the network is slow, or is the bottleneck happening in the application because the network's quick and the data's arriving to the application, but it's taking a long time for the application to respond. And what I've been talking about is sort of contention that happens at a single physical host. If you have, in the example I gave earlier, six virtual machines or six containers or hundreds of containers running on a single host, they're all fighting for the CPU on that host. They're all fighting for the network bandwidth on the physical interfaces of that host. But as we move towards these architectures that are based around services inside our data centers, where we have shared storage, where we have a shared database, or a shared identity service, the contention is now moving outside of the physical host, or it's actually in addition to the contention that can happen at a physical host, you can now have contention at these infrastructure services. So at the storage service, you may have so many requests coming from many hosts, many physical hosts, I mean, virtual instances running on many physical hosts, all asking the storage for data or sending their rights to that storage service. And the bottleneck can now become at a single point in your data center that that storage service is providing or the database service. And that's why, as I mentioned earlier, the ability to see across all the hosts, all the VMs is an important aspect to monitoring. So I'm gonna show a slightly different example here. What we're seeing here is a project-oriented view. So earlier I showed a single host, right? And it's kind of an easy to conceptualize the idea of many virtual machines running on a single host. And what we have here is a more logical view. So in this case, there's a tenant of an OpenStack cluster, and he's got a project with a couple of different machines running on it. And these instances, maybe instance one, two, and three are all running on a single host. Maybe that's where they got scheduled. And the client one is running on a different host. But they're all accessing the same storage server. So what can happen is now, if client one suddenly has a burst in demand, maybe it starts running some really large workload, starts totally reading lots and lots of data from the storage server. Suddenly, instance one, two, and three are getting a much smaller share of the storage IO bandwidth. Now, if you were just looking at the host that showed you the view of instance one, two, and three, you're looking at a single host, all you would see is that suddenly, instance one, instance two, instance three have reduced storage IO. But you wouldn't be able to figure out why. Did the demand by the application go down? Or was it not able to get it? The amount of resources. But when you take a view that expands across more than one host, where you can see what's going on in your data center, maybe you can see what's going on at your storage server itself. Then you can see that, okay, when client one suddenly spiked up, that there's some correlation there. Probably that was what's driving the problem that I have with instance one, two, and three, not receiving the amount of bandwidth I wanted them to get from the storage server. So with proper monitoring, you can help pinpoint where's the bottleneck, like when there's a performance problem, where is it happening, why is it happening. You need these kinds of monitoring tools in order to answer those kinds of questions that arise in your applications and in your infrastructure. But how do you solve the problem?  What you would like to be able to do is apply a policy that says this application is assigned this many resources so it can get its job done at an acceptable level of performance. And that is the second thing that FormX provides is that we provide programmable control. We have an API-driven system that you can specify the amount of resources to assign to an application or to a virtual machine or to a container. And the reason we break it down that way is that sometimes you have more than one application running inside a virtual machine. And maybe you wanna prioritize, even within a certain virtual machine, what resources that virtual machine gets and how they get split up among its applications. Maybe the virtual machine is running both a web server and a database. And maybe the database you think is a higher priority to get its data out to a storage server or an object store where it's putting its information. And so you can kind of prioritize the bandwidth for the database, but maybe you leave the client-facing web server that's not a super high priority application, you give it a little bit less. And the API that we provide allows you to do two things. You can both configure it in real time. So if you find a problem, you can go solve it. With a simple command, with a simple REST API you can go and dynamically change the amount of resources that are given to a particular virtual machine instance, application, what have you that's running inside your infrastructure. And you can also, you can integrate these APIs into your orchestration so that when you're creating a new virtual machine, when you're spawning up a new container, you can assign at that time the amount of resources that are required for that application to run. You can configure that policy and we integrate with OpenStack. So for instance, right now you have like flavors of VMs that you can have, right, small, medium, large. What we allow you to do is you can say, okay, for small VMs, I want this much network IO. Or for large VMs, I want such and such network IO and such and such CPU. And providing that control allows you to preemptively assign the amount of resources that you think an application's gonna need, but you still have the ability at run time to say, okay, well, I'm not seeing problem over here, I wanna reconfigure my policy, I wanna change it, I wanna fix the problem as it's happening. And given that application IO is such an important part of applications these days, and application IO is predominantly over the network now. We're seeing that much less frequently is local disk being used. I mean, I'd be a scratch space, but for data that matters, it's going out onto the network typically. And or applications are interacting with multiple services over, you talk to your MongoDB, you talk to your Redis server and your RabbitMQ message bus. All this information is happening over the network. That's how applications and services are being composed these days. So today what I wanna focus on in terms of resource control is how you can configure the network resources to prioritize applications. So just to give you an example of how simple our APIs look is that at runtime with a curl command, I can actually configure the network resource limit for an instance. So that example I gave where we had four virtual machines and they were all accessing shared storage server. We saw that the client one in purple started consuming a lot of storage IO. And so we wanted to cut that down. And so at runtime we could say, let's say we wanna cut that down to 200 megabits per second. This is just a simple curl command you would be able to issue to our controller that would say for that virtual interface, this is how much bandwidth they can use. Similarly, if we were talking about if you wanna do it during orchestration with the time you're bringing up a container, then this is an example of a YAML file that we've kind of extended with Docker compose so that when you specify the container's attributes, you can say okay for this network limit, I wanna set a network limit for that container. So this video's kind of continuing the example we had earlier. And we can see that the curl command was issued, the bandwidth that the purple client one is able to achieve to the storage server is now being limited to 200 megabits per second. And what's interesting to note here is that the total throughput in the system is not changing, right? What we're doing is we're reallocating what resources that our infrastructure does provide to meet and the requirements of our applications and to prioritize which applications are important. So the aggregate throughput is the same but we've just reassigned it. A second type of control that we provide is that we allow what we call a reservation. And this carves out a certain amount of resources for the virtual machine or a virtual interface on a container and makes it unavailable to the other instances running on that host. If you recall the example we had in the beginning where there was varying load and the performance was unpredictable because you didn't know what the demand was, the demand was always changing on that same host. So at some times a machine was able to get a lot of bandwidth, sometimes an instance was not able to get enough bandwidth. You can solve that issue by, if you have an application that's a high priority, you can give it a reservation and you can say, okay, I want to carve out this much for this application and make sure that it receives a minimum amount of network IL. And again, API-driven and we can do it in real time. So here the yellow application is running and right now what we've done is we've set a 500 megabit reservation for the yellow instance six. And what we'll see is that as the load in blue comes and goes that as long as there's enough demand on that yellow application, it's gonna get the network IO that it needs to meet its performance requirements. So now the blue is varying, the purple and pink is they're going up and down because they're kind of subject to what's available. They haven't been given any limit or any guarantee, but yellow has been given a reservation and so it has guaranteed access to those resources on that host. So that's how we can prioritize that application and make sure it has predictable performance. So I just kind of want to bring it back here is that at performance, what our goal is is to optimize cloud operations by using a software tool that provides real-time monitoring and control, right? So the monitoring, I kind of showed a few aspects of what we can do with monitoring. We can look at the amount of resources that a physical host is using. We can look at the amount of resources that a virtual machine is using and we can inspect into what an application is doing in terms of the protocol. We have drivers right now for HTTP. We have one for iSCSI that we're working on so that those kind of cover a large majority of use cases that we're seeing in customer environments, storage being a big thing that's out on the network and web services being the other. So that covers like 95% of things that people are doing that they want to monitor at the application level. With that monitoring, we can show and help application owners and infrastructure operators identify where bottlenecks are in their infrastructure so they can find out is it the application that's performing poorly or is it the network that's performing poorly, right? Because you have this holistic view across your whole infrastructure. You can kind of correlate and pinpoint. And we feed that data up so that the UI that I was showing you earlier is our user interface and that is completely REST based in terms of how it controls and interacts with our software and it publishes the events up to the user interface and we make that available to the users as well. So if there's custom things you would like to do with the data, if there's certain monitoring you want to do, then that data can be consumed in-house by custom applications that you write to solve the kinds of problems you might be facing or to gain insight into what's going on in your infrastructure.  You can scale, I mean people are, data centers are growing and growing and growing. And our architecture is based on a distributed architecture such that the data that's feeding up is only the data that you really are interested in finding out about, right? So there's so much data that if you were to just push it all up and process it after it arrives at some central location, then there's just, you're gonna have so much data that you won't be able to keep up with it. You'll have to do a kind of offline processing and we want to be real time. We wanna be able to show you what's going on right now in your infrastructure, right now what problems you're facing. And so we actually flip it on its head instead of processing the data after it arrives in some central place, we actually process it on the fly in a distributed fashion. So if you're interested in certain kinds of data that you wanna subscribe to, certain kinds of events, maybe you're interested in, for instance, the time to first byte, you wanna know any time the time to first byte is spiking up. You can push a query down into our system that says when you see the time to first byte exceed one standard deviation above the norm, then I wanna generate an event up. I wanna know that information so that I can make a decision. I can be alerted. I could have a reactive system that is gonna automatically go reconfigure the policy to make sure that that time to first byte maybe is within the requirements of the application. So the second thing we do is control. And as I mentioned, it's all API driven. We give you real time, you can change the policy. We provide for network IO, CPU, memory. What we do is, as I showed for network is that we give you controls to set limits and to set reservations. And the rules can be applied across different layers of the infrastructure. So you can say I want a virtual machine or a container that interface to have a certain absolute bandwidth or minimum limit or reservation. Or we can actually say on an application by application basis. So you can say, okay, this virtual machine is running a few applications, but the web, the traffic that's going on the web, I want it to have this policy. Or for a storage server, when this virtual machine connects to this storage server, I want there to be a minimum reservation so that it can have the right access and ease to the storage IO. So with the monitoring and the control, in conjunction where you're basically able to ensure that you achieve the performance that you want for your applications. So you can both monitor and detect that your applications are getting the performance they want. You can find when they're not getting the performance that you want. And you can configure to ensure that they get the performance that you want. Right now our product is in production with a few early adopters. We're also expanding the program right now to new early adopters. So if you have use cases that you're interested in talking about, the performance problems you're seeing, we would love to hear about them. Come visit us at our booth. We can talk about the scenarios you have, use cases you have. And if you're interested, maybe we can sign you up for the early adopter program. We can deploy the software in your infrastructure. You can see what's going on, getting some insight and visibility into what's happening. We're at booth S4. So bring your scenarios down. And we're a growing company. So if you're interested in this area of work and maybe something you'd like to work on, definitely give us a ring. And I'll open up any questions right now. Oh, can you, I'm sorry. Can you speak at the mic? Dave asked me to. Actually a quick question anyway. Where does your controller run? Is it, do you have to run it on one of the compute nodes or is it independent of all the compute nodes or is there any restrictions on that? The controller runs outside of the compute nodes. You can just run it on a virtual machine. And that's like a management, consider it like a management machine that you would put in your infrastructure. And then we have the agent that's collecting data that runs on each compute node. I know you guys mentioned it. You're all about real time and monitoring real time. But have you saw in use cases so far any value in maybe collecting the aggregate data and providing dashboard and reports long term? Or is that kind of not your forte at this point? Yeah, we do that. I mean, we are focused on real time. But again, since we publish this data, right? The UI is one consumer of the data that we publish, right? We also have currently a listener that will store the data in MongoDB, right? And we can expand that to other kinds of storage, if someone wants to use Cassandra or something. And the amount of data that you would want to store, that's purely up to you. So if you want to have a really large infrastructure, you really want to store days worth of data or I don't know how long. But then you want to size a MongoDB that's appropriate for that amount of data, that data rate, that size of data. And then you can push that data out to a MongoDB that's set up and appropriately sized. Any other questions? A quick one, what is the granularity of your timing window for your real time monitoring and control? You're measuring packets per second. Yeah, what's the sampling window size? Right, it varies depending on the resource. For some resources, we have a finer granularity than others. And that's just to kind of make sure we don't disrupt what's going on on the compute node. We don't want to have a high overhead, right? So we have to balance that precision with the overhead that we impose on the system. For things like network, we're basically below a second granularity, because we're able to, again, filter what's the important data and push it up. And we're able to, for instance, identify a burst that's happening at a sub-second granularity, even if we're not giving samples up to the user interface at that same rate. The ability to do that data analysis kind of distributed at the compute node itself is what allows us to be both efficient and precise. CPU. So CPU is one that, right now, currently, we use a little bit more, like core screen, like one second, just because, again, it's harder to get that information without kind of putting load on the system too much. Are you using the OpenStack APIs, like CELOMETER or something? So we don't use CELOMETER. We have our own agent, which kind of collects all the metrics that we show, push it out, and push it out on a dashboard. But we have an OpenStack plugin, basically, to have discover all your infrastructure. So let's say, once you have deployed OpenStack and then you deploy AppFormics, we go in there and talk to the NOVA client and the neutral client and figure out all your infrastructure, like what our VMs are running, what our compute nodes do you have. So we have a discovery plugin, which will go and fetch all that information and then populate our controller and our database so that you can see the pretty charts. Yeah, and we also, the agent, after it does the discovery, it continues to listen on the OpenStack message bus. So as new instances come up, then we react to that, which show them, start monitoring them. And we also, like I was mentioning earlier, if you want to assign a certain network resource to each flavor, then you can automatically configure that at the time the instance is created. How, is that what the question was? How do we, OK. So using shares on the scheduler. So how do we do what with the network traffic? Oh, the question is, how do we control the network bandwidth? Basically, how do we? So we take an end-to-end approach, actually, where we make sure that the sender is not sending more than what the capacity is allowed. Now, we don't have to control the application, so that's a little bit of our secret sauce. But yeah, we don't actually modify the guest or the application at all. And we do not drop packets as well. Right. So for CPU, we rely on the scheduler that's in the hypervisor itself, right? So the hypervisor is always scheduling virtual machines. And by assigning shares, you can make sure that the virtual machine will not get scheduled. So it's not, we're not actually stopping it ourselves. We're letting the interface that the hypervisor provides already take care of that for us. Any other questions? All right, thank you very much. Be happy to talk to anyone else along.


Well, the Navy changed my life. It gave me confidence and it allowed me to become the person that I am now. I would never have thought as a child that I would have my PhD for one thing, that I would have retired from the Navy as a commander, that I would have been the CEO of a ship, that I would have been a Navy diver, so I've just done so many really cool things in my life that the Navy allowed me to achieve. One of the things that was happening back in the late 70s was opportunities for women who were just opening up and I didn't realize it at the time but the diving community had just recently been opened for women officers. So I was actually one of the first three women to go to the Navy Diving School in the Washington Navy Yard and what that taught me was that I was physically able to do a lot of things that I had never really done before. So it challenged me to an area where it gave me a lot of confidence and a lot of ability to actually lead later on because I did find out that men seemed to cherish people who have good physical ability. In the early 1980s there were no other ships really for women to go to so I kind of found my career stalled because men were able to go back-to-back sea tours, women didn't have that opportunity. So I went to a command that was a training command, so I was an instructor for two years and then I found out that the new class of salvage ships, ARS, auxiliary repair and salvage, a new class was opening up the safeguard class. So I called my detailer and asked him if I could be assigned to the new ship. There were going to be four in the class and the first ship had already been manned, the USS Safeguard, so he says I can put you on the second ship, the USS Grasp. I said great. So I terminated my shore duty after two years and then set out to be on this pre-commissioning unit, the USS Grasp, so I was on the Grasp from 1984 until 1987. While I was on the Grasp, of course, I got all my qualifications being the officer of the deck underway and all those kinds of things, so I was selected for executive officer. So I was executive officer right after that on the USS Preserver, which was an older salvage ship, so I built the 40s. And I also had the opportunity to do a dual EXO tour, so I crossed decked over to the USS Hoist and where we did a Mediterranean deployment, got my engineering quals, and then after that I was selected for commanding officer. Now at the time, there were other women in the running to become the first commanding officer of a Navy ship, but that other woman who was actually senior to me and a surface warfare officer was on her shore duty tour after her EXO tour. So I had the opportunity to be the first woman CO, which was not something I had ever thought would happen. You know, I was always thinking someone else would do it first, but it should not be me, so I took command of the USS Opportun in Naples, Italy in December of 1990.  I went to graduate school after I retired in 2000, and I actually got a PhD in sociology, and my experiences in the Navy framed my outlook on the sociological experience. My specialty areas were the military, the sociology of military, as well as gender work and family, so I have combined those two specialty areas to do research in gender and the military. So I have one book that under my belt, actually two, because my dissertation was about the senior women in the military, and then the second book was actually about issues that women face in the military environment, and I'm currently working on a third book about women military divers, so hopefully that will be done sometime in the near future.


to the creative life from the American Creativity Association on Think Tech Hawaii. I'm your host, Phyllis Blyse, and our co-host today is Darlene Boyd. Today on the show, we will be discussing how to use your noodle with our guest Seattle's soba master chef, Soma Otsuko. And she has been the food and wine winner for Best New Chefs in 2019. And that has to do around the opening of her restaurant in Seattle that specializes in handmade soba noodles called Kavanagi. And she also has a sister establishment next door where she serves sake and she's a sake sommelier and that's called Hanyoto. And I'm sure I didn't get that right but I think Chef Sova will help us with that. Today we'll learn her approach to creative thinking in the food industry and in restaurants and why she won a major contest called Use Your Noodle for which she made ramen noodles and new recipes and won a $50,000 award. You can send your questions to Chef Soma and the show today through email at questionsatthinktecawaii.com. So Chef Soma, Arigato for joining us today. You can get a lot of English in Hawaiian but Arigato Aloha for joining us. And can you just explain a little bit about what soba noodles are and what makes your restaurant different and creative? So, soba noodle is basically made from buckwheat. Our recipe is 80% buckwheat, 20% wheat and about 50% of water. That's it. No salt, no egg, anything else. And our restaurant, every soba noodles, I make myself by scratch. That's me mixing by hand, rolling by hand, cutting by hand, which takes lots, lots, lots of time. I think that's one of the reasons our restaurant is popular. It's like everything from scratch, everything handmade and love. And not only soba noodle, we're focusing on unique appetizer like you never seen anywhere else. An example, our most popular appetizer, it's called hoagura tofu. It's a tofu dish, but not made from soybean. It's made from hoagura, but tastes like tofu. Well, we're going to see you chopping noodles here in just a minute. And so you said this buckwheat noodles, fresh, you make them every day, fresh that day for the cuisine. And how many restaurants in the United States can anyone go to and get fresh buckwheat noodles, soba noodles? In U.S., I think one in San Francisco, one in Texas, hosting, and one, no, three in New York. I think that's it. Okay. So for folks watching the show, you have to get to Seattle and taste this daily fresh handmade soba noodles made out of buckwheat. And tell us a little bit what got you into the business of making soba noodles. Is it a business or is it kind of a love of life for you? So when I was a child, I was growing up eating my grandmother's noodles. She makes like, when family gather, she makes like soba noodles from scratch, makes us a tempura, like all sorts of feast. And after I moved to the United States, I never seen handmade soba noodles. And dry noodles, soba noodles, it's like completely different things. So I moved back to Japan once and studied how to make soba noodles and practice. And I come back initially just for myself so I can eat it. Then I realized, oh, no one else is doing like, why don't I start business? That's how I started.  So we do talk and we're going to show, at some point in the show, the audience is going to be able to see you chopping your fresh noodles. And there are YouTube's that we want to tell everybody about that we didn't get the copyright to that shows her, in her kitchen, doing the flour and water together by hand and she's kneading it. She's rolling out the dough and she's chopping it. It really is a labor of love. And so first of all, from a creativity and innovation standpoint, when there are no buckwheat fresh soba noodles in the United States, you kind of followed the path of necessity being the mother of creation. So you made your own and you're making them for everyone here in the US. And I think that's one of the sparks and inspiration for being creative. And in the making of it, is this a, didn't you say that it's a very changing art that every day with temperature and conditions, you're having to change your recipes and what goes into it on a day to day basis because of weather?  So I have to touchless noodles, sorry, touchless water or cold day dough gets tough. So you get more water, like need more, like atmosphere is not always same. So dough reacts every day difference. So I have to change the small difference to make adjustment. But it just sounds luscious. And Darlene, I know you have questions and we're going to shift to those that you have and tell the audience more about your creative style. So some of the last few days and since we've met you, I've been haunted trying to think of someone that I had heard that it's been said the creativity is one of the most important skills for a chef. And I knew that that I was somewhere and someone had said that. And it just came to me recently that it was Edward de Bono and it was after a meeting. And perhaps he was just trying to get a better dinner, but he was telling us all the strengths of chefs and that in his opinion, in his professional opinion, that chefs might be the most creative people that will ever cross our paths. So that being said, you, our guests come to us in many different ways, but you came to us through the press where we noted that you won a contest and the use your noodle contest which you won. Can you share with us the soba making process that you used in that contest and perhaps the recipes that you entered? Yeah, so technically, this is completely opposite things. Like I make soba noodle basically same process.   Does that make sense? Yes. So this particular contest is is it similar to what we see on television and those cooking contests or did you have to go somewhere or did they come to your place? This is from Instagram. So we just like, okay, all right. So there was there's a creative productive thinking skill that we wanted to share with the audience today and it comes from many directions, but one of the books on creative thinking, this is a series of books by Dr. Joyce Juntun and it's a fun book and she brings to our attention five different creativity skills to make you more productive in your creativity and one of them is fluency. Another is flexibility. Another is originality and elaboration and evaluation. And I know you have a special way that you won this contest on using your noodle and the way we would describe it in the creativity world is you use fluency and fluency means this is by Dr. Joyce Juntun. It's thinking of many many many many ideas. Some people would call it brainstorming idea generation and I know you have many ways that you worked with your ramen noodles. It was at 50 and you did it over a month and let's have the engineers show us some of the many ways that you created new recipes to win the contest. So talk to us about that. Can you enlarge the image? That'll have to be sage. Sage, can you make it bigger? So like one you see the bottom, I made tonkatsu using noodle as a crust instead of panko. Top one is chamush using like a powder as a broth and made an extinct custard. Ice cream sandwich. It's like dipping chocolate. Sandwich with ice cream. That's so good. Other one is pizza. I made so many. So brainstorming is just inside of your head, right? So I try to make actually things happen. So like I can taste it. I can feel next step of brainstorming, but it's kind of brainstorming. If I make 50 different things, I can choose like top three. Okay, this is amazing. That's like how I create like make a lot then choose top things. When you said you tested, were you the only tester or did you have others on your staff taste and test or and clients taste and test or just you? This was during pandemic. So me and my staff like we tasted as a lunch. So now this, so what I was hearing you tell us the other day is you tried 50 different recipes over a month of something new and then you choose three and those three make it onto your menu out of the 50. Have there been other foods or types of cuisine that you did this process? I thought you said something about oysters and were there other examples where you do this regularly in your process of cooking? Yeah, I did once with oyster like 50 different ways to cook oyster, but I did it with sake peyote. So I select sake paired with that new oyster dish. Other things I did was hot sandwich maker challenge. Have you ever seen hot sandwich maker like when you use for like camping? Okay, so I cook it to a panini grill or? Yeah, yeah, yeah. Okay. Okay. So I didn't cook sandwich inside of hot sandwich maker, but I cook something else like 50 different way like scotch egg or like sushi, okonomiyaki, gyoza, yeah, lots of different things. All right. Well, I think this is this Dr. Gentian also wrote another book. I didn't I don't have it with me, but it's called creativity thinking with foods. And maybe we'll have, you know, have another show with that. But this what we really wanted to let the audience know is I mean, it's very creative and fun to hear just about the food and the restaurant. And we also want to know what those skills are that we can all go and access ourselves to be more creative. And I think that you're doing you have a very big demand on your day. I mean, you probably work almost six or seven days a week long hours. You're the owner and the chef. Isn't that right? So this is keeping you very much on your feet. But also as you're doing so, you're not creating a routine where you do the same thing every day. You're doing many the same thing in many different ways. It sounds like every day. And it's what are you thinking, darling? It just sounds so innovative. It truly does. And also related to the innovation is you shared with us that you have a motto that you that you remind yourself. Can you share with us that motto? Yes. Don't think and just do it. Just explain it. You have to experiment. Try.  Yeah, which which explains to us why chefs might be viewed as some of the most creative people because it seems to me with 50 recipes to put in there and 50 ways to play around, that it can't be just playing around because you could have quick failures on the spot. So there's a whole list of knowledge base and strong knowledge base and skills I would assume. Would you not?  Yeah. You also told us a story about your grandmother. So the roots of your studying and playing around go pretty far or deep rooted, aren't they? Well, you remind me, Darlene, I wanted if we have time today to talk a little bit about your expertise with sake. And I don't know if everybody realizes there are sake sommeliers and you get the same kind of go through the same kind of certification processes that we do for wine and spirits. And you just keep pushing the doors wider open to more creative ways to show up with your food each day and in your restaurant. So tell us what it means first of all to be a sake sommelier and what sake means in Japan coming from a very Buddhist Zen background. How does that get brought into the culture in Japan? So my sakeba called hanyato means wisdom water. So hanyato is Buddhist word for wisdom water. It's like back then monk things like if you drink wisdom water make you think more, make you smart.  I love that. Wisdom water. So what does that and it does that with sake doesn't mean that, right? What how would you say wisdom water in Japanese? Hanyato. Oh, that's the name of the restaurant. All right. I know we get a real clear phonetics and also understanding hanyato is wisdom water in Japanese and then you're serving sake for that. So there must be many different ways to I know I'm in a wine tasting and investment club. We had sake twice was what we what we did our wine tasting and I was so surprised to learn that some of the most expensive sake were served cold and growing and growing up sort of in Hawaii and spending many years there. I only got it served hot and little hot sake dishes. So could you tell us a little bit about the cold sake versus hot and you know how to add these to your meal or to your week? So some people think hot sake is bad or cheap sake or like more happier drink but that's not true. Sake is only beverage you can enjoy besides tea you can drink cold to hot and there's so many different type of sake. Some sake better showcase cold such a daiginjo type like daiginjo like more high-end like more fruit sword like clear sake but uh like kimoto style sake more old style sake taste better warm or hot taste more umami so it depends on like what's you like or what's your preference there was correct way to drink sake. So Soma are you part of a community of chefs and if so do you do you all gather in your sake bar and gain your wisdom? Yeah if you have other chefs that you can regularly discuss and bounce ideas. Interesting and um well I I wish we could do a sake tasting here and and have you take us through the delights and the variances of the different tastes. Do you pair your sake with different chosen soba noodle dishes or are they does it go with anything or the other dishes that you make from scratch at the restaurant? Most of the dish goes well with sake and also I have different type of sake at the restaurant and more here you know like some people think fish doesn't taste great with red wine right but fish or like any seafood is amazing with sake like example people like eat sushi with sake right just because sake doesn't have any iron so doesn't like fight like iron fish so I think any any any sake you choose from our bar or restaurant tend to go well with everything. Oh fascinating well you know one of the things I just got noticed from the engineers I think that I would like the audience to see you doing this homemade soba noodle buckwheat noodle making and there will be a silence when we're showing it but I think that would be absolutely appropriate have a sacred silence as we watch you doing the handmade noodle making so Max if you would bring it on we'll know that it'll be a silent few minutes watching this ancient art of soba noodle making. Thank you. That's a cutting board. I know that I wanted the longer video and we don't even see you but it still is something for viewers to see. Thank you. That's good. Oh a little bit of you awesome well there we are and we got a little bit of Chef Soma in the video and it's just been a delight to learn more about your creative processes. Darlene do you have anything? Yeah so what do you think or what what efforts do you go through to make your customers come back? I like changing menu often that's like number one like if people like my food like I make sure post it on Instagram so people see it people come back. So you do use social media and technology okay a little bit of that you're not your broad-based knowledge there. How did you find out about the contest? It was on Instagram was it posted on Instagram? Yeah so you found it through your following on Instagram interest and how long did it take you to prepare for the contest? So I made one thing a day so like about months but I do like one thing a day and difference. And so over the course of a month did you turn in these recipes to the contest producers like throughout the month you kept sending new recipes in or did you do it all at once? I just posted on Instagram every day. Oh I see posted it I see so it's an entirely electronic process I see and do you hold fairs or food days in anywhere around Seattle where you show up with the food truck and try to recipes out or is it they're always coming in just to the restaurant? Just to the restaurant. Okay so as an art you were talking about your daughter you were hoping that she would learn this art of soba noodle making. Tell us a little bit about that why is that what would how does that add would that add to her life and maybe our lives to to to do this kind of practice and art and food? It's you know family things like my grandma was always cooking for you know grandkids and go generation by generation and when my grandma died it's same day my daughter was born so like I felt like something like I should teach her soba noodle too so you know hopefully when she became mom or she became grandmother she can teach grandkids or kids how to make soba or at least like feed them soba. Thank you so much that was really touching and reminds us too that staying in that in this area of creativity and being innovative and and getting away from cookie cutter kind of life and and sharing the special unique gifts that we give when we're using our own creativity each time it's so different and if you made it seem very special in our American creativity world of creativity your touch of it. I would agree there's something beautiful in the discussion field especially as you describe it and and I think we often talk about the stages of creativity if if one ties into that there are such and and so you talked about brainstorming but but I think there's something more beautiful underlying here and it's it's not just using the tools but there's an ebb and a flow soma that you described and and I think you would agree Phyllis is as we're listening to this process it's not just step one step two step three there's the pulling back and then there's the beautiful flow and then we turn in and we add the wisdom water and so it's it's really a pleasure to listen to your dedication. Thank you. It certainly is and we're I'm going to have to close and talk about the next show is there anything that you wanted to say chef soma before we close the show out besides inviting people to the restaurants and coming to Seattle?  That's beautiful and well on that note thank you darling we we will leave it here for today dear audience you have been watching The Creative Life on Think Tech Hawaii and today Darling Boyd and I have been discussing how to quote use your noodle to develop creative thinking skills such as fluency in your daily life we've been with soba master chef soma mutsuko and she wants us to remember don't think just do experiment and try so thank you very much for participating and I'm Phyllis Blesch your host and in two weeks we will be back with another edition of The Creative Life aloha